Я неправильно предположил, что мое внутреннее тестирование AB означает, что мой сервер может обрабатывать 1k одновременных обращений при 3k в секунду.

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

Внешнее тестирование от blitz.io при 1k одновременности показывает, что мои хиты / с ограничены на 180, а страницы реагируют все дольше и дольше, поскольку сервер может возвращать только 180 в секунду.

Я подал пустой файл из nginx и протестировал его: он масштабируется 1: 1 с параллелизмом.

Теперь, чтобы исключить узкие места IO / memcached (nginx обычно извлекает данные из memcached), я использую статическую версию кэшированной страницы из файловой системы.

Результаты очень похожи на мой оригинальный тест; Я ограничен на 180 RPS.

Разделение HTML-страницы пополам дает мне удвоенное число запросов в секунду, поэтому оно определенно ограничено размером страницы.

Если я внутренне использую ApacheBench с локального сервера, я получаю непротиворечивые результаты около 4 тыс. Запросов в секунду как на полной, так и на полстранице при высоких скоростях передачи. Скорость передачи: 62586,14 [Кбайт / с] получено

Если я AB с внешнего сервера, я получаю около 180RPS - так же, как результаты blitz.io.

Как я знаю, что это не намеренное регулирование?

Если я сравниваю результаты с нескольких внешних серверов, все результаты становятся неудовлетворительными, что наводит меня на мысль, что проблема в исходящем трафике МОИХ серверов, а не в скорости загрузки с моими контрольными серверами / blitz.io.

Итак, я вернулся к своему выводу, что мой сервер не может отправлять данные достаточно быстро.

Я прав? Есть ли другие способы интерпретации этих данных? Является ли решение / оптимизация для настройки нескольких серверов + балансировка нагрузки, каждый из которых может обслуживать 180 обращений в секунду?

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

Исходящий трафик

Вот дополнительная информация о исходящей полосе пропускания. На графике сети показана максимальная производительность 16 Мбит / с: 16 мегабит в секунду. Звучит совсем не так.

Из-за предположения о дросселировании я посмотрел на это и обнаружил, что у линода есть ограничение 50 Мбит / с (что я даже не близок к удару, очевидно). Я поднял его до 100 Мбит / с.

Поскольку линод ограничивает мой трафик, а я его даже не бью, означает ли это, что мой сервер действительно должен быть способен выводить до 100 Мбит / с, но ограничен каким-то другим внутренним узким местом? Я просто не понимаю, как работают сети такого масштаба; Могут ли они буквально отправлять данные так быстро, как они могут читать с жесткого диска? Сетевой канал такой большой?

В заключение

1: Исходя из вышеизложенного, я думаю, что я определенно могу повысить свои 180RPS, добавив балансировщик нагрузки nginx поверх конфигурации с несколькими серверами nginx со скоростью точно 180RPS на сервер за LB.

2: Если у linode есть предел 50/100 Мбит, который я вообще не бью, должно быть что-то, что я могу сделать, чтобы достичь этого предела с помощью настройки моего единственного сервера. Если я могу читать / передавать данные достаточно быстро локально, а линоде даже надоедает иметь ограничение 50 Мбит / 100 Мбит, должно быть внутреннее узкое место, которое не позволяет мне попасть в те ограничения, которые я не знаю, как обнаружить. Верный?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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