Лично у меня сейчас нет таких бизнес-процессов, которые могут положить синглтон-компайлер. Кроме того, если проблема в пропуской способности именно его, то просто давайте мы разделим бизнес-процессы. Я подозреваю что большое кол-во скриптов как раз из-за этого, я правильно понимаю? Причем БП можно раскинуть по разным JVM с jmeter. Это один из вариантов ухода от проблемы.
Но даже при создании тест-плана одного бизнес-процесса мы можем совершенно по-разному использовать эти сценарии. А если у нас несколько схожих БП, то мы их можем обрабатывать вместе, в одном beanshell скрипте, используя, например, асинхронные тест-планы.
>Так что сам BeanShell быстрый, а вот большое количество разнородных небольших скриптов положит ваше нагрузочное тестирование в 2 счета.
Для создания прототипов, для быстрого написания, я бы рекомендовал именно beanshell, а для производительности пользоваться православным способом.
Плагин на самом деле хороший и удобный. Но регрессии там нету, это печаль. Плагином можно пользоваться просто как громилой-вышибалой. Тест на производительность прошел — выпускаем билд. Не прошел — не пускаем. А что-то сравнивать, тюнить, там не удобно:(
Но даже при создании тест-плана одного бизнес-процесса мы можем совершенно по-разному использовать эти сценарии. А если у нас несколько схожих БП, то мы их можем обрабатывать вместе, в одном beanshell скрипте, используя, например, асинхронные тест-планы.
>Так что сам BeanShell быстрый, а вот большое количество разнородных небольших скриптов положит ваше нагрузочное тестирование в 2 счета.
Для создания прототипов, для быстрого написания, я бы рекомендовал именно beanshell, а для производительности пользоваться православным способом.