Что вызывает задержку в 100 мс при установлении соединения HTTP?
Настройки: это четырехъядерный процессор, достаточно мощный, не загруженный вообще (ни процессор, ни сеть), клиент - 64-разрядная ОС Windows Server 2008, сервер - Linux-сервер.
У меня есть четыре потока, которые выдают запросы HTTP, начинающиеся одновременно. Соединения инициируются с IP-адресами X, X, Y, Z (два соединения с X, одно с Y и Z). Все цели находятся в локальной сети.
Я вижу, что соединения с X, Y и Z сформированы (SYN-SYN/ACK), а второе соединение с X имеет задержку 100 мс. Это означает, что машина не отправляет второй SYN в X в течение полных 100 мс.
Может ли это быть связано с TCP Offload Engine? Что еще может быть причиной этой задержки?
Редактировать - Еще один подозрительный код клиента - он написан на Java, использует HttpURLConnection.
6 ответов
Трассировка сети (например, Wireshark) покажет, находится ли задержка в ожидании ответа. Это также указало бы на другие "обходные пути", такие как предложение о DNS. Похоже, вы, возможно, уже сделали это, но вы не сказали.
Другая возможность: ограничение Windows XP SP2 для исходящих полуоткрытых подключений, которое по умолчанию равно 10. Я не уверен, как вы видите, сколько подключений находится в этом состоянии, но я полагаю, что если этот ограничитель скорости сработает, он покажет в журналах ошибок.
Должен ли он выполнять поиск DNS для каждого запроса? Это ограничивает скорость?
Хорошо, есть много возможных мест, это может пойти не так. Вы упомянули механизм разгрузки TCP, и это вполне обоснованно (особенно если у вас есть сетевые адаптеры Broadcom), поэтому давайте исключим его и отключим (обратитесь к документации по этому вопросу).
После этого вы хотите начать сокращать число других возможных кандидатов, поэтому обратите внимание на коммутаторы, сетевые кабели и так далее. Если вы можете, подключите источник к цели через кроссовер и посмотрите, сможете ли вы воспроизвести его там.
Стоит также попробовать дорогой старый ping - из его звуков вы должны быть в состоянии воспроизвести аберрантное поведение с помощью 4 одновременных пингов.
Но это сводится к тому, что нет смысла что- либо подозревать на этом раннем этапе, так как существует слишком много мест, где это может пойти не так (включая ваше приложение).
Первоначальное соединение проходит нормально, но ваше второе соединение ставится в очередь. Я бы рассмотрел реализацию клиента в программном обеспечении, я не знаю, если более поздние JDK внесли больше изменений, но раньше было так, что даже если вы сделали отдельные HttpUrlConnections, нижележащий обработчик протокола все равно будет повторно использовать соединение с сокетом.
Вы должны зарегистрироваться в StackOverflow и посмотреть, сталкивались ли некоторые из них с этой проблемой ранее.
Вы проверили настройки брандмауэра? В настройках брандмауэра может быть что-то, что ограничивает скорость соединений.
Есть ли у вас какие-либо специальные настройки sysctl для сервера? Есть много мелких изменений, которые можно сделать для работы в сети в sysctl.
Вы проверяли на разных серверах / клиентах? Это поможет изолировать причину проблемы - будь то конкретный сервер, клиент или оба.