сервер обрабатывает 70 запросов в секунду каждый со временем ответа менее 50 миллисекунд

Question

Я получаю большое количество http GET-запросов с ограниченного количества IP-адресов (<4) от соседних серверов.Задача состоит в том, чтобы поддерживать время ответа <= 50 миллисекунд для каждого запроса. </p>

Я включил повторное использование TCP-соединения, задав для tcp_tw_reuse значение 1. ip_local_port_range для значения от 1024 до 65535.

tcp_fin_timeout установлено на 60 (по умолчанию).

В файле conf моего веб-сервера (nginx) я установил keepalive_timeout равным 5 (это связано с tcp TIME_WAIT?).

Сейчас я получаю 5 запросов в секундуи время отклика составляет около 200 мс.

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

Answer 1

nginx keepalive_timeout контролирует возможность протокола HTTP повторно использовать существующие подключения и не имеет никакого отношения к состоянию TCP TIME_WAIT ,(Он также не связан с датчиками поддержания активности TCP; они отправляются после двух часов простоя и поэтому бесполезны почти для всего.)

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

Состояние TCP TIME_WAIT существует, чтобы убедиться, что оба пира знаютмертвое соединение не работает - если одна сторона повторно использует порты при повторном соединении, а другая сторона пропустила пакет FIN, она может подумать, что пакеты из нового соединения на самом деле предназначены для старое соединение.К сожалению.Состояние TIME_WAIT предотвращает это.Как правило, нет необходимости возиться с этим номером;Рассмотрим своих клиентов, подключаясь 70 раз в секунду.При выборе 63 тыс. Портов это примерно 500 секунд между повторным использованием порта: 63 тыс. Портов / 70 к / с == 1000 секунд, случайный выбор говорит, возможно, вдвое меньше.TIME_WAIT близок к двум минутам, а это семь или восемь минут.Когда вы получаете около 100 соединений в секунду от однорангового узла, я начинаю больше беспокоиться о TIME_WAIT.

Вместо этого, я думаю, вы столкнулись с проблемой алгоритма Нейгла , используемогочтобы предотвратить переполнение Интернета кучей глупых маленьких пакетов.Алгоритм Nagle заставляет системы TCP немного подождать при отправке небольшого количества данных в надежде, что при ожидании будет получено больше данных.Это отлично, когда дела идут, но может вызвать недопустимые задержки при установлении соединения.Обычный механизм противодействия Nagle - установка опции сокета TCP_NODELAY.(Что ж, возиться с шаблонами приложения вызовов send(2) и recv(2) - лучше , но это не всегда вариант. Следовательно, этот лейкопластырь.) См. Справочные руководства по tcp(7), setsockopt(2)подробности.Поскольку алгоритм Nagle плохо взаимодействует с алгоритмом ACK с задержкой TCP , вы также можете попросить TCP отправлять немедленные ACK-пакеты, а не обычную небольшую задержку для ACK-пакетов: это TCP_QUICKACKопция сокета.

Страница man tcp(7) также предоставляет небольшую подсказку для настройки tcp_low_latency, которая может сделать то, что вам нужно.Попробуйте включить его.(Я не знаю последствий этого решения, но думаю, что это повлияет на параметры Nagle и Delayed ACK по всему сайту, а не на отдельные сокеты.)

Answer 2

Я собираюсь выйти и предположить, что это статические файлы, а вы не пропускаете их через cgi.

Из моего опыта в профилировании и профилировании в Google, все дело в том, чтобы найти узкое место или оптимизировать области, которые занимают больше всего времени, не затрачивая все свои усилия на ускорение процесса, который занимает 5% вашего времени.

Я хотел бы узнать больше о вашей настройке. Какое время отклика для одного файла? Какое время в обратном пути для пинга? Насколько большие файлы?

например, если пинг занимает 150 мс, ваша проблема в вашей сети, а не в вашем nginx conf. Если файлы в мегабайтах, это не nginx.

Если время отклика отличается от 1 до 30 запросов в секунду, я предполагаю, что что-то более интенсивное, чем более тонкие настройки nginx.

Можете ли вы пролить свет на ситуацию?

- обновление - Я выполнил тест на своем стандартном сервере nginx, получив типичную страницу index.php.

При сравнении изнутри сервера:

roderick@anon-webserver:~$ ab -r -n 1000 -c 100 http://anon.com/index.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking anon.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        nginx/0.8.54
Server Hostname:        anon.com
Server Port:            80

Document Path:          /index.php
Document Length:        185 bytes

Concurrency Level:      100
Time taken for tests:   0.923 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Non-2xx responses:      1000
Total transferred:      380000 bytes
HTML transferred:       185000 bytes
Requests per second:    1083.19 [#/sec] (mean)
Time per request:       92.320 [ms] (mean)
Time per request:       0.923 [ms] (mean, across all concurrent requests)
Transfer rate:          401.96 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    4   1.6      4       9
Processing:     1   43 147.6      4     833
Waiting:        1   41 144.4      3     833
Total:          4   47 148.4      8     842

Percentage of the requests served within a certain time (ms)
  50%      8
  66%      8
  75%      9
  80%      9
  90%     13
  95%    443
  98%    653
  99%    654
 100%    842 (longest request)

При сравнении с моим домашним рабочим столом:

roderick@Rod-Dev:~$ ab -r -n 1000 -c 100 http://anon.com/index.php
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking anon.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        nginx/0.8.54
Server Hostname:        anon.com
Server Port:            80

Document Path:          /index.php
Document Length:        185 bytes

Concurrency Level:      100
Time taken for tests:   6.391 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Non-2xx responses:      1000
Total transferred:      380000 bytes
HTML transferred:       185000 bytes
Requests per second:    156.48 [#/sec] (mean)
Time per request:       639.063 [ms] (mean)
Time per request:       6.391 [ms] (mean, across all concurrent requests)
Transfer rate:          58.07 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       40  260 606.9    137    3175
Processing:    81  214 221.7    140    3028
Waiting:       81  214 221.6    140    3028
Total:        120  474 688.5    277    6171

Percentage of the requests served within a certain time (ms)
  50%    277
  66%    308
  75%    316
  80%    322
  90%    753
  95%    867
  98%   3327
  99%   3729
 100%   6171 (longest request)

Моя ОС Linux, моему процессору 3 года (это был сервер за 500 долларов).

Я ничего не сделал с файлом конфигурации.

Что это говорит мне? Nginx не проблема.

Либо сеть вашего сервера перегружена, либо AWS ограничивает ваш процессор. Я бы наверное угадал оба.

Если исправление так важно, я бы получил выделенный сервер. Но это только, насколько мне известно.

Answer 3

Поскольку клиентских хостов очень мало, возможно, закрытые соединения TCP в состоянии TIME_WAIT вызывают медлительность, резервируя доступные номера портов.

Может быть, вам стоит попробовать:

echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle

Примечание о опции:

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