Для нашей игры мы размещаем ее статические ресурсы на виртуальной машине, на которой только что установлен и запущен httpd (конечно, вместе с некоторыми собственными вещами Linux), чтобы обслуживать веб-контент. Настроен MPM - рабочий с MaxClients 6400, ServerLimit 100 и ThreadsPerChild 64. Объем памяти 4 ГБ. В приведенной выше конфигурации общий размер обслуживаемого статического содержимого составляет около 20 МБ, и он обслуживается в моей стране (Болгарии), а также в других странах. Проверено и подтверждено, что национальные и международные скорости передачи данных не отличаются. Однако в пиковые моменты, когда пропускная способность исчерпана, мы начинаем получать массовые жалобы от удаленных пользователей (то есть из России), что игра полностью загружается за 2-3 минуты. Каждый раз, когда мы проверяем загрузку игры с отключенным кешем отсюда, это занимало около 10 секунд, каждый раз, когда мы пытались, с любого компьютера. Мы добавили еще 2 виртуальные машины из исходного образа виртуальной машины (с той же конфигурацией и содержимым) и выполнили самую быструю балансировку нагрузки - циклический перебор DNS до трех IP-адресов. Жалобы уменьшились, но время загрузки для российских пользователей по-прежнему составляло 1 минуту +. Когда мы снова несколько раз пытались загрузить игру отсюда, все равно было 10 секунд, для нас никакой разницы. Каковы могут быть возможные причины, учитывая, что серверы статического контента имеют равный национальный и международный пиринг, и при низкой нагрузке все российские пользователи также могут загружать в течение 10 секунд, но не в часы пик? Разве это не должно быть одинаковым для всех пользователей?
P.S. Постоянно на статических серверах было много памяти, а порожденные процессы httpd никогда не превышали 50, с установленным пределом 100.
РЕДАКТИРОВАТЬ: Краткое изложение вопроса - при низкой нагрузке все клиенты (локальные и удаленные) загружают клиента за равное время (например, 15 секунд). При высокой загрузке локальные клиенты снова загружают его в течение 15 секунд, а удаленные - в течение 2-3 минут. Каковы возможные причины?
Вы не можете сказать, что пиринг одинаков для национального и международного трафика.
Это могло измениться за последние пару лет, но традиционно в России большинство провайдеров никогда не платили за какой-либо локальный пиринг, получая его напрямую из MSK-IX, а остальной трафик обрабатывают транзитные провайдеры.
Ссылки в разных направлениях почти всегда имеют разную емкость, и очень часто определенные ссылки остаются насыщенными время от времени (либо из-за неожиданных всплесков трафика, либо из-за того, что кто-то слишком ленив, чтобы обновить свои ссылки, или платить больше за больший трафик и т. Д.) , и это может происходить особенно часто в часы пик.
Часто в точках пиринга или транзита провайдеры платят фиксированную ставку за безлимитные 100 Мбит / с, 1 Гбит / с или 10 Гбит / с. Что произойдет, когда трафик станет больше того, за что заплатили? Некоторые пакеты отбрасываются, некоторые замедляются, и обычно это происходит только в часы пик, а иногда и только в одном направлении (но даже если это происходит в одном направлении, трафик все равно замедляется в обоих, так как задержка увеличивается, а некоторые ACK также теряются пакеты управления перегрузкой).
Я бы решил проблему, запустив mtr к одному из хостов в России, на котором возникла проблема, а также от одного из хостов в России к вашему серверу в Болгарии. Я считаю наиболее полезным запускать каждый экземпляр от 30 секунд до 15 минут (mtr будет агрегировать статистику за всю продолжительность такого запуска), а затем снова запустить его еще на 5-15 минут сразу после завершения предыдущего запуска. Таким образом, вы сможете точно увидеть, в какое время возникают проблемы.
В противном случае это также может быть проблема с Apache, возможно, связанная с более высокой задержкой хостов в России - nginx обычно более эффективен в обслуживании всех видов контента, чем Apache, поэтому, возможно, это хорошая возможность попробовать nginx вместо этого. ?
Ответ зависит от многих вещей. Вы не можете просто сказать, что ваши международные скорости постоянны. У удаленных пользователей всегда будет более низкая производительность, в зависимости от сети между вами и ними и от того, насколько она загружена.
Кстати, вы сказали, что ваша пропускная способность исчерпана. Пропускная способность сетевого подключения вашего сервера? Тогда вам действительно понадобится CDN или кеширующие обратные прокси.
Я могу предложить несколько быстрых улучшений:
Согласно пояснение, что это происходило только тогда, когда пропускная способность была максимальной, это может показаться совершенно нормальным поведением, тогда - когда вы максимизируете доступную пропускную способность (до скорости линии), вы можете начать терять пакеты и Окно TCP для клиентов с длинными связями, которые никогда не увеличивались для достижения оптимальной скорости; Продукт задержки полосы пропускания растет, время загрузки того же файла по тому же каналу увеличивается; тебе нужно сделать кое-что формирование трафика (другими словами, организация очереди пакетов и приоритезация) если вы хотите сделать его более равномерным для всех в периоды перегрузки. - cnst 6 октября в 4:56
Хотя скорость света постоянна и данные передаются по оптоволоконным кабелям на большие расстояния с той же скоростью, чем дальше от источника, тем больше «прыжков» он должен пройти.
Если вы запустите traceroute к серверу, находящемуся на расстоянии 100 миль, а затем сравните этот traceroute с сервером, который находится на полпути через земной шар, то сервер на полпути через земной шар, вероятно, пройдет еще много переходов.
Задержка - это время, необходимое для прохождения данных через каждый маршрутизатор (переход), прежде чем они достигнут пункта назначения, и проблема здесь заключается в задержке.