Не всегда разрабатываемое решение работает с приемлемой производительностью. Особенно для заказчика. И если предложение докупить памяти и поднять системные требования не срабатывает (у меня ни разу не получалось), приходится браться за оптимизацию. И для этого у нас есть не только StopWatch: об инструментах, которые позволяют понять, где искать, куда лезть в первую очередь, каких результатов ждать, работая над перфомансом приложения, поговорили с прекрасной девушкой, отличным специалистом и докладчиком конференции DotNext 2016 Moscow — Диной Гольдштейн.
О решениях для мониторинга
– Какие существуют готовые решения для мониторинга? Насколько они популярны и востребованы? Какие задачи решают?
– Инструменты мониторинга могут быть поделены на две главные группы — встраиваемые блоки и отдельные независимые программы.
Для первой категории существуют такие инфраструктуры как 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)