Comments 8
спасибо достаточно полезная статья.
От себя немного добавлю не совсем по теме, но может кому будет полезно.
Jenkins сервер CI имеет Performance plugin и через него можно интенрировать Jmeter в процесс построения билдов в среде непрерывной интеграции. Тогда на каждый билд можно запускать некоторый набор jmeter тестов в том числе нагрузочных и валить билд если код не работает достаточно быстро или некорректно.
Да, я понимаю что это достаточно много работы и муторно, но поверьте мне, оно того стоит.
От себя немного добавлю не совсем по теме, но может кому будет полезно.
Jenkins сервер CI имеет Performance plugin и через него можно интенрировать Jmeter в процесс построения билдов в среде непрерывной интеграции. Тогда на каждый билд можно запускать некоторый набор jmeter тестов в том числе нагрузочных и валить билд если код не работает достаточно быстро или некорректно.
Да, я понимаю что это достаточно много работы и муторно, но поверьте мне, оно того стоит.
Хотелось бы дополнительно уточнить по поводу производительности BeanShell своим опытом:
Имеется:
1. jboss jbpm (количество воркеров больше 30ки)
2. бизнес процесс в котором некоторые состояния и условия написаны на BeanShell
3. пару тысяц процессов на выполнение
Вопрос: где будет затык?
Оказалось, что в BeanShell, но отнють не скорость его работы как «интерпретатора», так как жизненный цикл скрипта выглядит примерно так:
1. берем скрипт
2. разбираем и компилим его в валидный class файл
3. отправляем на выполнение
и вот пункт 2 оказывается проходит через синглтон, то есть выполнение еще можно в несколько потоков, а вот компилироваться у вас будет в 1 поток, а остальные будут стоять курить.
Так что сам BeanShell быстрый, а вот большое количество разнородных небольших скриптов положит ваше нагрузочное тестирование в 2 счета.
Имеется:
1. jboss jbpm (количество воркеров больше 30ки)
2. бизнес процесс в котором некоторые состояния и условия написаны на BeanShell
3. пару тысяц процессов на выполнение
Вопрос: где будет затык?
Оказалось, что в BeanShell, но отнють не скорость его работы как «интерпретатора», так как жизненный цикл скрипта выглядит примерно так:
1. берем скрипт
2. разбираем и компилим его в валидный class файл
3. отправляем на выполнение
и вот пункт 2 оказывается проходит через синглтон, то есть выполнение еще можно в несколько потоков, а вот компилироваться у вас будет в 1 поток, а остальные будут стоять курить.
Так что сам BeanShell быстрый, а вот большое количество разнородных небольших скриптов положит ваше нагрузочное тестирование в 2 счета.
Лично у меня сейчас нет таких бизнес-процессов, которые могут положить синглтон-компайлер. Кроме того, если проблема в пропуской способности именно его, то просто давайте мы разделим бизнес-процессы. Я подозреваю что большое кол-во скриптов как раз из-за этого, я правильно понимаю? Причем БП можно раскинуть по разным JVM с jmeter. Это один из вариантов ухода от проблемы.
Но даже при создании тест-плана одного бизнес-процесса мы можем совершенно по-разному использовать эти сценарии. А если у нас несколько схожих БП, то мы их можем обрабатывать вместе, в одном beanshell скрипте, используя, например, асинхронные тест-планы.
>Так что сам BeanShell быстрый, а вот большое количество разнородных небольших скриптов положит ваше нагрузочное тестирование в 2 счета.
Для создания прототипов, для быстрого написания, я бы рекомендовал именно beanshell, а для производительности пользоваться православным способом.
Но даже при создании тест-плана одного бизнес-процесса мы можем совершенно по-разному использовать эти сценарии. А если у нас несколько схожих БП, то мы их можем обрабатывать вместе, в одном beanshell скрипте, используя, например, асинхронные тест-планы.
>Так что сам BeanShell быстрый, а вот большое количество разнородных небольших скриптов положит ваше нагрузочное тестирование в 2 счета.
Для создания прототипов, для быстрого написания, я бы рекомендовал именно beanshell, а для производительности пользоваться православным способом.
Ну вот про BPEL, честно, ничего сказать не могу. В свое время мне предложили работу по данной тематике, но ушел в другое место. Кстати когда предлагали, условием было использование LoadRunner.
Просто использовать в Beanshell java фреймворк на самом деле не круто. Именно поэтому пришлось столько компилировать. Можно было бы сделать удобные ручки, скомпилировать их разок, т.е. фактически сделать обвязку и потом дергать их через beanshell. Но выбор за вами. Я бы на вашем месте писал полноценные семплеры.
>Для нагрузочного тестирования уже приходилось пару раз подымать независимые jmeter, так как бывало что подвисали отдельные треды, несколько jmeter с меньшим количеством потоков работали хорошо.
Тут нужно смотреть что за нити висели, и кто был виноват. Возможно даже одну JVM можно было потюнить до необходимого уровня производительности.
Поднять несколько JVM это простой уход от проблемы, а посмотреть что внутри JVM, вот это оказаться трудоемкой, но стоящей задачей=)
Просто использовать в Beanshell java фреймворк на самом деле не круто. Именно поэтому пришлось столько компилировать. Можно было бы сделать удобные ручки, скомпилировать их разок, т.е. фактически сделать обвязку и потом дергать их через beanshell. Но выбор за вами. Я бы на вашем месте писал полноценные семплеры.
>Для нагрузочного тестирования уже приходилось пару раз подымать независимые jmeter, так как бывало что подвисали отдельные треды, несколько jmeter с меньшим количеством потоков работали хорошо.
Тут нужно смотреть что за нити висели, и кто был виноват. Возможно даже одну JVM можно было потюнить до необходимого уровня производительности.
Поднять несколько JVM это простой уход от проблемы, а посмотреть что внутри JVM, вот это оказаться трудоемкой, но стоящей задачей=)
так я был разработчиком у которого стояла задача ускорить это все «счастье»: «вот у нас есть что-то, нужно найти почему так плохо работает, должно работать быстро и не падать на таймаутах» =)
в итоге переписано все на чистую java (почти полный копипаст, так как в большем уже все отлажено было) и прямо в xml процесса указываем какие хэндлеры дергать, производительность увеличилась более чем на порядок.
несколько jvm это действительно уход от проблемы, но сроки поджимали и нужно было предоставить отчеты сколько может держать сервис и что проблемы со скоростью у проекта выше по стеку
в итоге переписано все на чистую java (почти полный копипаст, так как в большем уже все отлажено было) и прямо в xml процесса указываем какие хэндлеры дергать, производительность увеличилась более чем на порядок.
несколько jvm это действительно уход от проблемы, но сроки поджимали и нужно было предоставить отчеты сколько может держать сервис и что проблемы со скоростью у проекта выше по стеку
Sign up to leave a comment.
Кодируем на лету в base64 и стреляем в MongoDB из JMeter с помощью BeanShell