Кэшированные, сгенерированные PHP миниатюры загружаются медленно

Question

Вопрос Часть A ▉ (100 наград, присуждено)
Главным вопросом было, как сделать этот сайт, быстрее загружаться. Сначала нам нужно было прочитать эти водопады. Спасибо всем за ваши предложения по анализу показаний водопада. Из приведенных здесь графиков различных водопадов видно основное узкое место: миниатюры, генерируемые PHP. Загрузка jquery без протокола, полученная от CDN по совету Дэвида, получила мою награду, хотя в целом мой сайт был только на 3% быстрее, и при этом не отвечал основным узким местам сайта. Время для уточнения моего вопроса, и еще одна щедрость:

Вопрос Часть B ▉ (100 наград, присуждено)
Новый фокус теперь должен был решить проблему, которая была у 6 изображений jpg, которые вызывают большую часть задержки загрузки. Эти 6 изображений представляют собой миниатюры, сгенерированные PHP, маленькие и размером всего 3 ~ 5 КБ, но загружаются относительно очень медленно. Обратите внимание на " время до первого байта " на различных графиках. Проблема осталась нерешенной, но награда досталась Джеймсу, который исправил ошибку заголовка, которую RedBot подчеркнул : «Условный запрос If-Modified-Since вернул весь контент без изменений.» .

Вопрос Часть C ▉ (моя последняя награда: 250 баллов)
К сожалению, после исправления даже ошибки заголовка REdbot.org задержка, вызванная сгенерированными PHP изображениями, осталась нетронутой. О чем думают эти крошечные миниатюрные миниатюры размером 3 ~ 5Кб? Вся эта информация заголовка может послать ракету на Луну и обратно. Любые предложения по поводу этого узкого места очень ценятся и рассматриваются как возможный ответ, так как я застрял в этой узкой проблеме уже семь месяцев. Заранее спасибо.

[Некоторая справочная информация на моем сайте: CSS вверху. JS внизу (Jquery, пользовательский интерфейс JQuery, купленные движки меню awm / menu.js, движок tabs js, video swfobject.js) Черные линии на втором изображении показывают, что инициируется для загрузки. Злой робот - мой питомец "ZAM". Он безвреден и часто счастливее.]

---

Загрузка водопада: хронологическая | http://webpagetest.org

---

Параллельные домены, сгруппированные | http://webpagetest.org

---

Сайт-Перф водопад | http://site -perf.com

---

Pingdom Tools Waterfall | http://tools.pingdom.com

---

GTmetrix Waterfall | http://gtmetrix.com

---

Answer 1

Исследовать использование PHP данных сеанса.Может быть (просто возможно), генерирующий изображение PHP-скрипт ожидает блокировки данных сеанса, который блокируется главной страницей, выполняющей рендеринг, или другими сценариями рендеринга изображений.Это сделало бы все оптимизации JavaScript / браузера практически неактуальными, поскольку браузер ожидает сервера.

PHP блокирует данные сеанса для каждого выполняемого сценария, с момента начала обработки сеанса до момента завершения сценарияили когда вызывается session_write_close ().Это эффективно сериализует вещи.Проверьте страницу PHP о сессиях, особенно комментарии, такие как this .

Answer 2

Я думаю, что вместо того, чтобы использовать скрипт-генератор миниатюр , вы должны TinySRC попробовать быструю быструю и размещенную в облаке генерацию миниатюр.Он имеет очень простой и удобный API, вы можете использовать как: -

http://i.tinysrc.mobi/ [высота] / [ширина] / http://domain.tld/path_to_img.jpg

[ширина] (необязательно): - это ширина в пикселях (которая переопределяет адаптивный или семейный размер).Если с префиксом «-» или «x» он будет вычтен или уменьшен до определенного процента определенного размера.

[высота] (необязательно): - Этовысота в пикселях, если ширина также присутствует.Он также переопределяет адаптивный или семейный размер и может иметь префикс «-» или «x».

Сводку API можно посмотреть здесь

---

FAQ

Сколько мне стоит tinySrc?

Ничего.

Когда я могу начать использовать tinySrc?

Сейчас.

Насколько надежна служба?

Мы не даем никаких гарантий относительно сервиса tinySrc.Однако он работает на крупной распределенной облачной инфраструктуре , поэтому обеспечивает высокую доступность по всему миру.Этого должно быть достаточно для всех ваших нужд.

Насколько это быстро?

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

---

Удачи.Просто предложение, так как вы не показываете нам код: p

Answer 3

Вы пытались заменить созданные php thumnails обычными изображениями, чтобы увидеть, есть ли разница?Проблема может быть вокруг - ошибка в вашем php-коде, приводящая к регенерации миниатюры при каждом вызове сервера - задержка в вашем коде (sleep ()?), Связанная с проблемой синхронизации - проблема жесткого диска, вызывающая очень плохое состояние гонкипоскольку все эскизы загружаются / генерируются одновременно.

Answer 4

Поскольку некоторые браузеры загружают только 2 параллельных загрузки для каждого домена, не могли бы вы добавить дополнительные домены в для разделения запросов на два-три разных имени хоста.например, 1.imagecdn.com 2.imagecdn.com

Answer 5

Что касается отложенных миниатюр, попробуйте выполнить вызов flush () сразу после последнего вызова header () в сценарии создания миниатюр. После этого восстановите график водопадов и посмотрите, есть ли задержка на теле вместо заголовков. Если это так, вам нужно внимательно взглянуть на логику, которая генерирует и / или выводит данные изображения.

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

Answer 6

Прежде всего, вам нужно обработать If-Modified-Since запросы и тому подобное, как сказал Джеймс.Эта ошибка гласит: «Когда я спрашиваю ваш сервер, изменено ли это изображение с момента последнего раза, оно отправляет все изображение вместо простого да / нет».

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

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

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

Кроме них, вы можете применить некоторые из ярких идей оптимизации из частей производительности этого общего приятного предложения.ТАК вопрос о том, как правильно сделать сайты , например, о разделении ваших ресурсов на поддоменах без файлов cookie и т. Д. Но, во всяком случае, для загрузки 3k-образа не требуется ни секунды, это очевидно по сравнению сдругие элементы на графиках.Вы должны попытаться определить проблему до оптимизации.

Answer 7

Большая часть медленной проблемы - ваш TTFB (время до первого байта) слишком высок. С этим трудно справиться, не разбираясь в файлах конфигурации вашего сервера, коде и базовом оборудовании, но я вижу, что он свирепствует при каждом запросе. У вас слишком много зеленых полос (плохо) и очень маленьких синих полос (хорошо). Возможно, вы захотите немного прекратить оптимизацию внешнего интерфейса, так как я считаю, что вы многое сделали в этой области. Несмотря на то, что « 80% -90% времени отклика конечного пользователя тратится на внешний интерфейс », я полагаю, что ваше происходит в бэкэнде.

TTFB - это бэкэнд, сервер, предварительная обработка перед выводом и квитирование.

Время выполнения вашего кода, чтобы найти медленные вещи, такие как медленные запросы к базе данных, время ввода и выхода функций / методов, чтобы найти медленные функции. Если вы используете php, попробуйте Firephp . Иногда это один или два медленных запроса, запускаемых во время запуска или инициализации, таких как получение информации о сеансе или проверка аутентификации, а что нет. Оптимизация запросов может привести к хорошим результатам. Иногда код запускается с использованием php prepend или spl автозагрузки, поэтому они запускаются на всем. В других случаях это может быть неправильно настроенный Apache Conf и настройка, которая спасает день.

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

Вы можете попробовать DNS Prefetching для борьбы со многими доменами и ресурсами, http://html5boilerplate.com/docs/DNS-Prefetching/

Является ли ваш собственный сервер хорошим / достойным сервером? Иногда лучший сервер может решить множество проблем. Я болею за «1018 * аппаратное обеспечение дешево, программисты дорогое мышление », если у вас есть шанс и деньги обновить сервер. И / или используйте CDN, например maxcdn или cloudflare или аналогичный.

Удачи!

(p.s. Я не работаю ни на одну из этих компаний. Также ссылка на cloudflare выше расскажет, что TTFB не так важен, я добавил это, чтобы вы могли получить еще один дубль)

Answer 8

Вы пытались настроить несколько поддоменов под NGINX webserver специально для обслуживания статических данных, таких как изображения и таблицы стилей?Что-то полезное уже можно найти в этой теме .

Answer 9

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

Как вы обслуживаете эти изображения? Если вы транслируете их через PHP, вы делаете очень плохие вещи, даже если они уже сгенерированы.

НИКОГДА НЕ ПОТОКИ ИЗОБРАЖЕНИЙ С PHP. Это замедлит работу вашего сервера, независимо от способа его использования.

Поместите их в доступную папку со значимым URI. Затем позвоните им напрямую с их реальным URI. Если вам нужно генерировать на лету, вы должны поместить .htaccess в каталог images, который перенаправляет на php-скрипт генератора, только если изображение запроса отсутствует. (это называется стратегией кэширования по запросу).

Это исправит сеанс php, прокси-браузер, кеширование, ETAGS, все что угодно одновременно.

WP-Supercache использует эту стратегию, если она правильно настроена.

Я написал это некоторое время назад (http://code.google.com/p/cache-on-request/source/detail?r=8), последние ревизии не работают, но я думаю, что 8 или меньше должны работать, и вы можете взять .htaccess в качестве примера просто для проверки (хотя есть лучшие способы настройки .htaccess, чем я привык).

Я описал эту стратегию в этом посте (http://www.stefanoforenza.com/need-for-cache/). Это, вероятно, плохо написано, но это может помочь прояснить ситуацию.

Дальнейшее чтение: http://meta.wikimedia.org/wiki/404_handler_caching