Нагрузочное тестирование игры с парой сотен тысяч виртуальных пользователей / Комментарии / Хабр

polarnik 6 апр 2019 в 19:59

Спасибо, Герман. Интересные приёмы используешь, возьму себе:

вставка "%" для обозначения Throughput Controller;

циклы по переменным в Groovy-стиле:

vars.entrySet()
	.collect { it.key }
	.grep { it.startsWith('can_') }
	.each vars.&remove

передача функций через vars:
```
vars.putObject('updateGrid', this.&updateGrid)
```
скрытый JSR223 через Flow Control Action + JSR223 PreProcessor;
метрики для определения качества autovacuum.

Не знаю, чем JSR223 Assertion лучше JSR223 PostProcessor. Проверить надо. Может и нет разницы.

У меня бы терпения не хватило столько JSR223 отлаживать. Их же постоянно править приходится. Поэтому все их выношу во внешние файлы. И пишу код в IDEA, так удобнее отслеживать версии, быстрее делать рефакторинг, искать код.

А вот этот код меня смущает:

// Portal Timer
def local = ${THREAD_COUNT};
def total = ${THREAD_COUNT_TOTAL};
...

Сейчас специально замерю, но думаю, что вот такой вариант будет быстрее, за счёт неизменности groovy-кода, и отсутствия даже возможности лишней перекомпиляции:

// Portal Timer
def local = vars.get('THREAD_COUNT');
def total = vars.get('THREAD_COUNT_TOTAL');
...

В Timing PostProcessor код не является потокобезопасным, так как props — это просто HashMap, нет блокировок, между моментами get и put данные изменятся несколько раз:

int samples = 5;

double oldAvg = props.get('portalRespAvg');
double newAvg = ((oldAvg * (samples-1)) + prev.getTime()) / samples

props.put('portalRespAvg', newAvg);

Но тут не знаю, что предложить взамен. Не писал таймеры.