Проблема заключалась в том, что я предполагал, что пики графика linode.com были истинными пиками. Оказывается, на графике используются средние значения данных за 5 минут, поэтому мой пик оказался равным 24 Мбит, тогда как на самом деле я достиг ограничения в 50 Мбит.

Теперь, когда они увеличили его до 100 Мбит, мои тесты немедленно поднялись до нового ограничения исходящего трафика.

Если бы я только заметил это раньше! Многие мои рассуждения основывались на идее, что я не достиг предела исходящего трафика из-за этого графика.

Теперь мой пик составляет 370 запросов в секунду, что составляет примерно 100 Мбит / с, после чего я начинаю получать «невыполненные» запросы, и время отклика начинает расти.

Теперь я могу увеличить максимальный параллелизм, уменьшив страницу; с включенным gzip я получаю 600 об / с.

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

Это был отличный урок по оптимизации / чтению этих данных / сокращению возможных проблем. Большое спасибо за ваш вклад!

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

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

Мы обнаружили, что довольно часто отбрасываем пакеты на интерфейсах со скоростью 1 Гбит / с со скоростью всего 10-30 Мбит / с, что снижает нашу производительность. Это связано с тем, что скорость 10-30 Мбит / с на самом деле представляет собой количество битов, передаваемых за 5 минут, преобразованное в скорость в одну секунду. Когда мы ближе познакомились с Wireshark и использовали графическое отображение ввода-вывода за одну миллисекунду, мы увидели, что мы часто взрываем скорость 1 Мбит на миллисекунду так называемых интерфейсов 1 Гбит / с.

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

Кто знает, возможно, я даже открою некоторые из них в секрете. :)

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

Я бы предложил исключить как можно больше из уравнения, чтобы нарисовать разумную базовую линию. Измерьте пиковую пропускную способность, задержку и потерю пакетов от вашего сервера до нескольких точек в обычном Интернете. Как бы маловероятно это ни звучало, попробуйте выполнить поиск по запросу «Тест трафика VoIP» или аналогичному. У нескольких поставщиков услуг VOIP есть приложения, которые могут измерять такие типы шаблонов (двунаправленно) с достаточной степенью точности. Как только у вас появятся достоверные эмпирические данные о фактической полезной скорости вашей ссылки, ваши результаты вполне могут быть подтверждены.

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