Здравствуйте, зиг, Вы писали:
зиг>Какой у нас сейчас самый кошерный способ замера времения выполнения некоего метода? зиг>Гуглится многое конечно, но что-то много всего, а главное еще всё какое-то старое, типа вот вопрос 2010го года: https://stackoverflow.com/questions/3382954/measure-execution-time-for-a-java-method
зиг>А хотелось бы что-то а-ля 2019. Например, пользовался ли кто-то неким datadog, как оно?
Смотря какие задачи и контекст.
Можно через https://github.com/dropwizard/metrics — добавляя аннотации в код и собирая потом статистику.
Можно через аспекты спринга.
Можно через анализ логов через какой-нибудь ELK или Splunk или ClickHouse или вообще awk.
Если нужно для микробенчмарков — то там свой отдельный мир с JMH во главе.
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Смотря какие задачи и контекст. ДФ>Можно через https://github.com/dropwizard/metrics — добавляя аннотации в код и собирая потом статистику. ДФ>Можно через аспекты спринга. ДФ>Можно через анализ логов через какой-нибудь ELK или Splunk или ClickHouse или вообще awk.
ДФ>Если нужно для микробенчмарков — то там свой отдельный мир с JMH во главе.
ДФ>Какая цель?
ну например узнавать сколько времени заняла некая операция. например процессится набор каких-нибудь разнотиповых штук. и нужно узнать сколько занял суммарный процессинг штук типа 1, типа 2 и т.д.
И потом узнать как быстро сработало то же самое на продакшне. Чтоб потом сравнить не ухудшилось ли например
По логам это что-то нереально, ну точнее можно наверное. Но может проще что-то есть
Здравствуйте, зиг, Вы писали:
зиг>Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>>Смотря какие задачи и контекст. ДФ>>Можно через https://github.com/dropwizard/metrics — добавляя аннотации в код и собирая потом статистику. ДФ>>Можно через аспекты спринга. ДФ>>Можно через анализ логов через какой-нибудь ELK или Splunk или ClickHouse или вообще awk.
ДФ>>Если нужно для микробенчмарков — то там свой отдельный мир с JMH во главе.
ДФ>>Какая цель? зиг>ну например узнавать сколько времени заняла некая операция. например процессится набор каких-нибудь разнотиповых штук. и нужно узнать сколько занял суммарный процессинг штук типа 1, типа 2 и т.д. зиг>И потом узнать как быстро сработало то же самое на продакшне. Чтоб потом сравнить не ухудшилось ли например зиг>По логам это что-то нереально, ну точнее можно наверное. Но может проще что-то есть
Тогда Metrics, он умеет и персентали строить, насколько я помню (а без них оценки смысла особого не имеют)
По логам тоже не сложно, если логи не в файликах, а в какой-нибудь нормальный аггрегатор идут. Но, впрочем, мы и на файликах строили такую аналитику, awk вполне рулит )
Главное — не писать все эти жуткие выдачи в консоль )
А, еще можно включить на проде отладчик, в нем подобные данные тоже можно вытащить )
Это утверждение очень спорное. Да по вашей ссылке автор показывает как HdrHistogram уделывает DropwizardMetrics в способности точно отображать измерения близко к моменту снятия снапшота. Однако он умалчивает, что свои трюки он проделывает вовсе не на стоковой HdrHistogram. В статье используется гистограммы из библиотеки RollingMetrics, которая позиционируется просто как набор дополнительных алгоритмов мониторинга для DropwizardMetrics.
Ежели взять просто сырую HdrHistogram, то она из коробки будет следовать за временным трендом хуже чем любая релиазация резервуара для DropwizardMetrics, из-за отсутствия понятия Retention Policy вообще как класса, и чтобы получить внятный результат придётся накручивать велосипеды по сбрасыванию записанных измерений самостоятельно.
Война за свободу библиотек до полного уничтожения диктатуры фреймворков!
Здравствуйте, vsb, Вы писали:
vsb>Я так меряю: vsb>
vsb>long start = System.currentTimestamp();
vsb>call();
vsb>long end = System.currentTimestamp();
vsb>System.out.println("call took " + (end - start));
vsb>
счастливые микросекунд не наблюдают, как впрочем и вызовов закончившихся эксепшенами, если ещё приложению и 24/7 работать не нужно, то прям идеальное место работы чтобы встретить пенсию, главное использовать NTP и время руками на сервере не переводить, чтобы не видеть отрицательной латенси в логах.
Война за свободу библиотек до полного уничтожения диктатуры фреймворков!
Здравствуйте, vimba, Вы писали:
SK>>Лушче HDRHistogram пока ничего не придумали. SK>>https://medium.com/hotels-com-technology/your-latency-metrics-could-be-misleading-you-how-hdrhistogram-can-help-9d545b598374
V>Это утверждение очень спорное. Да по вашей ссылке автор показывает как HdrHistogram уделывает DropwizardMetrics в способности точно отображать измерения близко к моменту снятия снапшота. Однако он умалчивает, что свои трюки он проделывает вовсе не на стоковой HdrHistogram. В статье используется гистограммы из библиотеки RollingMetrics, которая позиционируется просто как набор дополнительных алгоритмов мониторинга для DropwizardMetrics.
Что тут спорного? Что ее можно присобачить к это хипстеркой обертке DropwizardMetric как-то умеляет ее достоиства? Скрипя сердцем вынужден согласиться, что лушче бы без DropwizardMetric
Если серьезно, то Dropwizard еще те буратины, они появились до HdrHistogram и когда HdrHistogram появилась еще долго не могли ее добавить. Не уверен, что в итоге и добавили. В реальность это единственный резервуар, который имеет смыл, остальные подходят только для графиков в PowerPoint.
V>Ежели взять просто сырую HdrHistogram, то она из коробки будет следовать за временным трендом хуже чем любая релиазация резервуара для DropwizardMetrics, из-за отсутствия понятия Retention Policy вообще как класса, и чтобы получить внятный результат придётся накручивать велосипеды по сбрасыванию записанных измерений самостоятельно.
HdrHistogram она не про сброс результатов. Конечно его там не будет, как не будет в каком-нить TreeMap автоматического удаления самого "маленького" ключа, для этого надо будет вызвать метод.
Понятие же "Retention Policy" в данном случае настолько тривиально (как и его реализация), что говорить, что это фича просто язык не поворачиватеся.
HdrHistogram это про то как храняться данные и как компенсируется их отсутсвтие, и статья как раз об этом.
Здравствуйте, StanislavK, Вы писали:
SK>Что тут спорного? Что ее можно присобачить к это хипстеркой обертке DropwizardMetric как-то умеляет ее достоиства? Скрипя сердцем вынужден согласиться, что лушче бы без DropwizardMetric
Без дефолтных реализаций гистограмм от Dropwizard да лучше, не одна из них не подходит для реального продакшена, поэтому все пишут свои реализации. Однако достоинства HdrHistogram тоже не стоит преувеличивать, уникального в ней только то, что математическая модель позволяет оперировать точностью в десятичных знаках, что очень понятно человечиским человекам, а вот идея разделить всё множество возможных значений на отрезки и вместо хранения отдельно взятых значений по одиночке инкрементировать число попаданий в конкретный отрезок и избавится с этой помощью о проклятия сэмплирования вовсе не уникальна. В тех же гистограмках от Netflix Spectator она успешно применена, и как показывает практика Cassandra — любой дятел даже не разбирающийся в пакете java.math и битовых операциях может быстро наколхозить решение просто заранее запомнив границы интервалов в массиве и вычислять интервал для измерения простым binary search.
Спорное же ваше утверждение об абсолютном доминировании HdrHistogram по следующей причине: Решение не уникально, есть аналоги, как минимум у Netflix Spectator.
API у HdrHistogram ни разу не очевидный, достаточно посмореть чудовищное количество закрытых багов в имени которых есть ArrayIndexOutOfBoundsException или ConcurrentModificationException. И если обратите внимание на следующую строчку кода в статье withHighestTrackableValue(120000, OverflowResolver.REDUCE_TO_HIGHEST_TRACKABLE) автор обёртки RollingMetrics поправил кривизну обязав пользователя предоставлять реакцию для случая когда он пихает в гистограмму значение выше прогнозируемого максимума. Говорить о доминировании мониторинг библиотеки которая кидает ошибку при записи измерений нельзя, это точно такой же нонсенс как восхвалять библиотеку логирования, которая может при записи в лог кинуть в юзера эксепшен.
Библиототеки вроде Netflix Spectator, Spring Micrometer, Dropwizard Metrics решают проблему в комплексе, решая также проблемы экспорта во всевозможные timeseries БД, взяв сырую HdrHistogram вы рискуете потратить время(пусть и небольшое) на интеграцию ежа с ужом.
В общем я бы резюмировал что в java c подсчетом латенси явного лидера нет. У Spectator и Micrometer тоже свои проблемы
SK>Если серьезно, то Dropwizard еще те буратины, они появились до HdrHistogram и когда HdrHistogram появилась еще долго не могли ее добавить. Не уверен, что в итоге и добавили. В реальность это единственный резервуар, который имеет смыл, остальные подходят только для графиков в PowerPoint.
И до сих пор не добавили. И я думаю не добавят еще долгое время пока не поймут, что сэмплирование это путь в никуда. Да что там дропвизард, я недавно в Дойче Банк ходил на собеседование, люди тоже удивились когда я им сообщил, что можно запомнить все измерения не зависимо от их количиства.
SK>HdrHistogram она не про сброс результатов. Конечно его там не будет, как не будет в каком-нить TreeMap автоматического удаления самого "маленького" ключа, для этого надо будет вызвать метод. SK>Понятие же "Retention Policy" в данном случае настолько тривиально (как и его реализация), что говорить, что это фича просто язык не поворачиватеся.
Угу, тривиально.
Это смотря для кого тривиальная, для многих моих текущих коллег это будет нетривиальная задача, а для коллег с предидущих мест работы просто от API и исходного кода HdrHistogram будет реакция как-будто в глаза кислотой брызнули. И факт того, что задача тривиальная ещё не отменяет необходимости её решения, каждый кто возьмет HdrHistogram будет вынужден её решить.
SK>HdrHistogram это про то как храняться данные и как компенсируется их отсутсвтие, и статья как раз об этом.
Нет, про Coordinated omission в статье вообще ничего нет. Да и про то как данные хранятся внутри то же ничего нет. Статья про то как круто взять HdrHistogram и получить на выходе статистику которая наголову лучше(быстрее) реагирует за изменениями в потоке измерений, чем гистограммы от Dropwizard. Тут только одна проблемка следование за временным трендом это не свойство HdrHistogram, автор получил это плюшку за счёт third-party обертки RollingMetrics.
Война за свободу библиотек до полного уничтожения диктатуры фреймворков!
Здравствуйте, vimba, Вы писали: SK>>Что тут спорного? Что ее можно присобачить к это хипстеркой обертке DropwizardMetric как-то умеляет ее достоиства? Скрипя сердцем вынужден согласиться, что лушче бы без DropwizardMetric V>Без дефолтных реализаций гистограмм от Dropwizard да лучше, не одна из них не подходит для реального продакшена, поэтому все пишут свои реализации. Однако достоинства HdrHistogram тоже не стоит преувеличивать, уникального в ней только то, что математическая модель позволяет оперировать точностью в десятичных знаках, что очень понятно человечиским человекам, а вот идея разделить всё множество возможных значений на отрезки и вместо хранения отдельно взятых значений по одиночке инкрементировать число попаданий в конкретный отрезок и избавится с этой помощью о проклятия сэмплирования вовсе не уникальна. В тех же гистограмках от Netflix Spectator она успешно применена, и как показывает практика Cassandra — любой дятел даже не разбирающийся в пакете java.math и битовых операциях может быстро наколхозить решение просто заранее запомнив границы интервалов в массиве и вычислять интервал для измерения простым binary search.
Уникальна она не идеей, а тем как она реальзована. "любой дятел" именно, что наколхозит и остальные библиотеки тому пример.
Вот возмем Netflix Spectator. Они явно не такие буратины как Dropwizard, реально постарались, но все равно как HdrHistogram по перфомансу не получается:
Тест
private long shift = 0;
@Threads(1)
@Benchmark
public void percentileTimerReuseSpectator() {
// shift allows to spread values, hopefully it will force usage of different buckets.
int start = 1 << (++shift%20);
int end = start + 10_000;
for(int i = start; i != end; ++i) {
percentileTimerCached.record(i, TimeUnit.MICROSECONDS);
}
}
@Threads(1)
@Benchmark
public void percentileTimerReuseHDR() {
// shift allows to spread values, hopefully it will force usage of different buckets.
int start = 1 << (++shift%20);
int end = start + 10_000;
for(long i = start; i != end; ++i) {
histogram.recordValue(i);
}
}
И это еще на батарейке на лаптопе, где все плавает как черт знает, что. Даже тут видно, что велосипед от Netflix в разы медленнее.
Кстати, отдельно стоит отметить их перфоманс тесты, где они пишут одно и то же значение — при таком раскладе даже самое говно заоптимизируется. V>Решение не уникально, есть аналоги, как минимум у Netflix Spectator.
Не аналог — см. тесты. Мне еще там не понравилось, что они там бакеты статически выделяют, независимо от интервала значений. Но там порыться надо, тесты погонять, пока не пойму что там к чему. V>API у HdrHistogram ни разу не очевидный, достаточно посмореть чудовищное количество закрытых багов в имени которых есть ArrayIndexOutOfBoundsException или ConcurrentModificationException. И если обратите внимание на следующую строчку кода в статье withHighestTrackableValue(120000, OverflowResolver.REDUCE_TO_HIGHEST_TRACKABLE) автор обёртки RollingMetrics поправил кривизну обязав пользователя предоставлять реакцию для случая когда он пихает в гистограмму значение выше прогнозируемого максимума. Говорить о доминировании мониторинг библиотеки которая кидает ошибку при записи измерений нельзя, это точно такой же нонсенс как восхвалять библиотеку логирования, которая может при записи в лог кинуть в юзера эксепшен.
У всех есть баги. Весь вопрос в том как их много и как часто они всплывают. У меня с HdrHistogram проблем не было, много лет пользую. V>Библиототеки вроде Netflix Spectator, Spring Micrometer, Dropwizard Metrics решают проблему в комплексе, решая также проблемы экспорта во всевозможные timeseries БД, взяв сырую HdrHistogram вы рискуете потратить время(пусть и небольшое) на интеграцию ежа с ужом.
Прежде всего они должны правильно измерять. Остальное уже опциональные плюшки. V>В общем я бы резюмировал что в java c подсчетом латенси явного лидера нет. У Spectator и Micrometer тоже свои проблемы
Я бы сказал, что там вариантов нет. Если надо мерить — HdrHistogram, если нужны плюшки и обертки, то, наверно, да можно посмотреть, что-нить еще. V>я недавно в Дойче Банк ходил на собеседование, люди тоже удивились когда я им сообщил, что можно запомнить все измерения не зависимо от их количиства.
Это правда, можно. И правда, что много кто не верит. V>Угу, тривиально. V>Это смотря для кого тривиальная, для многих моих текущих коллег это будет нетривиальная задача, а для коллег с предидущих мест работы просто от API и исходного кода HdrHistogram будет реакция как-будто в глаза кислотой брызнули. И факт того, что задача тривиальная ещё не отменяет необходимости её решения, каждый кто возьмет HdrHistogram будет вынужден её решить.
Да таким и мерить-то не надо, там счет на минуты идет SK>>HdrHistogram это про то как храняться данные и как компенсируется их отсутсвтие, и статья как раз об этом. V>Нет, про Coordinated omission в статье вообще ничего нет. Да и про то как данные хранятся внутри то же ничего нет. Статья про то как круто взять HdrHistogram и получить на выходе статистику которая наголову лучше(быстрее) реагирует за изменениями в потоке измерений, чем гистограммы от Dropwizard. Тут только одна проблемка следование за временным трендом это не свойство HdrHistogram, автор получил это плюшку за счёт third-party обертки RollingMetrics.
Да, правда, Coordinated omission нет. Че-то мне показалось в любой статье это должно быть
