Вопрос Часть A ▉ (100 наград, награжден)
Главный вопрос заключался в том, как сделать этот сайт более быстрым. Сначала нам нужно было прочитать эти водопады. Спасибо всем за ваши предложения по анализу показаний водопада. Из приведенных здесь графиков различных водопадов видно главное узкое место: миниатюры, генерируемые PHP. Безрецептурная загрузка jquery из CDN по совету Дэвида получила мою награду, хотя в целом мой сайт был только на 3% быстрее, и при этом не отвечал основным узким местам сайта. Время для прояснения моего вопроса и еще одной награды:
Вопрос, часть B ▉ (100 наград, награжден).
Теперь новое внимание было уделено решению проблемы, которую имели 6 изображений jpg, которые вызывают большую часть задержки загрузки. Эти 6 изображений представляют собой миниатюры, сгенерированные PHP, крошечные и всего 3 ~ 5 КБ, но загружаются относительно очень медленно. Обратите внимание на « время первого байта » на различных графиках. Проблема осталась нерешенной, но награда досталась Джеймсу, который исправил ошибку заголовка, которую RedBot подчеркнул : «Условный запрос If-Modified-Since вернул весь контент без изменений». ,
Вопрос Часть C my (моя последняя награда: 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 Инструменты Водопад | http://tools.pingdom.com
GTmetrix Водопад | http://gtmetrix.com
SHOULD
), чтобы клиенты HTTP 1.1 использовали не более 2 соединений с серверами HTTP 1.1; HTTP 1.0, конечно, гораздо более открыт.Ответы:
Во-первых, использование этих нескольких доменов требует нескольких поисков DNS. Лучше было бы объединить многие из этих изображений в спрайт, а не распространять запросы.
Во-вторых, когда я загружаю вашу страницу, я вижу большую часть блокировок (~ 1.25 с) на all.js. Я вижу, что начинается с (старая версия) jQuery. Вы должны ссылаться на это из Google CDN, чтобы не только уменьшить время загрузки , но и потенциально полностью избежать HTTP-запроса .
В частности, на самые последние библиотеки пользовательского интерфейса jQuery и jQuery можно ссылаться по этим URL-адресам (см. Этот пост, если вам интересно, почему я пропустил
http:
):Если вы используете одну из стандартных тем пользовательского интерфейса jQuery, вы также можете извлечь ее CSS и изображения из Google CDN .
Оптимизировав хостинг jQuery, вы также должны объединить
awmlib2.js
иtooltiplib.js
в один файл.Если вы решите эти вопросы, вы должны увидеть значительное улучшение.
источник
У меня была аналогичная проблема , несколько дней назад и я нашел head.js . Это плагин Javascript, который позволяет загружать все файлы JS paralell. Надеюсь, это поможет.
источник
Я далеко не эксперт, но ...
В связи с этим: «Условный запрос If-Modified-Since вернул весь контент без изменений». и мои комментарии.
Код, используемый для генерации миниатюр, должен проверять следующее:
Если любой из них ложен, миниатюра должна быть сгенерирована и возвращена, несмотря ни на что Если они оба верны, то следует сделать следующую проверку:
Если любой из них ложен, кэшированная миниатюра должна быть возвращена.
Если оба они верны, то должен быть возвращен статус 304 http. Я не уверен, требуется ли это, но я также лично возвращаю заголовки Cache-Control, Expires и Last-Modified вместе с 304.
Что касается GZipping, мне сообщили, что нет необходимости в GZip изображениях, поэтому игнорируйте эту часть моего комментария.
Изменить: я не заметил ваше добавление к вашему сообщению.
Я также уверен, что ваш код должен проверить заголовок HTTP_IF_MODIFIED_SINCE и отреагировать на него. Простая установка этих заголовков и вашего файла .htaccess не даст требуемого результата.
Я думаю, вам нужно что-то вроде этого:
источник
If Modified Since
вопрос , кажется, работает сейчас Тем не менее, длинные заголовки / время ожидания для крошечных больших пальцев еще не решены ...Вау, сложно объяснить что-либо с помощью этого изображения ... Но здесь некоторые попытки:
источник
Простое предположение, потому что этот вид анализа требует большого A / B-тестирования: кажется, что ваш домен .ch труднодоступен (длинные зеленые полосы до появления первого байта).
Это будет означать, что либо веб-сайт .ch плохо размещен, либо у вашего интернет-провайдера нет хорошего пути к ним.
Учитывая диаграммы, это может объяснить большой удар по производительности.
Кстати , есть этот крутой инструмент cuzillion, который может помочь вам разобраться с вещами в зависимости от того, какой порядок загрузки ресурсов у вас есть.
источник
Попробуйте запустить тесты Y! Slow и Page Speed на своем сайте / странице и следуйте инструкциям, чтобы устранить возможные узкие места в производительности. Вы должны получить огромный прирост производительности, как только наберете больше очков в Y! Slow или Page Speed.
Эти тесты подскажут вам, что не так и что нужно изменить.
источник
То есть ваш скрипт PHP генерирует миниатюры при каждой загрузке страницы? Во-первых, если изображения, которые обрабатываются с помощью большого пальца, меняются не так часто, не могли бы вы настроить кеш так, чтобы их не нужно было анализировать при каждой загрузке страницы? Во-вторых, использует ли ваш PHP-скрипт что-то вроде
imagecopyresampled()
создания миниатюр? Это нетривиальный пример, и PHP-скрипт не будет ничего возвращать, пока не прекратит работу. Использованиеimagecopymerged()
вместо этого снизит качество изображения, но ускорит процесс. И сколько вы делаете сокращения? Являются ли эти миниатюры 5% размером исходного изображения или 50%? Большой размер исходного изображения, вероятно, приводит к замедлению, поскольку PHP-скрипт должен получить исходное изображение в памяти, прежде чем он сможет уменьшить его и вывести уменьшенный эскиз.источник
readfile()
а неfile_get_contents()
сопровождается эхом, который ожидает вывода чего-либо, пока весь файл не будет перемещен в память сценария PHP.Я нашел URL вашего сайта и проверил отдельный файл jpg с домашней страницы. Хотя время загрузки сейчас разумное (161 мс), оно ожидает 126 мс, что слишком много.
Все ваши последние измененные заголовки установлены в субботу, 01 января 2011 г., 12:00:00 по Гринвичу, которая выглядит слишком «круглой» для реальной даты генерации ;-)
Поскольку Cache-control "public, max-age = 14515200", произвольные последние измененные заголовки могут вызвать проблемы через 168 дней.
Во всяком случае, это не настоящая причина задержек.
Вы должны проверить, что делает ваш генератор миниатюр, когда миниатюра уже существует, и что может занять так много времени, проверяя и доставляя изображение.
Вы можете установить xdebug чтобы профилировать скрипт и увидеть узкие места.
Может быть, все это использует фреймворк или подключается к какой-либо базе данных даром. Я видел очень медленный mysql_connect () на некоторых серверах, в основном потому, что они подключались с использованием TCP, а не сокетов, иногда с некоторыми проблемами DNS.
Я понимаю, что вы не можете разместить здесь свой платный генератор, но боюсь, что слишком много возможных проблем ...
источник
Если нет действительно веской причины (обычно ее нет), ваши изображения не должны вызывать интерпретатор PHP.
Создайте правило перезаписи для своего веб-сервера, который будет напрямую обслуживать изображение, если оно найдено в файловой системе. Если это не так, перенаправьте на ваш скрипт PHP для создания изображения. Когда вы редактируете изображение, измените имя файла изображения, чтобы заставить пользователей, которые имеют кэшированную версию, получать вновь отредактированное изображение.
Если это не сработает, по крайней мере, теперь, вы не будете иметь ничего общего с тем, как изображения создаются и проверяются.
источник
Исследовать использование PHP данных сеанса. Может быть (просто возможно), генерирующий изображение PHP-скрипт ожидает блокировки данных сеанса, который блокируется главной страницей, выполняющей рендеринг, или другими сценариями рендеринга изображений. Это сделало бы все оптимизации JavaScript / браузера практически неактуальными, так как браузер ждет сервера.
PHP блокирует данные сеанса для каждого выполняемого сценария, с момента начала обработки сеанса, до момента завершения сценария или при вызове session_write_close (). Это эффективно сериализует вещи. Проверьте страницу PHP на сессиях, особенно комментарии, как этот .
источник
Это просто дикое предположение, так как я не смотрел на ваш код, но я подозреваю, что здесь могут играть роль сессии, следующее из записи PHP Manual
session_write_close()
:Как я уже сказал, я не знаю, что делает ваш код, но эти графики кажутся странно подозрительными. У меня была похожая проблема, когда я закодировал функцию обработки файлов из нескольких частей, и у меня была та же проблема. При обслуживании большого файла я не мог заставить работать многокомпонентную функциональность, и не мог открыть другую страницу, пока загрузка не была завершена. Звонок
session_write_close()
исправил обе мои проблемы.источник
exit();
функция в таких же строках, как иsession_write_close();
? в настоящее время автор исходного кода исследует эту проблему, но, похоже, он тоже немного не в курсе, поскольку его щедрое обновление кода с улучшенной обработкой If-Modified-Since, похоже, имеет те же задержки (новый водопад) Графики производили те же графики, хотя реальные результаты выглядели / чувствовались быстрее загрузки! Это очень странная проблема ...Вы пытались заменить созданные php thumnails обычными изображениями, чтобы увидеть, есть ли разница? Проблема может быть вокруг - ошибка в вашем php-коде, приводящая к регенерации миниатюры при каждом вызове сервера - задержка в вашем коде (sleep ()?), Связанная с проблемой синхронизации - проблема жесткого диска, приводящая к очень плохому состоянию гонки так как все миниатюры загружаются / генерируются одновременно.
источник
Я думаю, что вместо того, чтобы использовать этот скрипт-генератор миниатюр, вы должны попробовать TinySRC для быстрого и быстрого создания миниатюр в облаке. Он имеет очень простой и удобный API, вы можете использовать как: -
http://i.tinysrc.mobi/ [высота] / [ширина] /http://domain.tld/path_to_img.jpg
[ширина] (необязательно): - это ширина в пикселях (которая переопределяет адаптивный или семейный размер). Если префикс «-» или «x», он будет вычитаться или уменьшаться до определенного процента от определенного размера.
[рост] (необязательно): - это высота в пикселях, если ширина также присутствует. Он также отменяет адаптивный или семейный размер и может иметь префикс «-» или «x».
Вы можете проверить сводку API здесь
Вопросы-Ответы
Сколько стоит tinySrc?
Ничего.
Когда я могу начать использовать tinySrc?
Сейчас.
Насколько надежен сервис?
Мы не даем никаких гарантий относительно сервиса tinySrc. Однако он работает в крупной распределенной облачной инфраструктуре , поэтому обеспечивает высокую доступность по всему миру. Этого должно быть достаточно для всех ваших потребностей.
Как быстро это?
tinySrc кэширует изображения с измененным размером в памяти и в нашем хранилище данных на срок до 24 часов , и он не будет извлекать ваше исходное изображение каждый раз. Это делает сервис невероятно быстрым с точки зрения пользователя. (И снижает нагрузку на ваш сервер как хороший побочный эффект.)
Удачи. Просто предложение, так как вы не показываете нам код: p
источник
Поскольку некоторые браузеры загружают только 2 параллельных загрузки для каждого домена, не могли бы вы добавить дополнительные домены для разделения запросов на два-три разных имени хоста. например, 1.imagecdn.com 2.imagecdn.com
источник
Прежде всего, вам нужно обрабатывать
If-Modified-Since
запросы и тому подобное, как сказал Джеймс. Эта ошибка гласит: «Когда я спрашиваю ваш сервер, изменено ли это изображение с прошлого раза, оно отправляет все изображение вместо простого да / нет».Время между соединением и первым байтом - это обычно время, необходимое вашему PHP-скрипту для запуска. Очевидно, что что-то происходит, когда этот скрипт начинает работать.
Генерировать правильные заголовки через приложение немного сложно, плюс они могут быть перезаписаны сервером. И вы подвержены злоупотреблениям, так как любой, кто отправляет заголовки запросов без кэширования, заставит ваш генератор миниатюр работать непрерывно (и поднимать нагрузки). Поэтому, если возможно, попытайтесь сохранить сгенерированные превью, вызывайте сохраненные изображения прямо со своих страниц и управляйте заголовками
.htaccess
. В этом случае вам даже не понадобится ничего,.htaccess
если ваш сервер настроен правильно.Кроме этого, вы можете применить некоторые из ярких идей оптимизации из частей производительности этого общего вопроса о том, как правильно делать сайты , например, разделить ваши ресурсы на поддоменах без файлов cookie и т. Д. Но, во всяком случае, изображение 3k загрузка не должна занимать секунды, это очевидно по сравнению с другими элементами на графиках. Вы должны попытаться определить проблему до оптимизации.
источник
Вы пытались настроить несколько поддоменов в веб-сервере NGINX специально для обслуживания статических данных, таких как изображения и таблицы стилей? Что-то полезное уже можно найти в этой теме .
источник
straight from hdd
. вы имеете в виду вместо этогоstraight from DDR3 RAM
/straight from Solid State Disk
я знаю, что жесткие диски, в отличие от оперативной памяти DDR3 или твердотельных дисков, имеют очень медленное время доступа. Но я чувствую, что это не узкое место здесь ...Что касается отложенных миниатюр, попробуйте сделать вызов flush () сразу после последнего вызова header () в вашем скрипте генерации миниатюр. После этого восстановите график водопадов и посмотрите, есть ли задержка на теле вместо заголовков. Если это так, вам нужно внимательно взглянуть на логику, которая генерирует и / или выводит данные изображения.
Надеемся, что сценарий, который обрабатывает миниатюры, должен использовать какое-то кэширование, чтобы любые действия с изображениями, которые вы обслуживаете, выполнялись только в случае крайней необходимости. Похоже, что каждый раз, когда вы обслуживаете эскизы, происходит какая- то дорогостоящая операция, которая задерживает любой вывод (включая заголовки) из скрипта.
источник
flush();
сразу после заголовков изменений, похоже, нет вообще! Что бы это могло значить?<img src="thumbprocessor.php?src=/folder/image.jpg&w=100&h=200" id="thumbnail"/>
Большая часть медленной проблемы - ваш TTFB (время до первого байта) слишком высокий. С этим трудно справиться, не разбираясь в файлах конфигурации вашего сервера, коде и базовом оборудовании, но я вижу, что он свирепствует при каждом запросе. У вас слишком много зеленых полос (плохо) и очень маленьких синих полос (хорошо). Возможно, вы захотите немного прекратить оптимизацию интерфейса, так как я считаю, что вы многое сделали в этой области. Несмотря на то, что « 80% -90% времени отклика конечного пользователя тратится на внешний интерфейс », я полагаю, что ваше происходит в бэкэнде.
TTFB - это бэкэнд, сервер, предварительная обработка перед выводом и квитирование.
Время выполнения вашего кода, чтобы найти медленные вещи, такие как медленные запросы к базе данных, время входа и выхода из функций / методов, чтобы найти медленные функции. Если вы используете php, попробуйте Firephp . Иногда это один или два медленных запроса, выполняемых во время запуска или инициализации, таких как получение информации о сеансе или проверка аутентификации, а что нет. Оптимизация запросов может привести к хорошим результатам. Иногда код запускается с использованием php prepend или spl автозагрузки, поэтому они запускаются на всем. В других случаях это может быть неправильно настроенный Apache Conf и настройка, которая спасает день.
Ищите неэффективные петли. Ищите медленные вызовы кэшей или медленные операции ввода-вывода, вызванные неисправными дисками или большим использованием дискового пространства. Посмотрите на использование памяти и что используется и где. Запустите повторный тест веб-страницы из 10 прогонов для одного изображения или файла, используя только первый просмотр из разных мест по всему миру, а не из одного места. И читайте ваши журналы доступа и ошибок, слишком многие разработчики игнорируют их и полагаются только на выводимые на экран ошибки. Если у вашего веб-хостинга есть поддержка, обратитесь к ним за помощью, если они все равно не вежливо попросят их о помощи, это не повредит.
Вы можете попробовать DNS Prefetching для борьбы со многими доменами и ресурсами, http://html5boilerplate.com/docs/DNS-Prefetching/
Является ли ваш собственный сервер хорошим / достойным сервером? Иногда лучший сервер может решить множество проблем. Я болею за менталитет « аппаратное обеспечение дешевое, программисты - дорогое », если у вас есть возможность и деньги обновить сервер. И / или использовать CDN , как maxcdn или CloudFlare или аналогичный.
Удачи!
(ps я не работаю ни на одну из этих компаний. Также ссылка на cloudflare выше будет доказывать, что TTFB не так важен, я добавил это, чтобы вы могли получить еще один шанс.)
источник
Извините, вы предоставляете немного данных. И у вас уже было несколько хороших предложений.
Как вы обслуживаете эти изображения? Если вы транслируете их через 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
источник