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

Так начинается статья "Медленная загрузка сайтов и как с ней бороться", опубликованная в "Читальном зале" проекта.

Материал подготовлен к публикации на сайте hostobzor.ru специалистами легендарной хостинговой компании Зенон Н.С.П. и содержит не только подробный анализ причин, по которым возникают проблемы со скоростью загрузки сайтов, но и рекомендации по их устранению. Следует заметить, что среди рекомендаций отсутствует немедленная смена хостинг-провайдера , что только лишний раз подтверждает высокий профессиональный уровень авторов статьи.

Брякнем
1) В качестве оптимизиров php-скриптов упомянут zend, который казалось бы стандарт, и тоже вырос из mmcache, и вроде бы лучший. Однако дано описание mmcache, и тут же упомянуто что eAccelerator лучше mmcache. Плюс слышали что mmcache хостеры недолюбливают ставить, в том числе из-за глюкавости. Опять же, нам казалось что zend более распространен. Поэтому угол освещения темы "оптимизаторов" нам кажется странным. Хотелось бы узнать почему это было написано именно так.
2) В качестве причины "медленной загрузки сайтов" из статьи следует а) узкий канал б) кривой скрипт генерирующий страницу.
Почему не упомянуты в) тормоза у хостера г) медленный рендеринг самой страницы браузером?
Почему не упомянуто как собственно определить причину? Ведь для обычного юзера это самое важное, писалось наверное для него? ибо "необычный" и так знает об этих причинах. А ведь есть ещё ситуации когда долго висит сам запрос к сайту, потом открывается всё мгновенно, почему так?
Сайт рассматривается как единое целое. А бывает что половина картинок на странице не загружается, или грузится долго, хотя первая половина грузится мгновенно (на другом хостинге всё нормально). То есть опять же, как-то (для нас) неполно освещено, а ситуацию наблюдали не один раз, на разных хостингах.
3) Не написано есть ли связь между скоростью генерации страницы скриптом и нагрузки на сервер. А нам вот любопытно например, и смысл осветить этот вопрос видим. Ибо а) слышали что zend ускоряет работу скриптов, но сильнее нагружает сервер б) один раз перенося сайт с одного хостинга на другой, время генерации уменьшилось с 30 секунд до 0.6 секунды, однако новый хостер тут же "выгнал" за большую нагрузку, хотя на старом претензии носили в основном рекомендательный характер.

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

P.S.: Это не столько критика, сколько желание получить ответы на неувиденные моменты.

P.P.S.: При всем при этом не можем не отметить, что в отличии от аналогов, статья написана достаточно грамотно.

Если коротко, то "Мы тут ни при чём" :-)

Я бы на месте хостеров растиражировал бы статью на все свои сайты . В каждый FAQ.
Разрешение на перепечатку от авторов получено. С условием сохранения текста со ссылками и авторства (от себя требую сохранения ссылки на страницу-первоисточник, т.к. материал все же перерабатывался авторами специально для нашего "Читального сайта").

Zend Optimizer не рассматривался подробно вполне сознательно. Он хоть и дает некоторый прирост производительности, в основном, все-таки предназначен для запуска закодированных Zend Encoder'ом скриптов. Ощутимый результат дает использование Zend Platform - но это платный продукт.

Если сравнивать Turck MMCache и eAccelerator, то никаких принципиальных различий не будет. Из этих двух продуктов Turck MMCache выбран в качестве примера лишь потому, что он более известен.

Про глюкавость Turck MMCache... В статье есть такой абзац: "... стоит помнить о том, что не всегда те скрипты, которые корректно работали без оптимизаторов, будут на 100% совместимы с дополнительными модулями к PHP. При подключении того или иного модуля постарайтесь убедиться в том, что написанный вами код совместим с ним."

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


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

Медленный рендеринг страницы браузером - действительно, несколько упустили из виду. Но это очень субъективный фактор. Тем не менее, отметить его, конечно, стоило. Спасибо за замечание.


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

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


Не скажу конкретно про Zend, но опишу, каков вообще основной принцип работы PHP-оптимизаторов - кэшируется (в памяти или на диске) байт-код, получаемый из скрипта. При следующем обращении к скрипту не тратится время на его чтение с диска и парсинг. Еще можно кэшировать сам результат работы скрипта (чаще всего - полученный html-код).

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


Тут, видимо, речь идет лишь о неправильном (неравномерном) распределении ресурсов между пользователями у второго хостера.

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

На новом же хостинге у Вас получалось забрать больше ресурсов. За счет чего Ваши скрипты работали быстрее, но страдали другие клиенты.


Статья действительно предназначена для "среднего" веб-разработчика.

Мы в своей практике, например, неоднократно сталкивались с клиентами, у которых достаточно хорошо и грамотно написан сайт. Но, вот, тормозит - и все тут. Включаем slow_log в MySQL, строим пару индексов... и все начинает летать. Очевидный, вроде бы, момент, но, оказывается, что не для всех. Кто-то вообще про индексы впервые слышит, кто-то просто забыл их построить...


В любом случае - спасибо!

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

MMCache рвет башню апачу. В прямом смысле слова.
Умирает башка и крутяться только сиротки.

Если бы все было так сурово, его бы не использовали.

Сурово, подтверждаю.
За 6 месяцев имели 5 случаев на одном из серверов. Вроде живой, а процессы только уже запущенные крутятся, и всё...
Нестабильность сервера - слишком высокая цена за ускорение работы PHP.
Убили Turck - всё наладилось.

А его и так не используют

ну не надо использовали в свое время и достаточно активно и особых проблем он не вызывал. но, было бы странным предполагать что софт рассчитанный на пхп 4.3.3 будет нормально работать и с пхп 4.4.1 Проект к сожалению был "съеден" зендом а новый - eaccelerator как раз стабильной работы и не может добиться...