Доброго времени суток.
Провожу нагрузочное тестирование проекта с помощью JMeter. Сервак под томкат имеет 4 ядра и 14ГБ памяти (частоту не знаю, хостинг - амазон эластик клауд 2). Сервак под джейметр - 2 ядра и 8ГБ памяти (тоже ec2). В server.xml разрешил максимальное количество потоков 1024 и количество одновременных коннектов 15000, разрешил пулл соединений. JAVA_OPTS тоже подтюнинговал. ОС - дебиан ленни, максимальное количество открытых файлов сделал 10240. Тестовый план джейметра немного далековат от имитации реальных действий пользователей, на нормальный план времени нет. В 1500 параллельных потоков выполняется последовательная ротация всех существующих команд моей аппликации. Первая команда - на создание юзера с рандомным UserID, который и используется до конца ротации в этом потоке. В этом и минус тестового плана - создание юзера самая тяжеловесная команда, и частота ее возникновения на продакшне очень мала.
Вообщем, наблюдаю странную картину, сначала джейметр сыпет:

А потом и вовсе:

Ну тут все понятно, сервак перегружен, сначала джейметр не дожидается ответа на команду, а потом и вовсе не может дождаться TCP-ответа для открытия сокета.
Долгое выполнение команд с условием далекого от правды тестового плана допускается, потому поставил в тестовом плане по три минуты на ожидание соединения и выполнения семпла. И тут начинается самое интересное. Во время перегрузки сервера все как обычно, но ошибки не сыплятся - 3 минуты на ожидание ведь есть. И тут выполняемые потоки заканчивают ротацию, нагрузка на сервере падает до нуля, а вот джейметр говорит что энное количество потоков еще выполняется. iftop говорит обратное. В таком висячем состоянии проходит время, близкое к искомым трем минутам, после чего все эти ошибки дропаются с стэктрейсом №2 выше. Но почему? Если произошел рефьюз соединения, почему не выпал эксепшн сразу? Если рефьюз не произошел, почему коннект не открылся, когда для него появились свободные ресурсы? Эта ситуация портит отчет джейметра, время на ожидание коннекта считается за время выполнения семпла, в итоге средние значения скорости выполнения семплов неоправданно занижены.
Заранее спасибо за ответы.

Это сообщение отредактировал(а) LLIbIcpEP - 23.2.2011, 17:05

А что такое "рефьюз"? 

Пофантазирую.

Когда сокет делает попытку установить соединение с адресом, который существует в сети, но никто по этому адресу не живет (удаленное приложение OFF), то в сокете сработает таймаут на соединение. Нет "рефьюза". 


Если  удаленное приложение ON, но не успевает обрабатывать соединения, то, если есть буфер входящих запросов на соединение,  запрос  с некоторой задержкой будет обработан. Если же буфер переполнен, то запрос просто игнорируется и опять в сокете сработает таймаут на соединение.  Опять нет "рефьюза". 


Очевидно, нет такой практики, что всегда должен быть "рефьюз". Если сетевой адрес недоступен или не существует, это сразу диагностируется в сокетах. Если серверное приложение спроектировано так, что оно принимает соединения, но при повышенной нагрузке тут же их явно закрывает, то тоже "рефьюз" будет.  Такая схема снижает количество игнорируемых запросов на соединение.

Моя версия: jmeter "выстрелил" N запросов. Часть их была проигнорирована сервером по причине переполнения буфера, и эти сокеты ждали 3 минуты, потом сообщили о неудаче. 

Это сообщение отредактировал(а) COVD - 26.2.2011, 18:09