«Моніторинг продуктивності .NET-додатків: підходи та інструменти», — інтерв'ю з Діною Гольдштейн



Не завжди розробляється рішення працює з прийнятною продуктивністю. Особливо для замовника. І якщо пропозиція докупити пам'яті і підняти системні вимоги не спрацьовує (у мене ні разу не виходило), доводиться братися за оптимізацію. І для цього у нас є не тільки StopWatch: про інструменти, які дозволяють зрозуміти, де шукати, куди лізти в першу чергу, яких результатів чекати, працюючи над перфомансом програми, поговорили з прекрасною дівчиною, відмінним фахівцем і доповідачем конференції DotNext 2016 Moscow — Діною Гольдштейн.

Діна — старший інженер програміст в компанії Aternity. Aternity займається розробкою інструментів моніторингу для мільйонів PC і мобільних пристроїв. Діна працює в команді, відповідальної за головний механізм збору даних з різних джерел.


Про рішення для моніторингу
– Які існують готові рішення для моніторингу? Наскільки вони популярні і затребувані? Які завдання вирішують?

– Інструменти моніторингу можуть бути поділені на дві головні групи — вбудовані блоки та окремі незалежні програми.

Для першої категорії існують такі інфраструктури як ETW (Event Tracing for Windows) і лічильники продуктивності. Вони вже встановлені в Windows. Ви можете використовувати готові рішення для збору даних або вбудувати компоненти в ваш інструмент .NET (або C++) API. Дані рішення, безумовно, допоможуть реалізувати саме те, що ви хочете. Але головне слово тут — реалізувати. В основному доведеться проробляти всю роботу самостійно. Ах, так, ще ви завжди можете перехопити (hook) виклики Windows API, щоб отримати ще більше даних, але це вимагає особливого підходу і підвищеної уваги.

Серед готових інструментів існує багато продуктів. І бібліотеки, які вбудовуються в ваш код, наприклад, New Relic, і повністю готові системи моніторингу, які не вимагають втручання програмістів. Наприклад, Aternity, де я працюю.

– Рано чи пізно складається така ситуація, коли готових інструментів не вистачає. І доводиться вже писати код у своєму продукті. Чи пропонують .NET Framework і засоби мови що-небудь, щоб спростити розробку?

– Так, однозначно. Лічильники продуктивності, звичайно, мають зручне .NET API, а використовувати ETW можна за допомогою вільно доступного NuGet пакету під назвою TraceEvent, який розробляється microsoft'ом. Нещодавно, до речі, компанія відкрила вихідний код. Тепер репозиторій доступний на GitHub.

Це були кілька слів про загальному підході. Окремі фреймворки на базі .NET (такі як WCF, WPF і Entity Framework) мають точки розширення, де ви можете вбудовувати свій код і збирати необхідні дані. Інша цікава опція — використовувати ClrMD. Це набір API для налагодження в .NET (також з відкритим вихідним кодом, підтримується microsoft'ом, доступно на GitHub і через NuGet).

З допомогою ClrMD можна отримувати стек викликів, досліджувати керовану купу тощо. Я не думаю, що вийде зробити масштабний моніторинг, використовуючи цей інструмент, хоча б тому, що накладні витрати занадто великі, але якщо ви виявили проблему з використанням будь-якого іншого інструменту, то з ClrMD можна отримати специфічну інформацію. Наприклад, якщо ви виявили, що купа в додатку занадто велика, то можна визначити, які саме об'єкти споживають найбільше пам'яті.

Якщо ви хочете зануритися глибше в Win32 API, то, я боюся, .NET не зможе особливо допомогти, і доведеться вдаватися до C++. Наприклад, Microsoft Detours.

Ви не повинні втрачати контроль
– Наш програмний продукт пішов в експлуатацію. Чи втратили ми контроль або все ще є способи збирати інформацію? Як краще це зробити?

– Ні! Ви не втрачаєте контроль. Якщо мова йде про серверному або хмарному продукті, то, звичайно, можна використовувати будь-яке рішення для моніторингу, що підходить під ваші потреби, так як оточення знаходиться під повним контролем.

Якщо ж ви розробляєте настільне додаток, ви не можете вимагати від користувачів установки фреймворку для моніторингу. А це означає, що доведеться вбудовувати в додаток можливість самостійного моніторингу. Звичайно, тут можна скористатися готовими бібліотеками, наприклад, New Relic, або реалізувати самостійно, використовуючи .NET API, який я вже згадала.

По правді кажучи, останнім часом я намагаюся переконати менеджера додати в наше додаток моніторинг навантаження на процесор, який працюватиме, використовуючи лічильники продуктивності, а по досягненню деякого порогового значення – запускати збір статистики по стеку викликів за допомогою ETW.

– Яка похибка вимірювань вважається прийнятною, і як нам її досягти?

– Я вірю, що точність — це не основне завдання. Ви явно хочете в цілому розуміти, як саме працює продукт. Моніторинг випущеного продукту – це не те ж саме, що налагодження і профілювання під час розробки. Завжди є способи отримати більше даних під час експлуатації, наприклад, використовуючи ClrMD, але через високу точність доводиться платити. Можна, звичайно, часами так робити, але я поки не бачу сенсу в його постійному користуванні. Ви можете підключитися або профілювальником відладчиком на короткий час, коли стикаєтеся з проблемами продуктивності. В ідеальному випадку моніторинг повинен давати загальне уявлення, і коли виявляється проблема, ви повертаєтеся в офіс, програвайте її локально і досліджуєте з використанням спеціалізованих інструментів.

– Припустимо, треба виміряти продуктивність методу. Але немає впевненості, що сторонні дії не вплинуть на це, збирач сміття, наприклад. Які є підводні камені при вимірах і як їх уникнути?

– Це залежить від того, що розуміти під продуктивністю методу. Якщо ми говоримо про «алгоритмічної» продуктивності, то, ймовірно, немає потреби вимірювати під час експлуатації в реальному оточенні, а можна локально написати тест, зупинити збірку сміття, відключити файл підкачки, підключити ноутбук до харчування, і взагалі зробити все, що ви вважаєте необхідним.

Але в реальному житті у нас немає можливості контролювати, коли ці переривання трапляться. Що дійсно МОЖНА зробити — це отримати інформацію, коли переривання мали місце та як довго тривали. ETW надає інформацію про збирача сміття, мережі, звернення до диска і так далі. Потім вже можна проаналізувати всі ці дані разом і прийти до висновку про продуктивності. Конкретно зі складальником сміття, якщо є критичні місця, то можна використовувати GC.TryStartNoGCRegion.

– Торкнемося трохи чисту теорію. На великих системах при великих обсягах даних виникає бажання використовувати досягнення математики. Багато існує теорій? Наскільки статистичні методи популярні? Використовуються в якихось інструментах?

– Відомі мені інструменти тільки збирають дані. І потім вже кожен сам вирішує, як обробляти ці дані. Одна з особливостей, яку слід прийняти до уваги, – іноді для отримання даних використовується дискретизація (sampling) замість перехоплень Windows API, які значно дорожче в плані продуктивності. За своєю природою дискредитація може призвести до недооцінки кількості рідкісних подій. Особливо це проявляється при вимірах використання процесора, і треба переконатися, що виміри проводяться досить довго, щоб статистично отримати інформацію навіть про дрібних діях. Але з іншого боку, ці дрібниці явно не те, що викликає проблеми продуктивності, і, ймовірно, взагалі не важливі, якщо ви хочете отримати уявлення про те, що займає більше часу, а що — менше. І однозначно не можна одержати точний час виконання при таких вимірюваннях.

Про моніторинг на етапі проектування системи
– чи Потрібно при проектуванні системи закладати точки розширення для моніторингу в майбутньому? Чи існують сформовані підходи і рекомендації?

– Так, однозначно! Я не згадувала це раніше, але ми можемо створювати свої лічильники продуктивності і ETW-логи. Тому під час розробки системи слід замислитися, які місця можуть бути цікаві і які дані повинні бути зібрані. В ідеальному випадку система повинна бути розроблена таким чином, щоб DevOps-и могли моніторити все, що їм потрібно, без втручання програмістів.

– Варто чекати допомоги від засобів розробки, наприклад, Visual Studio?

– Тут залежить знову ж від оточення. Звичайно, в Visual Studio є відмінні інструменти для профилировки під час розробки. Але не варто чекати допомоги під час експлуатації програми. По-перше, тому що профілювання має великі накладні витрати. По-друге, не можна поставити Visual Studio на комп'ютери користувачів, хоча б із-за обмежень по ліцензії. Якщо є віддалене підключення до сервера і допускається зупинити додаток на деякий час, то можна використовувати Visual Studio Remote Debugger. Але це все-таки налагодження, а не моніторинг.

– Багато стикаються з необхідністю обробляти величезну кількість сирих даних отриманих при моніторингу. Можна автоматизувати?

– Так, звичайно. Якщо ви використовуєте ETW, то ви також можете використовувати TraceEvent і написати трохи .NET-коду, який буде аналізувати події онлайн або оффлайн. Якщо ж ви використовуєте інший джерело даних і результат має стандартний формат, то можна використовувати будь мову програмування для аналізу. І, звичайно, в наш час існує неймовірна кількість готових програм і платформ для аналізу, які дозволяють обробляти дані в красивій формі і динамічно показувати на панелі моніторингу.

– Які проблеми зараз стоять перед інструментами моніторингу? І в якому напрямку йде розвиток?

– Я думаю, що найбільш актуальні проблеми — це накладні витрати і передозування даними. Ми не можемо дозволити великих просідань продуктивності через моніторингу. Крім того, користувач повинен мати можливість змінювати, що моніторити, і конфігурацію динамічно, без перекомпіляції або перезапуску програми. Особливо це актуально для фондових бірж і військових.

Ще одна річ, якої особливо не вистачає під Windows, це можливість зручно динамічно перехоплювати будь-які виклики Windows API, щось на зразок eBFP для Linux. В даний час ми стикаємося з великою кількістю даних, тому все більш популярними стають панелі управління, які дозволяють групувати і динамічно відображати інформацію згідно з постійно мінливими вимогами.



Діна виступає у першій секції конференції DotNext 2016 Moscow, яка відбудеться 9 грудня в готелі «Radisson Слов'янська». Зареєструватися ще можна тут.

Крім доповіді Діни також можна буде послухати:

.NET Core: State of the art
Squeezing the Hardware to Make Performance Juice
Інтелектуальні чатботы і когнітивні сервіси
Stack Overflow — it's all about performance!
Advanced Xamarin.Forms
C++ через C#
Продовжуємо говорити про арифметику
ASP.NET SignalR: Why it's Getting Really Crucial for Web Development
Exceptional Exceptions in .NET
Модифікація коду .NET у рантайме
End-to-end JIT
Performance tuning Stack Overflow tags
C# Scripting — why and how you can use your C# in places you never thought of before!
Multithreading Deep Dive
Зібрати все, або Знайомимося з Cake (C# Make)
WinDbg Superpowers for .NET Developers
Overview of the new .NET Core and .NET Platform Standard
Які знаходять уразливості в .NET платформі і як не повторити їх в своїх додатках
what's new in C# 7?
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.