Назад | Перейти на главную страницу

Тест производительности и настройка TCP

Мы находимся в процессе тестирования производительности приложения, которое получает запросы TCP, преобразует их в запросы мыла (WCF-httpBinding), над которыми работают другие службы.

Сервер - Windows Server 2008 R2. Запросы TCP принимает экземпляр TcpListener (.NET C #). На одном сервере работают 3 службы WCF с привязкой к http.

Мы создали клиент для тестирования производительности, цель которого - имитировать несколько одновременных запросов (каждый запрос должен отличаться и распознаваться приложением).

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

Один запрос записывает дважды один и тот же запрос на соединение и подтверждение приложения.

Хотя один запрос + подтверждение может занять около 150 мс, тест 150 занимает около 7 секунд.

Эта проблема

Когда мы пытаемся запустить этот тест с двух разных компьютеров, мы терять запросы. поступают запросы некоторых клиентов

no connection was made because the target machine actively refused it

Так я получил Вот и убедился, что это из-за отставания. Я изменил параметры TcpListener и записал изменения в журнале регистрации AFD Вот но это все еще не сработало, поэтому я вставил все предложенные настройки TCP плюс несколько рекомендованных команд netsh, но все равно без изменений, мы все равно получаем эту ошибку.

Что еще мне нужно знать? Есть ли другие решения?

Это досадное раздражение Windows. Когда сервер Windows перегружен, он активно отклоняет соединения (отвечая с помощью RST), а не просто не отвечает на них (не отправляет SYN). Чтобы это не интерпретировалось как сбой, клиенты Windows обычно повторяют попытки подключения (отправляя еще один SYN), даже если им активно отказывают (ответили RST).

Вам следует повторить попытку подключения, даже если в нем активно отказано. Очевидно, что если вы попытаетесь подключиться к большему количеству подключений в секунду, чем может обработать сервер, все они не будут успешными. Как вы хотите вести это дело, зависит от вас.

Итак, краткий ответ - что вы хотите, если у вас будет больше попыток подключения, чем сервер может обработать? Вы хотите, чтобы они двигались очень, очень медленно? Или вы хотите, чтобы они потерпели неудачу? Если первое, повторите попытку до бесконечности, ожидая все дольше и дольше между попытками. Если последнее, то откажитесь.

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