Симуляция TCP-подключений

В общем случае ты можешь решить эту задачу, обойдясь и всего одной машиной, запустив на ней 10K клиентов и сервер

хочешь задержек ? man tc-netem

Учитывая наличие tproxy можно имитировать подключение с произвольных адресов.

Для начала можно обойтись и без отдельного клиента - запускать его в контейнере.

Нагрузку всю жизнь JMeter-ом задавали. Попробуй из GUI, если понравится — сможешь в консольный режим перейти.

Насколько такое тестирование (кроме отсутствия сетевых задержек из-за близости расположения) будет эффективным? Т.е. сможет ли вторая машина адекватно создать картину пика подключений и как организовать такие условия?

Конечно сможет. Я вот этой приблудой пользуюсь.

Как решить задачу в общем случае, используя лишь две машины в локальной сети (одна сервер, вторая клиенты)?

на одной машине сервер, на другой клиенты. и свечка в церкви не помешает чтобы клиент не помер раньше сервера (спойлер: все равно помрет)

Насколько такое тестирование (кроме отсутствия сетевых задержек из-за близости расположения) будет эффективным?

в первую очередь зависит от твоих тестовых данных (какие пакеты в какой пропорции ты будешь отправлять) и ассертов на клиенте (насколько ты сможешь вычленить из полученных ответов данные, которые позволяют определить корректность обработки и передачи)

сможет ли вторая машина адекватно создать картину пика подключений и как организовать такие условия?

сферически в ваккуме - да запросто. практически - зависит от твоего конкретного случая. у меня были случаи, когда 20к клиентов требовали 4х генераторов нагрузки и те все равно крутились на пределе. про jmeter не слушай, он от такого количества клиентов раком встанет. несколько нод с loadui (он сейчас вроде часть soapui), думаю смогут переварить ту нагрузку, что я представляю по твоим цифрам. это если не писать свой фреймворк для стресс-тестирования, а лучше это все-таки сделать: большинство готовых тулз вынесут тебе мозг своим перфомансом и будут вставать колом задолго до рассчетной нагрузки

разумеется, все вышеописанное - для случая тестирования нормального. если тебя не интересует корректность ответов и часотоа запросов - все упрощается. но в любом случае, 10к клиентов в минуту (не в год же) даже в пике, которые постоянно шлют мегабайтные пакеты - это ты что-то неадекватное придумал - либо оно тебе на самом деле не нужно, либо тебе нужен человек гораздо более опытный.

судя по тому, что тема в Development, а не в Admin - ТСу скорее нужно тестирование сервера, не сети. тут такими примитивными тулзами не обойдешья. хотя теги вносят некоторую путаницу, да

Примитивная тулза не может проверять корректность ответов, но дать различные виды нагрузок — вполне. По моему опыту этого обычно достаточно, чтобы выявить слабые места в performance программы и/или ее окружения.

Все очень индивидуально. Что-то можно и на одной машине увидеть. И надо смотреть, чтобы затык не был на самих клиентах.

Скажем, перловые скрипты, и их много - в результате получаем, что сервер справляется, а клиенты отжирают всю память, система уходит в своп. В общем, система не должна уходить в своп, а иначе что там увидишь? Хотя если сервер уходит с своп, то это плохо.

Еще могу посоветовать с третьей машины снимать дамп TCP/IP. Чтобы не было TCP zero window, не было всяких там reset. Очень может быть, что затык будет где-нибудь на уровне реализации стека TCP/IP в самом ядре системы. У всякой реализации есть свои пределы. При нагрузке на процессор около 100% стек TCP/IP начинает банально рушиться.

Затык должен быть. Вопрос, где?

Да, и скорее всего увеличить пределы по числу файловых дескрипторов.

Не забывать, что select при числе передаваемых дескрипторов >= 1024 на линуксе не фурычит. FD_SET рушит стек. А вот на солярисе работает. Там ограничение в 60 с чем-то тысяч. Впрочем, если используете poll/epoll, то эта проблема не должна волновать, или если Java.

Тонкостей много. При тестировании могут вылезти все слабые места. Задача - их найти, а общие советы сложно давать.

Неточно выразился на счет select. Если число дескрипторов в самом процессе больше где-то 1024, то тогда FD_SET рушит стек для больших значений дескрипторов, но это детали, хотя мы на них напоролись и как раз при тестировании)

Еще иметь в виду, что при нагрузке затык может быть запросто на дисковых операциях. Скажем, если вы интенсивно пишите логи в файл или файлы, то именно логирование может оказаться самым слабым местом, особенно если диски обыкновенные, а не специальные с хитро-вывернутой системой, какие были на сановских спарках.

Ну, и последнее. Вы, конечно, убедились, что у вас в самой логике приложения все чисто? Зачистили и оптимизировали все места, на которые указывал valgrind/профилировщик (даже при малой нагрузке). Да и с точки зрения проектирования все нормально. Затык может быть запросто в неэффективных алгоритмах, например, если обработка сложнее O(n log(n)), то это уже сигнал, что при нагрузке будет плохо. Обычно затык бывает именно в алгоритмической части, а потом уже во всем том, что я описал выше.

В общем, проблема может быть совсем не там, где вы ее ждете. К этому надо быть готовым)

По моему опыту этого обычно достаточно, чтобы выявить слабые места в performance программы и/или ее окружения

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