Apache Bench Varnish Long Tail результатов

Я пытаюсь настроить Varnish перед Drupal и просто провожу несколько быстрых тестов Apache Bench, чтобы увидеть, какие улучшения я получаю.

Я выполняю следующую команду ab: ab -n 15000 -c 300 -k -H 'Accept-Encoding: gzip,deflate' www.mysite.tld/some-page

Как только я устанавливаю параллелизм выше 300 или около того, я начинаю видеть очень длинный хвост результатов:

Percentage of the requests served within a certain time (ms)
  50%      2
  66%      4
  75%      4
  80%      5
  90%      7
  95%     19
  98%     45
  99%    246
 100%   5016 (longest request)

Этот длинный хвост становится все хуже и хуже по мере увеличения параллелизма, но всегда, кажется, возникает после 95% соединений (плюс-минус).

Для той же команды ab, но с c на 500:

  50%      1
  66%      1
  75%      1
  80%      2
  90%      5
  95%     22
  98%    365
  99%   5060
 100%   5061 (longest request)

Для c = 1000:

  50%      1
  66%      1
  75%      2
  80%      2
  90%      5
  95%     39
  98%   5061
  99%  27867
 100%  27885 (longest request)

Я изменил эти настройки Varnish:

thread_pool_add_delay      1 [milliseconds]
thread_pool_max            5000 [threads]
thread_pool_min            500 [threads]

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

Почему этот длинный хвост? Как мне от этого избавиться?

РЕДАКТИРОВАТЬ Я вижу эти сообщения в dmesg во время тестирования:

[1469125.946204] TCP: Possible SYN flooding on port 80. Sending cookies.
[1469203.735802] TCP: Possible SYN flooding on port 80. Sending cookies.
[1469276.171367] TCP: Possible SYN flooding on port 80. Sending cookies.

А с сокетами я часто вижу интересные вещи:

$ netstat -ant | grep 80 | awk '{print $6}' | sort | uniq -c | sort -n
      1 TIME_WAIT
      2 LISTEN
    257 ESTABLISHED
    437 CLOSE_WAIT

Во время тестирования обычно он проходит через запросы 0 - 13500, затем идет очень, очень медленно, только иногда до 15000. Если этого не происходит, то соединения переходят к CLOSE_WAIT - предположительно, потому что время ожидания Apache Bench истекло, поэтому сокет фактически не закрыт. Но во время ожидания обычно целая куча сокетов просто ждет в ESTABLISHED.

Что-то происходит, когда ядро ​​отправляет обратно синхронные файлы cookie, что каким-то образом заставляет мои клиенты тайм-аут и повторять попытку?

РЕДАКТИРОВАТЬ 2

Хотя на практике это, вероятно, ужасная идея, я все же попытался отключить файлы cookie синхронизации:

sysctl -n net.ipv4.tcp_syncookies = 0

Это обеспечивает значительно лучший результат - для c = 1000, n = 25000 результаты выглядят практически так же, как c = 500, n = 15000 выше.

Однако я также пришел к выводу, что если я обслуживаю 3 КБ запросов в секунду, то на самом деле я буду очень близок к достижению предела моего исходящего сетевого канала. Итак, я, вероятно, верну свои сетевые параметры к значениям по умолчанию и не буду слишком беспокоиться о результатах тестов. Но мне по-прежнему очень любопытно: а) почему файлы cookie синхронизации вызывают это замедление, когда на обеих машинах много ЦП, и б) почему даже при отключенных файлах cookie синхронизации я все еще вижу аналогичный результат, только с более высокими значениями c и n.