JMeter: забудьте про BeanShell Sampler

[polarnik]

Отличная статья, Владимир. Много лет уже использую знания о том, что Groovy производительнее, чем некешируемый BeanShell.

А об удобстве SharedHashMap для обмена данными между потоками узнал от друга aklexel. Сам упустил этот момент, когда статью читал. Оставлю тут ссылки, чтобы другим пригодились, и сам не забыл.

О практике применения связанной работы потоков в Apache.JMeter и передачи параметров между ними можно отдельную статью написать:

• через объект ConcurrentHashMap: put + get
• через связку объектов LinkedBlockingQueue: put + take или put + pool и ConcurrentHashMap — хеш-таблица с очередями
• возможно учитывая параметры ConcurentHashMap для повышения эффективности ( Как работает ConcurrentHashMap )
• или используя другие комбинации: Обзор java.util.concurrent.*
• про подготовку параметров в SharedHashMap на этапе работы setUp Thread Group + JSR223 Sampler
• про проверку на наличие оставшихся в SharedHashMap данных на момент завершения теста в tearDown Thread Group + JSR223 Sampler, где используя объект SampleResult можно сгенерировать дочерние объекты с ошибками — невостребованными тестовыми данными (начиная с JMeter 5.0 подзапросы тоже попадают в csv-лог и отчёты, как самостоятельные сущности, поэтому не пропадут)

[polarnik]

Ещё заметил особенность загрузки SharedHashMap в JMeter 5.0. Возможно, это дефект загрузчика компонент. Если к классе SharedHashMap только статические методы, то методы класса нельзя вызывать из JSR-223 Sampler. И чтобы класс считался классом, добавил в него нестатический метод test(). Что будет делать этот метод не важно, важно, чтобы он был.

Код можно написать так:

import java.util.concurrent.ConcurrentHashMap;

public class SharedHashMap
{
	private static final ConcurrentHashMap instance = new ConcurrentHashMap();

	public static ConcurrentHashMap GetInstance()
	{
		return instance;
	}

	public String test() {
                return "SharedHashMap";
        }
}

Не исследовал пока почему так происходит. Поисследую