Веб-сервер httpd, обслуживающий контент, имеет разную скорость загрузки от клиентов?

Веб-сервер httpd, обслуживающий контент, имеет разную скорость загрузки от клиентов?

Для нашей игры мы размещаем ее статические ресурсы на виртуальной машине, на которой только что установлен и запущен httpd (конечно, вместе с некоторыми собственными вещами Linux), чтобы обслуживать веб-контент. MPM настроен как worker с MaxClients 6400, ServerLimit 100 и ThreadsPerChild 64. Память составляет 4 ГБ. С указанной выше конфигурацией обслуживаемый статический контент имеет общий размер около 20 МБ, и он обслуживается в моей стране (Болгария), а также в других странах. Проверено и подтверждено, что национальная и международная скорости полосы пропускания не отличаются. Однако в пиковые моменты, когда полоса пропускания достигает максимума, мы начинаем получать массовые жалобы от удаленных пользователей (например, из России), что игра полностью загружается в течение 2-3 минут. Каждый раз, когда мы проверяем загрузку игры с отключенным кэшем отсюда, это занимало около 10 секунд, каждый раз, когда мы пытались, с любого компьютера. Мы добавили еще 2 ВМ из образа исходной ВМ (та же конфигурация и содержимое) и выполнили самую быструю балансировку нагрузки - DNS round robin для трех IP-адресов. Жалобы уменьшились, но время загрузки для российских пользователей продолжало составлять 1 минуту+. Когда мы снова попытались несколько раз загрузить игру отсюда, оно все еще составляло 10 секунд, для нас никакой разницы. Каковы могут быть возможные причины, учитывая, что серверы статического контента имеют равный национальный и международный пиринг, и когда нагрузка низкая, все российские пользователи также могут загружать в течение 10 секунд, но не в часы пик? Разве это не должно быть одинаковым для всех пользователей?

P.S. На статических серверах всегда было достаточно памяти, а количество порожденных httpd-процессов никогда не превышало 50, при установленном лимите в 100.

EDIT: Краткое резюме вопроса - при низкой нагрузке все клиенты (локальные и удаленные) загружают клиент за одинаковое время (например, 15 сек). При высокой нагрузке локальные клиенты снова загружают его за 15 сек, а удаленные - за 2-3 минуты. Каковы возможные причины?

решение1

Согласноразъяснение, что это происходило только тогда, когда пропускная способность была исчерпана, это может показаться совершенно нормальным поведением, но когда вы достигаете максимума доступной пропускной способности (скорости линии), вы можете начать терять пакеты и иметьTCP-окнодля клиентов с длительным сроком действия, которые никогда не масштабировались для достижения оптимальной скорости;Продукт задержки полосы пропусканиярастет, время загрузки того же файла по тому же каналу увеличивается; вам придется сделать что-тоформирование трафика(другими словами,очередность пакетов и приоритезация) если вы хотите сделать его более равномерным для всех в периоды перегрузки. – cnst 6 окт в 4:56

решение2

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

Кстати, вы сказали, что ваша пропускная способность исчерпана. Пропускная способность сетевого соединения вашего сервера? Тогда вам действительно нужен CDN или кэширующие обратные прокси.

Я могу предложить несколько быстрых улучшений:

  • Используйте Nginx; он может обслуживать статический контент гораздо эффективнее.
  • Используйте CDN, например Cloudflare, или, если это слишком сложно, вы можете арендовать виртуальную машину в России и установить на ней кэширующий обратный прокси, сделать ваш DNS-гео-IP-адрес известным и перенаправлять туда российских пользователей. Cloudflare может быть проще :)

решение3

Нельзя сказать, что пиринг одинаков для национального и международного трафика.

За последние пару лет ситуация могла измениться, но традиционно в России большинство провайдеров никогда не платили за локальный пиринг, получая трафик напрямую от MSK-IX, а весь остальной трафик обрабатывался транзитными провайдерами.

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

Часто в точках пиринга или транзита провайдеры платят фиксированную ставку за безлимитные 100 Мбит/с, 1 Гбит/с или 10 Гбит/с. Что происходит, когда трафик превышает оплаченный объем? Некоторые пакеты отбрасываются, некоторые замедляются, и это обычно происходит только в часы пик, а иногда и только в одном направлении (но даже если это происходит в одном направлении, трафик все равно замедляется в обоих направлениях, поскольку увеличивается задержка, а некоторые ACKпакеты управления перегрузкой также теряются).

Я бы решил проблему, запустивmtrк одному из хостов в России, который испытывает проблему, а также от одного из хостов в России к вашему серверу в Болгарии. Я считаю наиболее полезным запускать каждый экземпляр в течение 30 секунд - 15 минут (mtr будет собирать статистику за всю продолжительность такого запуска), а затем запускать его снова в течение еще 5-15 минут сразу после завершения предыдущего запуска. Таким образом, вы сможете точно увидеть, в какое время возникают проблемы.

В противном случае это может быть проблема с Apache, возможно, связанная с более высокой задержкой хостов в России — nginx, как правило, более эффективен при обслуживании всех видов контента, чем Apache, так что, возможно, это хорошая возможность попробовать nginx?

решение4

Хотя скорость света постоянна, и данные передаются по оптоволоконным кабелям на большие расстояния с одной и той же скоростью, чем дальше они находятся от источника, тем больше «прыжков» им приходится делать.

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

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

Связанный контент