что такое профайлер java
Руководство по профилировщикам Java
1. Обзор
Иногда просто написать код, который просто запускается, недостаточно. Возможно, нам захочется узнать, что происходит внутри, например, как распределяется память, последствия использования одного подхода к кодированию по сравнению с другим, последствия одновременного выполнения, области для повышения производительности и т. Д. Мы можем использовать для этого профилировщики.
В этой статье мы обсудим основные профилировщики Java: JProfiler, YourKit, Java VisualVM и Netbeans Profiler.
2. JProfiler
Обладая этой информацией, мы можем легко узнать, что нам нужно оптимизировать, исключить или изменить в базовой системе.
Вот как выглядит интерфейс JProfiler:
Обзорный интерфейс JProfiler с функциями
На приведенном ниже снимке экрана показан интерфейс проверки JDBC со списком текущих подключений:
Просмотр проверки базы данных JProfiler
Если мы хотим узнать о дереве вызовов взаимодействий с нашей базой данных и увидеть соединения, которые могут просочиться, JProfiler прекрасно справится с этим.
В случае дерева вызовов распределения мы можем выбрать просмотр дерева вызовов живых объектов, объектов со сборкой мусора или того и другого. Мы также можем решить, должно ли это дерево распределения быть для определенного класса или пакета или для всех классов.
На приведенном ниже экране показано использование оперативной памяти всеми объектами с количеством экземпляров:
Просмотр живой памяти JProfiler
3. YourKit
YourKit Java Profiler работает на многих различных платформах и обеспечивает отдельные установки для каждой поддерживаемой операционной системы (Windows, MacOS, Linux, Solaris, FreeBSD и т. Д.).
Вот краткий обзор результатов профилирования памяти серверного приложения Tomcat:
Профиль памяти YourKit Java Profiler серверного приложения Tomcat
YourKit имеет интересную функцию профилирования ЦП, которая позволяет целенаправленно профилировать определенные области нашего кода, например методы или поддеревья в потоках. Это очень мощный инструмент, позволяющий выполнять условное профилирование с помощью функции «что, если».
На рисунке 5 показан пример интерфейса профилирования потоков:
Рисунок 5. Интерфейс профилирования потоков YourKit Java Profiler
Мы также можем профилировать вызовы баз данных SQL и NoSQL с помощью YourKit. Он даже дает представление о фактически выполненных запросах.
Хотя это не является техническим соображением, модель разрешающего лицензирования YourKit делает его хорошим выбором для многопользовательских или распределенных групп, а также для покупок с одной лицензией.
4. Java VisualVM
Ниже мы можем увидеть простой обзорный интерфейс текущего сеанса профилирования с использованием Java VisualVM:
Профилирование приложения локального сервера Tomcat Java VisualVM
Ниже мы можем увидеть внешний вид памяти приложения Java, профилированного с помощью Java VisualVM:
Гистограмма кучи памяти Java VisualVM
5. Профилировщик NetBeans
Все другие описанные выше профилировщики предоставляют плагины для улучшения интеграции IDE.
На снимке экрана ниже показан пример интерфейса профилировщика NetBeans:
Интерфейс телеметрии Netbeans Profiler
6. Другие твердотельные профилировщики
7. Заключение
В этой статье мы обсудили профилирование и профилировщики Java. Мы рассмотрели особенности каждого Profiler и то, что определяет потенциальный выбор одного из них.
Доступно множество профилировщиков Java, некоторые из которых обладают уникальными характеристиками. Выбор профилировщика Java для использования, как мы видели в этой статье, в основном зависит от инструментов, выбранных разработчиком, требуемого уровня анализа и функций профилировщика.
В поисках перформанса, часть 2: Профилирование Java под Linux
Бытует мнение, что бесконечно можно смотреть на огонь, воду и то, как другие работают, но есть и ещё кое-что! Мы уверены, что можно бесконечно говорить с Сашей goldshtn Гольдштейном о перформансе. Мы уже брали у Саши интервью перед JPoint 2017, но тогда разговор касался конкретно BPF, которому был посвящен доклад Саши.
На этот раз мы решили копнуть глубже и узнать фундаментальные проблемы мониторинга производительности и варианты их решения.
С чего стоит начинать
— В прошлый раз мы довольно подробно поговорили про BPF и вскользь обсудили проблемы мониторинга производительности Java под Linux. В этот раз хотелось бы сконцентрироваться не на конкретном инструменте, а на проблемах и поиске решений. Первый вопрос, довольно банальный, — как понять, что с производительностью есть проблемы? Следует ли думать об этом, если пользователь не жалуется?
Саша Гольдштейн: Если начинать думать о производительности только в момент, когда ваши пользователи жалуются, с вами они будут недолго. Для многих инженерия производительности — это траблшутинг и crisis mode. Телефоны звонят, свет мигает, система упала, клавиатура горит — обычные трудовый будни перформанс-инженера. В реальности же они проводят большую часть своего времени, планируя, проектируя, мониторя и предотвращая кризисы.
Для начала, capacity planning — оценка ожидаемой нагрузки системы и использования ресурсов; проектирование масштабируемости поможет избежать узких мест и получить значительные увеличения в нагрузке; инструментирование и мониторинг жизненно необходимы для понимания того, что происходит внутри системы, чтобы не копаться вслепую; благодаря установке автоматического оповещения вы точно будете знать о любых возникающих проблемах, как правило ещё до того, как пользователи начнут жаловаться; ну и конечно же будут единичные кризисы, решать которые придётся в стрессовых условиях.
Стоит отметить, что тулы постоянно меняются, но сам процесс остаётся неизменным. Приведу пару конкретных примеров: capacity planning вы можете сделать и на бумажке на коленке; можно использовать APM-решения (как New Relic или Plumbr) для end-to-end инструментирования и мониторинга, AB и JMeter для быстрого нагрузочного тестирования и так далее. Чтобы узнать больше, можно почитать книгу Брендана Грегга «Systems Performance» — это отличный источник по теме жизненного цикла и методологии перформанса, а «Site Reliability Engineering» от Google освещает тему установки характеристик производительности (Service Level Objectives) и их мониторинга.
— Допустим, мы поняли, что проблема есть: с чего начинать? Мне часто кажется, что многие (особенно не профессиональные перформанс-инженеры) сразу готовы расчехлять JMH, переписывать всё на unsafe и «хакать компиляторы». Потом смотреть, что получилось. Но ведь в реальности лучше не с этого начинать?
Саша Гольдштейн: Это довольно распространённая практика, когда при написании кода и проведении базовых тестов профайлера возникают проблемы с перформансом, которые можно легко исправить, поменяв код или «хакнув компиляторы». Однако на проде, исходя из моего опыта, это делается не так часто. Многие проблемы присущи только какой-то одной среде, вызваны меняющимися паттернами рабочей нагрузки или связаны с узкими местами вне кода вашего приложения, и лишь малую часть можно замикробенчмаркать и улучшить на уровне исходного кода «умными» хаками.
Вот пара примеров для иллюстрации:
— Наверняка следует сначала посмотреть, как приложение/сервис работает в продакшне. Какие инструменты ты для этого рекомендуешь, а какие — не очень?
Саша Гольдштейн: Мониторинг и профайлинг на проде — это набор инструментов и техник.
Начинаем с метрик высокоуровневого перформанса, фокусируясь на использовании ресурсов (процессор, память, диск, сеть) и характеристике нагрузки (# запросов, ошибок, типов запросов, # запросы к базе данных). Есть стандартные тулы для получения этих данных для каждой операции и времени выполнения. К примеру, на Linux обычно используют инструменты вроде vmstat, iostat, sar, ifconfig, pidstat; для JVM используют JMX-based тулы или jstat. Это метрики, которые можно непрерывно собирать в базу данных, возможно с 5-ти или 30-ти секундным интервалом, чтобы можно было проанализировать скачки и при необходимости вернуться в прошлое, чтобы скоррелировать предыдущие операции по развёртыванию, релизы, мировые события или изменения рабочей нагрузки. Важно, что многие фокусируются на собирании только средних показателей; они хоть и хороши, но, по определению, не представляют полное распределение того, что вы измеряете. Гораздо лучше собирать процентили, а по возможности даже и гистограммы.
Следующий уровень — это операционные метрики, которые обычно нельзя непрерывно собирать или хранить долгое время. Они включают в себя: лог сбора мусора, запросы сети, запросы к базе данных, классовые нагрузки и так далее. Разобраться в этих данных после того, как их где-то хранили, иногда гораздо труднее, чем, собственно, их собирать. Это позволяет, однако, задавать вопросы, вроде «какие запросы работали, пока нагрузка ЦП базы данных повышалась до 100%» или «какими были IOPS дисков и время отклика во время выполнения этого запроса». Одни лишь числа, особенно в виде средних показателей, не позволят вам провести подобного рода исследование.
И наконец, «хардкорный» уровень: SSH в сервере (или удаленный запуск тулов) для сбора большего количества внутренних метрик, которые нельзя хранить во время штатной работы сервиса. Это инструменты, которые обычно называют «профайлерами».
Для профайлинга Java-продакшна существует множество жутких тулов, которые не только дают большой оверхэд и задержки, но могут ещё и лгать вам. Несмотря на то, что экосистеме уже около 20 лет, есть лишь несколько надёжных профайлинговых техник с низким оверхэдом для JVM-приложений. Я могу порекомендовать Honest Profiler Ричарда Ворбертона, async-profiler Андрея Паньгина и, конечно, моего любимчика — perf.
Кстати, много тулов фокусируются на профайлинге процессора, разбираясь в том, какой путь выполнения кода вызывает высокую загрузку ЦП. Это здорово, но часто проблема не в этом; нужны инструменты, которые могут показывать пути выполнения кода, ответственные за распределение памяти (async-profiler теперь может делать и это), ошибки отсутствия страницы, непопадание в кэш, доступы к диску, запросы сети, запросы к базе данных и другие события. Меня в этой области привлекла именно проблема поиска правильных перформанс-тулов для исследования работающей среды.
Профилирование Java под Linux
— Я слышал, что под Java/Linux стек есть куча проблем с достоверностью замеров. Наверняка с этим можно как-то бороться. Как ты это делаешь?
Саша Гольдштейн: Да, это печально. Вот как выглядит текущая ситуация: у вас есть быстрая конвейерная линия с огромным количеством разных частей, которые нужно протестировать, чтобы найти дефекты и понять скорость приложения/сервиса. Вы не можете проверить абсолютно каждую часть, поэтому ваша основная стратегия — это проверять 1 часть в секунду и смотреть, всё ли в порядке, и вам нужно это делать через «крохотное окно» над этой «лентой», потому что подходить ближе уже опасно. Вроде неплохо, не так ли? Но потом оказывается, что когда вы пытаетесь в него посмотреть, оно показывает вам не то, что происходит на конвейере прямо сейчас; оно ждёт, пока конвейер перейдёт в волшебный «безопасный» режим, и только после этого даёт вам всё увидеть. Также оказывается, что многих частей вы не увидите никогда, потому что конвейер не может войти в свой «безопасный» режим, пока они рядом; и ещё оказывается, что процесс поиска дефекта в окошке занимает целых 5 секунд, так что делать это каждую секунду невозможно.
Примерно в таком состоянии сейчас находится множество профайлеров в мире JVM. YourKit, jstack, JProfiler, VisualVM — у всех у них одинаковый подход к профайлингу ЦП: они используют семплинг потоков в безопасном состоянии. Это значит, что они используют документированный API, чтобы приостановить все JVM-треды и взять их стек-трейсы, которые затем собирают для отчёта с самыми горячими методами и стеками.
Проблема такой приостановки процесса заключается в следующем: треды не останавливаются сразу же, рантайм ждёт, пока они не дойдут до безопасного состояния, которое может находиться после множества инструкций и даже методов. В результате вы получаете необъективную картину работы приложения, а разные профайлеры могут ещё и не соглашаться друг с другом!
Есть исследование, показывающее, насколько это плохо, когда у каждого профайлера своя точка зрения по поводу самого горячего метода в одной и той же рабочей нагрузке (Миткович и соавт., «Evaluating the Accuracy of Java Profilers»). Более того, если у вас есть 1000 тредов в сложном стеке вызовов Spring, часто собирать стек-трейсы не получится. Возможно, не чаще 10 раз в секунду. В результате ваши данные по стекам будут отличаться от фактической рабочей нагрузки ещё больше!
Решать такие проблемы непросто, но вкладываться стоит: некоторые рабочие нагрузки на проде невозможно профилировать, используя «традиционные» тулы вроде перечисленных выше.
Существует два раздельных подхода и один гибридный:
Профилирование в контейнерах
— К слову об окружениях, сейчас модно всё паковать в контейнеры, здесь есть какие-то особенности? О чём следует помнить, работая с контейнеризованными приложениями?
Саша Гольдштейн: С контейнерами возникают интересные проблемы, которые многие тулы полностью игнорируют и в результате вообще перестают работать.
Вкратце напомню, что контейнеры Linux построены вокруг двух ключевых технологий: группы контроля и пространства имён. Группы контроля позволяют увеличить квоту ресурсов для процесса или для группы процессов: CPU time caps, лимит памяти, IOPS хранилища и так далее. Пространства имён делают возможной изоляцию контейнера: mount namespace предоставляет каждому контейнеру свою собственную точку монтирования (фактически, отдельную файловую систему), PID namespace — собственные идентификаторы процессов, network namespace даёт каждому контейнеру собственный сетевой интерфейс и так далее. Из-за пространства имён множеству тулов сложно правильно обмениваться данными с контейнезированными JVM-приложениями (хотя некоторые из этих проблем свойственны не только JVM).
Прежде чем обсудить конкретные вопросы, будет лучше, если мы вкратце расскажем о разных видах observability тулов для JVM. Если вы не слышали о некоторых из них, самое время освежить ваши знания:
Мы хотели продолжить разговор и обсудить влияние железа на профилирование…
Совсем скоро Саша приедет в Санкт-Петербург, чтобы провести тренинг по профилированию JVM-приложений в продакшне и выступить на конференции Joker 2017 с докладом про BPF, поэтому, если вы хотите погрузиться в тему глубже – у вас есть все шансы встретиться с Сашей лично.
«Java-разработчики не осознают проблему с профайлерами»: Андрей Паньгин и Нитсан Вакарт о Java-профилировании
Легко подумать, что от профилирования не стоит ожидать больших новостей: поскольку разработчики профилируют уже десятилетиями, до чего там можно было ещё не додуматься? Но в Java-профилировании кроются серьёзные подводные камни вроде safepoint bias, и появляются новые инструменты для решения подобных проблем.
Мы решили поговорить с ними обоими сразу, начав разговор с последних новостей об async-profiler, а позже перейдя к состоянию Java-профилирования в целом.
JUG.ru: Недавно async-profiler был перемещён на GitHub из личного репозитория Андрея в “jvm-profiling-tools” — что представляет собой jvm-profiling-tools, и чем вызвано перемещение?
Нитсан: Это объединение нескольких репозиториев, преследующих схожие цели. Идея в том, чтобы собрать их в одном месте и стимулировать сообщество активнее их развивать.
Андрей: Именно. Когда стало понятно, что async-profiler интересен Java-сообществу, я решил его перенести в нейтральное место, потому как сторонним разработчикам порой некомфортно контрибьютить в чужой личный репозиторий.
Нитсан: В jvm-profiling-tools есть Honest Profiler, async-profiler и perf-map-agent, и они подходят к одной теме с разных сторон: perf-map-agent открывает возможности для профилирования с использованием линуксового perf, Honest Profiler использует AsyncGetCallTrace, что позволяет избежать safepoint bias, а async-profiler совмещает то и другое очень приятным образом.
Андрей: Да. На самом деле, в идее сочетания обоих подходов ничего космического нет, но почему-то никому в голову это раньше не приходило.
Нитсан: Вообще это было в Solaris Studio, но проблема Solaris Studio в том, что им пользуются человек 20 в мире.
Андрей: Но, насколько я знаю, он не показывает вызовы ядра, так ведь?
Нитсан: Показывает нативный код, но не ядро.
JUG.ru: Поскольку у Honest Profiler и async-profiler есть общее преимущество «отсутствие safepoint bias», теперь при взгляде на jvm-profiling-tools у новичков в профилировании может появиться вопрос: «Ну и какой из двух похожих инструментов мне использовать?» Что вы можете им сказать?
Андрей: Я считаю, что в отношении точности профилирования и полноты информации async-profiler далеко впереди. Ведь даже сам AsyncGetCallTrace в HotSpot работает не всегда: в некоторых пограничных случаях JVM не может восстановить стек-трейс, хотя async-profiler справляется и с такими ситуациями. Кроме того, Honest Profiler вообще не показывает нативные стек-трейсы. Но его большое преимущество в инфраструктуре вокруг представления данных. Он умеет отображать результаты красиво, у него есть UI, а async-profiler — это просто Java-агент, запускаемый из консоли.
Нитсан: Я думаю, что будущее за async-profiler. И мне бы хотелось, чтобы некоторые возможности Honest Profiler попали в async-profiler. Есть ещё разница в том, что Honest Profiler работает на macOS, а async-profiler пока нет: поддерживать большое сообщество хипстеров в нашей отрасли — это важно.
JUG.ru: Вроде бы Вадим Цесько из Одноклассников уже делал возможной работу async-profiler на macOS?
Андрей: Это было до того, как я добавил поддержку perf events. Linux-специфичный вызов сломал поддержку macOS. Но есть и хорошие новости: буквально на днях я разговаривал с Норманом Маурером из Apple (автором Netty), ему также интересен async-profiler, и он любезно согласился сделать Mac-порт.
JUG.ru: В июле в async-profiler появился профайлер хипа — можете рассказать об этом?
Андрей: Существует два основных подхода к профилированию памяти в Java. Первый — это инструментация байткода. Но для продакшен-систем он ужасен, потому что плачевно сказывается на производительности. Ряд оптимизаций компилятора перестаёт работать: прежде всего, Escape Analysis больше не помогает избегать аллокаций в хипе.
Другой подход — использование DTrace probes, что тоже крайне накладно, и может включаться только на старте JVM.
Но это не всё. Есть ещё гораздо более эффективный подход, основанный на сэмплировании TLAB (Thread Local Allocation Buffer). Он реализован в Java Mission Control / Java Flight Recorder, но требует включения коммерческих функций Oracle JDK, а с OpenJDK вообще не работает. Похожий метод используют внутри Google, но там требуется сборка модифицированной версии JVM.
Я нашёл способ использовать этот подход без подключения платных функций, в том числе, с OpenJDK. Сейчас не буду погружаться в подробности, но в отдельном докладе обязательно расскажу.
Нитсан: Я думаю, это важно. Поскольку Java Mission Control сейчас, пожалуй, единственный инструмент для профилированием аллокаций, и работа с подобными процессами в JMC реализована очень своеобразно, многие люди просто не занимаются таким профилированием. Надеюсь, что это поможет профилированию аллокаций стать мейнстримом.
JUG.ru: Может показаться странным, что заметные подвижки в профилировании происходят в 2017-м, когда они были бы полезны годы назад. В чём причина такой задержки?
Андрей: Java — корень всех зол 🙂 Она делает жизнь одновременно и лучше, и хуже. С одной стороны, из-за особенностей JVM стандартные подходы становятся неприменимы, но с другой — JVM предоставляет свои собственные API для профилирования.
Нитсан: Я думаю, что мир Java похож на Windows. Windows была ужасной ОС (вероятно, сейчас куда лучше), но, страдая от многих недостатков, она одновременно имела большой успех. Та же история и с Java. В случае с инструментами профилирования у Java получилось плохо. Я не совсем уверен в том, почему это так.
Я думаю, что разработчики JVM традиционно использовали Solaris Studio, так что всё более-менее нормально работало, но только для них. Специалисты использовали специализированные инструменты. А большинство Java-разработчиков были довольны тем, что имели.
Но теперь Java пришлось столкнуться с реальностью. Нативное профилирование, которое работало в Solaris Studio, но тогда было нишевым решением, становится все более популярным.
Андрей: Считаю нужным добавить, что Java не равно HotSpot, и другие JVM могут быть более дружелюбны к профайлерам.
Нитсан: Может быть, я что-то упустил, но о какой JVM мы говорим? Я знаю много о Zing, и у меня есть немного опыта работы с IBM J9…
Андрей: Сейчас на мне футболка Excelsior JET, и поэтому я вспомнил об этом проекте. Он умеет прекомпилировать Java в нативный код, и, насколько я знаю, от safepoint bias не страдает.
Нитсан: А, ок. Никогда этим не пользовался. Полагаю, что в этом случае можно сразу брать нативный профайлер.
JUG.ru: AsyncGetCallTrace, который используют async-profiler и Honest Profiler, не является официальным API. Не ощущается ли его использование «хаком»? Не беспокоитесь ли, что в будущем он может перестать функционировать? Помогла бы более официальная поддержка Oracle в вопросах профилирования?
Нитсан: AsyncGetCallTrace работает ещё с запуска OpenJDK 6, так что похоже, что он всегда был и будет работать. Это «незаконнорожденный ребенок», но я не думаю, что его могут взять и выкинуть. Когда что-либо становится опцией JVM, это в некотором роде получает официальную поддержку. Так что думаю, нам не стоит слишком беспокоиться об этом. Хотя мне интересно, насколько хорошо AsyncGetCallTrace уживается с новым компилятором Graal.
Конечно, более официальная поддержка помогла бы. На данный момент Oracle предоставляет JMC в качестве платного варианта, а всему остальному Java-миру остаётся что-то вроде VisualVM. Сейчас в этом деньги. Я думаю, что Oracle испытывает конфликт интересов: интересы Java, с одной стороны, и их собственные — с другой. Можно сказать, что для них поспособствовать улучшению других JVM-профайлеров означало бы ухудшить собственное положение.
Я не утверждаю, что они активно переживают из-за этого. Я понятия не имею, чего они сейчас хотят. Возможно, они сделают доступными для всех вещи вроде JMC. Теперь, когда работа над Jigsaw закончена, у них есть много времени для другого.
Андрей: Соглашусь, что AsyncGetCallTrace — отчасти «хакерский» API. К тому же далеко не идеальный: я и сам сообщал о багах. Но пока что это лучшее, что есть в HotSpot JVM.
JUG.ru: А может ли, помимо уже имеющихся вещей вроде AsyncGetCallTrace, появиться что-то ещё, что облегчит жизнь создателям профайлеров?
Андрей: Да. Недавно в списках рассылки HotSpot обсуждалось профилирование аллокаций. В итоге даже появился проект JEP, который предлагает новый стандартизованный API для сэмплирования хипа. Думаю, что поднимать такие темы в рассылках и предлагать JEP — правильный путь. Так что, возможно, когда-нибудь в Java 11…
JUG.ru: Что вы думаете о будущем Java-профилирования независимо от действий Oracle? Профайлеры станут намного лучше, чем сейчас?
Андрей: Очень на это надеюсь. В своих докладах я стараюсь доносить до разработчиков мысль, что у профайлеров, которые они используют сейчас, есть большие подводные камни. Нужно либо прекратить использовать их, либо как следует разобраться в их недостатках и ловушках. И думаю, когда больше людей осознают масштабы проблемы, разработчики этих инструментов примутся их улучшать.
Нитcан: В ряде вопросов есть куда расти. С perf-map-agent мы обрели возможность отслеживать инлайнинг при профилировании, но перейдя к async-profiler, снова её теряем. Мне бы очень хотелось увидеть её снова воплощённой.
Другая область — визуализация. Если использовать async-profiler при работе с многопоточными приложениями, где один поток задействует 100% CPU, а все остальные просто висят в ожидании, при профилировании можно получить сбивающую с толку картину. Меня интересуют проблемы представления данных, и я уверен, что существует множество подобных проблем.
Андрей: Да. Сегодня FlameGraph очень популярен в качестве визуализации, но я бы сказал, что он далеко не совершенен.
JUG.ru: Вы оба уже говорили (в докладах и блог-постах), что профайлеры могут создавать искажённую картину. Считаете ли вы, что отрасли сильно вредит использование людьми этой искажённой картины? Может ли быть так, что индустрии от профайлеров тогда вообще больше вреда, чем пользы?
Нитсан: Да, я думаю, что это вредит индустрии. Если вы посмотрите в интернете обсуждения производительности Java, то увидите, что там полно булшита. И причина, по которой его так много, в том, что информацию сложно верифицировать.
Некоторые люди говорили мне, что проблема никогда не оказывается в HashMap. И причина, по которой они никогда не думали, что HashMap может быть проблемой, состоит в том, что обычный профайлер им этого никогда не покажет. Я не утверждаю, что конкретно в их случае проблема в нём, но как бы то ни было, они об этом никогда не узнают. А когда они смотрят на график расхода времени CPU, они не могут увидеть время, затраченное на GC. То есть в том случае, если «бутылочным горлышком» у них оказался GC, они никак не смогут этого отследить.
Андрей: Я согласен с Нитсаном, но добавлю, что лучше иметь хотя бы плохой инструмент, чем не иметь никакого. Главная проблема — не когда профайлер привирает, а когда он не используется совсем. Многие разработчики вообще не профилируют, хотя зачастую проблема производительности кроется в неэффективных алгоритмах, и любой сэмплирующий профайлер её легко выявит.
Нитсан: Я согласен, что многие люди не профилируют, и это проблема. Но если единственным вашим инструментом оказывается плохой профайлер… Вы смотрите на него, видите, что он выдаёт какую-то бессмыслицу, и говорите остальным: «Лучше мы будем просто ставить временные метки», таким у вас получается вывод, и несложно понять, как подобное отбивает у людей желание использовать профайлеры.
JUG.ru: Значит, чтобы улучшить ситуацию с Java-профилированием, нам всем надо работать не только над улучшением инструментов, но и над знаниями сообщества о них?
Нитсан: Да. Я думаю, масштабная история успеха в Java-мире — это JMH, Java Microbenchmarking Harness. И причина в том, что это решение было очень успешным не только с технологической точки зрения, но и в аспекте обучения пользователей, предоставления им возможности лучше познакомиться с этой областью.
Думаю, то, что Андрей и создаёт инструменты, и рассказывает людям, очень важно.
Андрей: Даже самые мощные инструменты будут бесполезны, если не уметь ими пользоваться. С тем же JMH: я много раз видел, как люди писали ерунду в JMH, а потом делали совершенно неправильные выводы. Обучение является неотъемлемой частью успеха.
JUG.ru: Вы оба собираетесь помочь этому обучению своими докладами на ближайшем Joker, и вы оба собираетесь представить там новые версии докладов, ранее представленных на других конференциях. В чём будет состоять новизна?
Нитсан: После того, как я представил на QCon доклад “Profilers are lying hobbitses”, я подумал, что самое лучшее в нём — это название. Поэтому я решил сохранить название, но сам доклад будет очень сильно отличаться. Мы снова будем говорить о профайлерах и о том, как они могут ввести нас в заблуждение, но, думаю, я начну с самого мрачного, а затем буду показывать, как выкарабкаться. В прошлом доклад был серией сюрпризов, приводивших к выводу «ничего не работает». В этот раз будет так: «ничего не работает, но посмотрим, как нам с этим справиться».
Андрей: Изначально я планировал показать продолжение истории async-profiler, начатой на JPoint 2017. Однако потом мы с Программным Комитетом обнаружили большое сходство моего доклада с докладом Нитсана, так что я решил взять новую тему. Пока что я не готов сказать, что именно это будет, но в ближайшее время в программе Joker 2017 можно будет увидеть мой новый доклад! Так что следите за обновлениями.
Java-конференция Joker, где выступят Нитсан и Андрей, состоится в Петербурге 3-4 ноября. Как обычно, после докладов спикеры Joker оказываются в дискуссионных зонах, так что там можно будет расспросить их о профилировании лично. А помимо Андрея и Нитсана, там будут десятки других спикеров — на сайте конференции можно увидеть программу (и приобрести билет).