Назад | Перейти на главную страницу

Таймауты запроса статических файлов, если не запрашиваются заголовками Internet Explorer

Недавно мы провели некоторое обслуживание нашего сервера разработки; мы не знаем, из чего это состояло, поскольку мы не обслуживаем наши серверы. С тех пор мы наблюдаем серию HTTP-запросов, которые длятся более 20 с, прежде чем будут выполнены, или, что более часто, просто тайм-аут. Это огромная проблема для нас, поскольку мы используем некомпилированный RequireJS на сервере разработки, поэтому любая заданная страница выполняет от 100 до 400 запросов на файлы или данные, и даже если все они завершаются успешно, сама страница может занять несколько минут. для загрузки, ожидая завершения запросов. Изначально мы думали, что это какая-то форма защиты от DDoS-атак, поэтому перенесли все на локальные серверы Apache. Однако из-за различий в конфигурации мы пытаемся исправить сервер разработки и переместить все обратно туда.

Мы начали с попытки выяснить, что именно вызывает проблему (Apache, PHP или расширение, MySQL и т. Д.). Первоначально группа, которая управляет нашими серверами, утверждала, что это, скорее всего, наша кодовая база или, возможно, тот факт, что мы используем фреймворк Zend в качестве нашей базы. Изучая это, мы впервые заметили, что запросы PHP никогда не сталкивались с серьезными проблемами. Они могут колебаться во времени, но никогда не прекращаются. Единственные запросы с тайм-аутом относятся к статическим ресурсам, таким как файлы CSS, LESS, JS или HTML. Кроме того, мы исключили длинные запросы MySQL.

Чтобы еще больше усилить это, мы попытались использовать time из интерфейса командной строки PHP, что приводит к ожидаемому времени выполнения, за исключением того, что иногда для фактического запуска процесса требуется ~ 7 секунд. Мы даже продублировали эту проблему с помощью простого скрипта «Hello World», который не загружал Zend. Мы думаем, что этот долгий запуск может быть из-за расширения cURL (https://bugs.php.net/bug.php?id=50410), но не уверены.

Случайно, работая над некоторыми проблемами совместимости с IE9, мы обнаружили, что при использовании IE9 у нас не было абсолютно никаких тайм-аутов, которые воспроизводились в течение нескольких дней при одновременном тайм-ауте других браузеров. Это было удивительно, поскольку мы полагали, что среди всех браузеров есть проблемы, и IE будет одним из них. Что еще более удивительно, мы использовали расширения в Chrome и Firefox, чтобы изменить заголовки запросов на заголовки IE9, и проблема полностью исчезла!

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

Итак, резюмируем:

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

Поскольку вы упомянули, что вы:

  1. тайм-аут только на статических ресурсах
  2. вы недавно перешли на Apache

Вы, должно быть, изучаете конфигурацию Apache. А это совсем другая тема.

Начните исследование с конфигурации и характеристик нагрузки. Поскольку проблема возникает не в IE, а в Chrome и FF (как раз наоборот, чем я обычно вижу), что-то в конфигурации Apache вызывает это.

Смотри заголовки в IE, FF, Chrome - какая разница? Сравните заголовки ответов.

Также ищите:

  1. Ваш апач настроен?
  2. Убедитесь, что вы обслуживаете свой контент локально (локально для Apache)?
  3. Добавьте другие хорошо зарекомендовавшие себя средства для оптимизации обслуживания статического контента с такими вещами, как предварительное сжатие / сжатие, кэширование и т. Д., Есть хороший список вещей.