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

Медленное время загрузки на сервере TomEE на экземпляре AWS EC2 Windows Server 2008

у меня есть Tomee 1.5.1 машина работает на AWS m1.medium экземпляр с Windows Server 2008.

Ставлю на сервер статический .jpg файл из 2.5 MB, и это берет меня вокруг 25 seconds чтобы загрузить его на свой компьютер с Chrome.

Наблюдая за трафиком в Wireshark, я вижу, что приемник Window Size постоянно на 64 KBbytes, когда окно приемника равно 256, а коэффициент масштабирования равен 256 (сдвиг влево от 8).

Типичный обмен:

Факторы устранены:

  1. Сервер перегружен - это не так.

  2. У сервера низкая пропускная способность - ее нет, по крайней мере, когда соединение инициализируется с сервера. При запуске ookla speedtest на серверной машине для некоторых поставщиков тестов в моем районе отображается восходящий / нисходящий канал около 60 Мбит / с.

3. Ресивер работает медленно / неправильно настроен - это не так - тот же файл загружается с какого-то файлообменного сервера за 2 секунды. Размер окна подскакивает по мере увеличения трафика / перегрузки, как и должен, и становится намного больше.

Редактировать 1

Отключение эвристики на клиенте не помогло

Редактировать 2

Дополнительный вопрос заключается в том, почему отправитель, похоже, отправляет данные сериями из 1460 * 6 + 240 = 9000 байтов, и не имеет более одной «невыполненной» серии, что означает, что он отправляет новую группу, как только он получил подтверждение на одну- до-предыдущая связка

Изменить 3:

Оказывается, у http коннектора есть настройка socketBuffer - «Размер (в байтах) буфера, который должен быть предоставлен для буферизации вывода сокета. Можно указать -1, чтобы запретить использование буфера. По умолчанию будут использоваться буферы размером 9000 байт». - Это ровно 9000 байт исходящих пакетов.

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

Если мы изменим его на 4 МБ, пакетирование увеличится до 64 КБ ...

Если трафик не зашифрован SSL. Если SSL включен, размер пакета составляет 16 КБ.

Необходимо проверить следующее:

  1. Каков оптимальный размер выходного буфера для соединений с низким пингом? Думаю с 64к может быть нормально.
  2. Как настроен выходной буфер SSL
  3. Попробуйте более новую версию tomee - есть обновления для http-коннектора
  4. Проверьте разъем NIO
  5. Почему ACK приходят партиями?

Изменить 4:

  1. Размер буфера 64 КБ имеет небольшое значение. Я остановился на 128k на всякий случай.

  2. Если мы используем Tomee 7 на Windows Server 2016, SSL работает так же быстро, как и обычный HTTP-трафик. На данный момент я не знаю, когда произошло изменение между tomcat5-win2008 и tomcat7-win2016.

С Windows, похоже, обсуждаются две вещи, прежде всего проверьте свою текущую конфигурацию:

netsh int tcp show global

Часто предлагается отключить автонастройку, но это также отключит масштабирование. Итак, используя restricted кажется, на самом деле лучше для масштабирования. Отключение автонастройки также отключит масштабирование, поэтому не делайте этого.

Также некоторые люди сообщают, что отключение эвристики масштабирования окна на клиенте делает запрос функции более последовательным. 256 * 255 кажется типичной комбинацией, когда Windows недооценивает качество связи.

Также ознакомьтесь с этой статьей об оптимизации PSH на стороне клиента и сервера (особенно для Windows). Мне кажется, что из ваших диаграмм последовательностей клиент слишком долго ждет, чтобы подтвердить пакеты (ожидая PSH от сервера). http://smallvoid.com/article/winnt-tcp-push-flag.html