Ещё раз: проблема не в конкретных цифрах, а в том, что они означают совсем не то, что читатель предполагает. Вы пишете, что «парсер на ANTLR занимает столько-то», и логично предполагать, что там «парсер+необходимая ANTLR обвязка».
А по факту же, вы туда вкладываете свои commons (которые занимают половину результитрующего jar), log4j, commons-lang и далее по списку.
1) А зачем в зависимостях указывать <artifactId>antlr4</artifactId>, когда во время выполнения достаточно <artifactId>antlr4-runtime</artifactId>?
2) Зачем в jar-with-dependencies включать junit и hamcrest, ведь они только для тестов нужны? Зачем в измеряемый jar включать log4j и commons-lang3, которые вообще не используются в коде? Измерять нужно не jar-with-dependencies, а результат работы maven-shade-plugin'а. Либо оставляйте только реально нужные зависимости. Если всю эту ерунду удалить, то получается где-то 1 мегабайт.
3) Если удалить и yk/jcommon, то получается похоже на результат KvanTTT
Если бы речь шла о скорости работы SQL запроса в enterprise приложении, то, да, её можно и без JMH измерить. А тут наоборот: JMH проще, быстрее и точнее.
1) Вообще говоря, «производительность» автор объявляет первым требованием
2) В JMH без проблем можно измерять «холодный старт». И измерять это можно более полно, т.к. в JMH есть встроенный механизм Forks — будут запускаться отдельные Java машины
3) Код на JMH гораздо компактнее, чем «рукописный». В итоге, человеку со стороны проверить гораздо проще
4) В JMH встроено много разнообразных профайлеров. Автор приводит цифры без какого-либо анализа того *почему* цифры именно такие
1) 21-ый век на дворе, а JMH почему-то не пахнет. Как так? Набросал замер на JMH — получается, что IntelliJ парсер в 4 раза быстрее чем JavaCC.
2) GaugeKotlinIntellijParser зачем-то пересоздаёт окружение при каждом парсинге. Зачем так? Его же переиспользовать можно и нужно.
3) yk.jcommon.utils.IO#readFile(java.lang.String) не закрывает файл
Наверняка, я видел далеко не все нагрузочные тесты в Netcracker, но Gatling наблюдать не приходилось. Полагаю, дело в том, что, в подавляющем большинстве случаев, нам миллионы запросов в секунду не нужны. В JMeter'е более-менее пишутся сложные тесты (зайти туда-то, нажать такую-то кнопку и т.п.), и порог вхождения невелик.
Зависит от проекта, но сам по себе браузерный тест приходится использовать тогда, когда нужно измерить время работы end-to-end (довольно часто хватает отдельного тестирования серверной части и сбора базовых метрик с QA).
Selenium в нагрузке используется в двух вариациях:
1) Основную нагрузку подаём JMeter'ом, а Selenium запускаем в штучном количестве. При этом backend загружен на должном уровне, из Selenium'а получаем времена работ браузера (с учётом всех JS/CSS), и не требуется держать огромный ботнет этих самых Selenium'ов. Понятие «огромный», конечно, растяжимо, поэтому я под ним понимаю «более 1-2 браузеров».
2) Нагрузку подаём армией из Selenium'ов. Тут требуется больше нагрузочных машин чем в варианте №1, но при этом мы получаем больше данных за ту же длительность тестирования. Больше размер выборки — больше точность, и больше выбросов мы можем поймать.
Как строится тест?
В чём вопрос? Тест либо пишется специально (наиболее востребованный и/или подозрительный в плане производительности), либо адаптируется имеющийся функциональный. Как правило, в функциональных тестах много разнообразных проверок, которые в нагрузке не столь важны, поэтому 1-в-1 брать не получается.
А какой процент unit-test'ов (я про официальные Kotlin тесты) проходит этот парсер?
Например, JavaCC парсер считает, что -789 относится к определению переменной
x, хотя это, очевидно, не так:fun getResult() {val x = 123 + 456
- 789
}
Ясно как: никому и в голову не придёт, что вы, помимо необходимого, в jar включаете десяток-другой абсолютно лишних зависимостей.
А по факту же, вы туда вкладываете свои commons (которые занимают половину результитрующего jar), log4j, commons-lang и далее по списку.
<artifactId>antlr4</artifactId>, когда во время выполнения достаточно<artifactId>antlr4-runtime</artifactId>?2) Зачем в jar-with-dependencies включать junit и hamcrest, ведь они только для тестов нужны? Зачем в измеряемый jar включать log4j и commons-lang3, которые вообще не используются в коде? Измерять нужно не jar-with-dependencies, а результат работы maven-shade-plugin'а. Либо оставляйте только реально нужные зависимости. Если всю эту ерунду удалить, то получается где-то 1 мегабайт.
3) Если удалить и yk/jcommon, то получается похоже на результат KvanTTT
1) Вообще говоря, «производительность» автор объявляет первым требованием
2) В JMH без проблем можно измерять «холодный старт». И измерять это можно более полно, т.к. в JMH есть встроенный механизм Forks — будут запускаться отдельные Java машины
3) Код на JMH гораздо компактнее, чем «рукописный». В итоге, человеку со стороны проверить гораздо проще
4) В JMH встроено много разнообразных профайлеров. Автор приводит цифры без какого-либо анализа того *почему* цифры именно такие
2) GaugeKotlinIntellijParser зачем-то пересоздаёт окружение при каждом парсинге. Зачем так? Его же переиспользовать можно и нужно.
3) yk.jcommon.utils.IO#readFile(java.lang.String) не закрывает файл
Если интересно, могу рассказать об этом на https://heisenbug-moscow.ru/ 8-9 декабря
Selenium в нагрузке используется в двух вариациях:
1) Основную нагрузку подаём JMeter'ом, а Selenium запускаем в штучном количестве. При этом backend загружен на должном уровне, из Selenium'а получаем времена работ браузера (с учётом всех JS/CSS), и не требуется держать огромный ботнет этих самых Selenium'ов. Понятие «огромный», конечно, растяжимо, поэтому я под ним понимаю «более 1-2 браузеров».
2) Нагрузку подаём армией из Selenium'ов. Тут требуется больше нагрузочных машин чем в варианте №1, но при этом мы получаем больше данных за ту же длительность тестирования. Больше размер выборки — больше точность, и больше выбросов мы можем поймать.
В чём вопрос? Тест либо пишется специально (наиболее востребованный и/или подозрительный в плане производительности), либо адаптируется имеющийся функциональный. Как правило, в функциональных тестах много разнообразных проверок, которые в нагрузке не столь важны, поэтому 1-в-1 брать не получается.