Мой веб-сайт загружается медленнее, чем я думаю, из-за того, что некоторые ресурсы загружаются с сервера абсурдно долго. Я пытался выяснить причину этого. Я примерно на 95% уверен, что это проблема с сетью, а не с Apache, из-за проведенных мною тестов (см. Ниже).
Вот снимок экрана из инспектора сети Firefox. Обратите внимание, что застрявшие активы обычно представляют собой некоторые из этих изображений, но это произошло с другими активами, такими как файлы Javascript и т. Д.
Моя текущая теория состоит в том, что ограничение пропускной способности нашего colo вызывает потерю пакетов, когда браузер загружает ресурсы параллельно, возможно, на мгновение выше предела пропускной способности. Это разумная теория? Можем ли мы что-то изменить, кроме запроса большей пропускной способности, даже если большую часть времени мы не используем большую часть пропускной способности?
Или есть еще какое-то направление, которое мне нужно исследовать?
traceroute к серверу нормально. traceroute от сервера, скажем, до нашего офиса останавливается примерно через 8 прыжков. Я предполагаю, что это связано с traceroute где-то блокируется трафик (поскольку такие вещи, как wget—См. Ниже— и ssh похоже, в основном работают нормально), но я могу предоставить более подробную информацию, если это уместно.strace на Apache указывает, что сервер немедленно обслуживает весь образ без задержки.tcpdump/wireshark показал, что данные изображения были отправлены немедленно, но затем, позже, некоторые пакеты были переданы повторно. Одна трассировка, в частности, показала, что последний пакет актива был немедленно передан сервером, повторно передан несколько раз, но оригинал пакет был тем, который браузер наконец получил.wget, это происходило не так регулярно, как в браузере. Моя гипотеза состоит в том, что это потому, что wget не распараллеливает загрузки.iperf было интересно. С помощью iperfВ режиме UDP я обнаружил, что у меня практически не было потери пакетов на скоростях до 4 Мбит / с. Более того, я начал видеть потерю пакетов ~ 10%. Точно так же в режиме TCP небольшое количество параллельных соединений разумно разделяет полосу пропускания между ними. С другой стороны, 6 или более параллельных соединений начали получать "пилообразную" полосу пропускания, при которой соединение иногда имело пропускную способность, а не в других случаях.Я был бы рад предоставить более подробную информацию по любому из них, но я не хотел переполнять этот пост неуместными подробностями. Я не достаточно разбираюсь в сетях, чтобы понимать, какая информация полезна, а какая нет. :-D Любые ссылки на другие хорошие инструменты для устранения неполадок в сети будут отличными.
РЕДАКТИРОВАТЬ 1: Разъяснил мою почти уверенность в том, что виноват не Apache, а что-то сетевое.
РЕДАКТИРОВАТЬ 2: Я попытался iperf между этим сервером и другим нашим сервером на том же гигабитном коммутаторе, и мы получили довольно стабильные 940+ Мбит / с. Я думаю, что это исключает большинство проблем с оборудованием или несоответствия дуплексного режима на нашей стороне, за исключением, возможно, восходящего канала.
РЕДАКТИРОВАТЬ 3: Хотя специфика очень разная, этот пост о TCP incast Проблема звучит очень похоже, с точки зрения перетасовки трафика с высокой пропускной способностью по узкому каналу небольшими пакетами и потери пакетов. Мне нужно прочитать его более подробно, чтобы увидеть, применимы ли какие-либо особенности к нашей ситуации.
Наконец-то нашли виноватого. Наш коло формировал трафик на нашем соединении - когда они его отключили, проблема полностью исчезла. Я ожидаю, что мы продолжим работу, чтобы сузить их конфигурацию, но, к счастью, это была не наша конфигурация.
Вы пробовали поставить прокси перед Apache для кеширования данных? Популярным решением для этого является Nginx, который будет прослушивать, скажем, порт 80 (что означает, что вам нужно изменить порт прослушивания Apache, если он также использует 80).
Просто настройте его, чтобы Nginx обслуживал статический контент, такой как JS, CSS, изображения и т. Д., А все остальное передавал Apache через прокси.
Я заметил, что когда я сделал это для своего сайта, он немного улучшил производительность, поскольку Nginx был построен как прокси или автономный сервер IIRC, в то время как Apache был в большей степени вилкой предыдущего веб-сервера, когда проксирование не было очень популярным (если даже подумал).