1k одновременных звучит достаточно низко, чтобы это было что-то другое ... это также ограничение по умолчанию для количества открытых дескрипторов файлов во многих дистрибутивах Linux, так что, возможно, попробуйте поднять предел.
ulimit -Sn
покажет вам ваш текущий лимит и
ulimit -Hn
покажет вам жесткое ограничение, которое вы можете пройти, прежде чем вам нужно будет касаться файлов конфигурации. Отредактируйте /etc/security/limits.conf как root и установите что-то вроде
yourusername soft nofile 50000
yourusername hard nofile 50000
yourusername - должно быть именем пользователя, который с вами запускает jmeter.
После этого вам, вероятно, придется перезапустить, чтобы изменения вступили в силу. Если не в Linux, я не знаю, как на самом деле это сделать, вам придется Google: D
Рекомендация:
Как разработчик k6 , я могу предложить его в качестве альтернативного инструмента, но с ним будет сложно работать и 10K VU на одной машине. Каждый VU будет занимать некоторое количество памяти - например, по крайней мере 1-3 МБ, и это будет увеличиваться, чем больше ваш скрипт. Но с 32 ГБ вы все равно могли бы работать до 1-2 кВ и использовать http.batch для одновременных запросов, которые могут моделировать 10 КБ в зависимости от того, каков ваш фактический рабочий процесс.
Мне удалось запустить этапов с 300VU на одном 3770 процессоре i7 и 4 ГБ оперативной памяти в виртуальной машине, и получить 6,5 кбит / с на другую виртуальную машину на соседней физической машине (задержка составляет очень низкий), так что, возможно, 1,5-2 кВ с несколько более интересным сценарием и более высокой задержкой, поскольку это даст время golang для фактического запуска GC во время ожидания пакетов tcp. Я настоятельно рекомендую использовать discardResponseBodies , если они вам не нужны, и даже если вам нужны некоторые, чтобы получить ответ. Это очень помогает с потреблением памяти на каждый VU