В старые добрые времена, когда создание web-сайтов представляло из себя такое простое занятие, как набор нескольких HTML -страниц, отправка web-страниц в браузер была простой отправкой файла web-сервером. Посетители сайта могли видеть эти небольшие, исключительно текстовые странички, почти мгновенно (если не считать пользователей медленных модемов). Как только страница была загружена, браузер кэширует её где-нибудь на локальном компьютере, чтобы в случае повторного запроса страницы, можно было взять его локальную версию из кэша, послав лишь короткий запрос, чтобы убедиться, что страница на сервере не была изменена. Запросы обрабатывались быстро и как можно эффективней, и все были счастливы (кроме использующих модемы 9600 бод).
Появление динамических web-страниц изменило положение вещей в худшую сторону, эффективно «сломав» эту модель обслуживания web-страниц благодаря наличию двух проблем:
- Когда сервером получен запрос динамической web-странички, производится некоторая промежуточная обработка, например синтаксический анализ (парсинг) скрипта движком PHP , которая должна быть завершена. Благодаря этому получаем задержку перед тем, как web-сервер начнёт отправку вывода в браузер. Для простого PHP -скрипта это не существенно, но для более сложного приложения движок PHP может выполнить много действий прежде чем страница будет готова для отправки. Эти дополнительные действия приводят к заметной задержке между запросами пользователей и реальным отображением страниц в их браузерах.
- Типичный web-сервер, например Apache, использует время модификации файла чтобы правильно сообщить web-браузеру состояние кэша запрашиваемой странички. Для динамических web-страниц, фактически PHP -скрипт может изменяться только изредка, в то время как отображаемый им контент, возможно располагающийся в базе данных, изменяется часто. Web-сервер не имеет возможности знать о наличии изменений в базе данных, тем не менее он не отправляет дату последней модификации. Если клиент (браузер) не получает никакого признака того, как долго данные являются корректными, он предполагает, что в следующий раз необходимо запросить страничку по новой. Web-сервер всегда будет отвечать обновлённой версией странички, независимо от того, изменились ли данные. Чтобы избежать этого недостатка большинство web-разработчиков используют мета-тэги или HTTP -заголовки, чтобы сообщить браузеру никогда не использовать кэшированную версию странички. Однако это отрицает естественную способность web-браузера кэшировать web-страницы и обладает некоторыми существенными недостатками. Например, содержание динамической странички может изменяться раз в сутки, поэтому выгода, получаемая от наличия даже 24-часового кэширования странички браузером, очевидна.
Обычно для маленьких PHP-приложений вполне можно игнорировать существование этих проблем, однако с увеличением сложности и повышением трафика Вашего сайта Вы можете столкнуться с проблемами. Тем не менее, обе эти проблемы могут быть решены, первая путём кэширования на стороне сервера, вторая путём управления кэшированием на стороне клиента из вашего приложения. Подход, который вы будете использовать для решения проблем, будет зависеть от вашей области применения, но в этой главе мы увидим, как вы можете решить обе проблемы используя PHP и некоторые классы библиотеки PEAR .
Как я предотвращаю кэширование страницы браузерами?
Прежде чем мы рассмотрим методы клиентского и серверного кэширования, в первую очередь мы должны понять, как вообще предотвратить кэширование страниц web-браузером (и прокси-серверами). Основной способ достижения этого использует мета-тэги HTML:
Вставив прошедшую дату в мета-тэг Expires, вы сообщаете браузеру, что кэшированная копия странички всегда является устаревшей. Это значит, что браузер никогда не должен кэшировать страницу. Мета-тэг Pragma: no-cache довольно хорошо поддерживаемое соглашение, которому следует большинство web-браузеров. Обнаружив этот тэг, они обычно не кэшируют страницу (хотя никаких гарантий нет, это всего лишь соглашение).
Это хорошо звучит, но есть две проблемы, связанные с использованием мета-тэгов:
- Если тэг не существовал когда страница была запрошена браузером впервые, но появляется позже (например, вы модифицировали включаемый файл pageheader.php который является шапкой каждой web-страницы), браузер останется в блаженном неведении и воспользуется свей кэшированной копей оригинала.
- Прокси-серверы, кэширующие web-страницы, как например общий ISP , вообще не будет исследовать непосредственно содержимое HTML -документа. Вместо этого они полагаются только на web-сервер, с которого пришли документы, и протокол HTTP . Иными словами, web-браузер может считать, что не должен кэшировать страницу, но прокси-сервер между браузером и вашим web-сервером вероятно не знает этого – и продолжит отправлять клиенту ту же самую, уже устаревшую, страницу.
Лучший подход состоит в том, чтобы использовать непосредственно протокол HTTP с помощью функции PHP header() , эквивалентно приведённым выше двум мета-тэгам:
Мы можем пойти на один шаг вперёд, воспользовавшись заголовком Cache-Control совместимым с браузерами, поддерживающими HTTP 1.1:
Header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); header("Cache-Control: no-store, no-cache, must-revalidate"); header("Cache-Control: post-check=0, pre-check=0", FALSE); header("Pragma: no-cache");
Это гарантирует, что никакой web-браузер или промежуточный прокси-сервер не будет кэшировать страницу, таким образом посетители всегда получат самую последнюю версию контента. Фактически, первый заголовок должен быть самодостаточным, это лучший способ гарантировать, что страница не кэшируется. Заголовки Cache-Control и Pragma добавлены с целью «подстраховаться». Хотя они не работают во всех браузерах или прокси, они отловят некоторые случаи, в которых Expires не работает должным образом (например, если дата на компьютере клиента установлена неправильно).
Конечно, полный отказ от кэширования обеспечивает нас проблемами, которые мы обсуждали в начале этой главы. Сейчас мы рассмотрим решение этих проблем.
Internet Explorer и кэширование загрузки файлов
Если при обслуживании загрузки файла PHP -скриптом используются такие заголовки, как например Content-Disposition: attachment, filename=myFile.pdf или Content-Disposition: inline, filename=myFile.pdf у вас будут проблемы с Internet Explorer ’ом, если вы сообщите браузеру не кэшировать страницу.
Internet Explorer оперирует загрузкой довольно необычным образом, выполняя два запроса к web-сайту. Первый запрос загружает файл и сохраняет его в кэше, пока не будет создан второй запрос (без сохранения отклика). Этот запрос вызывает процесс передачи файла конечному пользователю в соответствии с типом файла (например, запускает Acrobat Reader , если файл является PDF -документом). Это значит, что если вы отправили заголовки, запрещающие браузеру кэшировать страницу, Internet Explorer удалит файл между первым и вторым запросом, в результате чего конечный пользователь ничего не получит. Если файл, который вы отдаёте PHP -скриптом, не изменяется, одним из простейших решений будет убрать «запрещающие кэширование» заголовки из скрипта.
Если загружаемый файл регулярно изменяется (т.е. вы хотите, чтобы браузер загружал новейшую версию), вы должны использовать заголовок Last-Modified , который будет рассмотрен в этой главе позднее, и гарантировать, что время модификации между двумя последовательными запросами не изменяется. Вы должны сделать это таким образом, чтобы не повлиять на пользователей браузеров, правильно оперирующих загрузкой. Одним из решений в этом случае будет сохранение файла на вашем web-сервере и предоставление простой ссылку к нему, предоставив web-серверу сообщать за вас заголовки кэширования. Конечно, это решение не может быть приемлемым, если предполагается авторизованный доступ к файлу, это решение допускает непосредственную загрузку сохранённого файла.
Как я могу захватить данные на стороне сервера для кэширования?
Пришло время взглянуть на то, как мы можем уменьшить задержку при помощи кэширования вывода на стороне сервера. Общий подход начинает предоставлять страницу как обычно, выполняя запросы к базе данных и так далее на PHP . Тем не менее, перед отправкой результата в браузер, мы захватываем его и сохраняем готовую страницу, например, в файле. При следующем запросе, PHP -скрипт сначала проверяет наличие кэшированной версии страницы. Если она существует, скрипт отправляет в браузер версию из кэша, исключая таким образом задержку на повторное создание страницы.
Несколько слов о кэшировании при помощи шаблонов
Как мне управлять кэшированием на стороне клиента средствами PHP?
Пришло время посмотреть на механизм, который позволит нам контролировать кеш на стороне клиента средствами PHP . Этот подход будет работать только если вы используете PHP в связке с сервером Apache , поскольку мы будем использовать функцию getallheaders() , чтобы получить заголовки, передаваемые браузером. Эта функция работает только в Apache .
Новые имена функций
Если вы используете PHP 4.3.0 с Apache , HTTP-заголовки доступны функцией apache_request_headers() и apache_response_headers() . Функция getallheaders() стала псевдонимом для новой функции apache_request_headers() .
Механизмом для работы с кэшем web-браузера вновь является HTTP . Множество заголовков вовлечёны в инструктирование web-браузеров и прокси-серверов независимо кэшировать страницу, ситуация осложняется тем фактом, что некоторые из них доступны только с HTTP 1.1.
Проверка HTTP-заголовков в вашем браузере
Простым но очень удобным инструментом для проверки заголовков запросов и откликов является LiveHttpHeaders – аддон к браузеру Mozilla . Необходимо точно знать, какие заголовки посылает ваш скрипт, особенно когда вы имеете дело с заголовками кэширования HTTP .
Для простоты мы рассмотрим только заголовки кэширования HTTP 1.0, а именно Expires , Last-Modified и If-Modified-Since , а также статус-код HTTP 304 (Not Modified) .
Другие заголовки, доступные с HTTP 1.1, например Cache-Control и ETag , предназначены для обеспечения расширенного механизма, который может использоваться совместно с состоянием web-сессии, иными словами, версия данной страницы, отображаемой неавторизованному посетителю, может значительно отличаться от отображаемой авторизованному пользователю. Заголовки HTTP 1.1 изначально добавлялись для того, чтобы позволить кэшировать такие страницы.
Истечение срока жизни страницы
Самым простым в использовании заголовком является заголовок Expire , который устанавливает дату (возможно, будущую), когда страница устареет. До этого момента web-браузеру разрешается использовать кэшированную версию страницы.
Пример 7. 6.php
"; echo "Сейчас " . gmdate("H:i:s") . " GMT"; echo "Посмотреть вновь
"; ?>
Функция setExpires отправляет заголовок HTTP Expires с будущим временем, заданном в секундах. Вышеприведённый пример показывает текущее время по Гринвичу и выводит ссылку, которая вам позволяет перейти на страницу вновь. Используя кнопку Refresh вашего браузера, вы можете сообщить браузеру о желании обновить кэш. Используя ссылку, вы увидите, что время изменяется только раз в 10 секунд.
Даты и время в HTTP
Даты в HTTP всегда вычисляются относительного меридиана времени Гринвича (GMT). Функция PHP gmdate() точно такая же функция, как date() , за исключением того, что она автоматически компенсирует время по Гринвичу, основанное на системных часах и настройках региона вашего сервера.
Когда браузер сталкивается с заголовком Expires , он кэширует страницу. Все последующие запросы страницы, сделанные до указанного времени истечения срока жизни, используют версию страницы из кэша, никаких запросов к web-серверу при этом не происходит.
Заголовок Expires преимущественно прост в реализации, но в большинстве случаев, если вы не высокоорганизованный человек, вы не можете знать точно, когда данная страница вашего сайта обновлена. Поскольку браузер войдёт в контакт с сервером только после того, как страница устареет, нет ни одного способа сообщить браузеру, что страница, находящаяся в его кэше, устарела. Вы также теряете некоторую часть трафика к вашему web-сайту, поскольку браузер не обращается к серверу при запросе страницы из кэша.
Время изменения страницы
Более практично использовать заголовки Last-Modified и If-Modified-Since , доступные в HTTP 1.0. Технически он известно как выполнение условного GET-запроса, вы возвращаете любой контент, основываясь на условии пришедшего заголовка запроса If-Modified-Since .
При использовании этого метода вы должны отправлять заголовок Last-Modified каждый раз, когда обращаются к вашему PHP-скрипту. При следующем запросе страницы браузером, он отправит заголовок If-Modified-Since , содержащий время, по которому ваш скрипт может определить, обновлялась ли страница со времени последнего запроса. Если это не так, ваш скрипт посылает код статуса HTTP 304 , чтобы указать, что страница не изменялась, не выводя при этом содержимого страницы.
Устанавливаем время модификации кэш-файла этой строкой: $lastModified = filemtime($cache_file);
Затем, используя время модификации кэш-файла, мы посылаем заголовок Last-Modified . Нам нужно посылать её для каждой предоставляемой страницы, чтобы вынудить браузер посылать нам заголовок If-Modified-Since с каждым запросом.
// Выдаём заголовок HTTP Last-Modified header("Last-Modified: " . gmdate("D, d M Y H:i:s", $lastModified) . " GMT"); \n\n"; echo "
\n"; echo "\n"; echo "\n"; ?>Если вы объедините подход времени последнего изменения со значением времени, являющимся уже доступным в вашем приложении (например, время самой последней новостной статьи, или время устаревания из системы серверного кэширования, которое мы видели в последнем решении), вы сможете воспользоваться преимуществами кэша web-браузера и разгрузите канал передачи данных, по возможности сэкономив информационный трафик с вашего сайта и улучшив его производительность.
Будьте осторожны при тестировании любого кэширования, выполненного в таком стиле, если вы сделаете это неправильно, вы можете заставить ваших посетителей всегда иметь устаревшие копии вашего сайта.
Кэширование ваших страниц в 5 шагов
Оригинал: Posted in PHP / JavaScript by ibzi on the February 17th, 2007Перевод: Кузьма Феськов ([email protected] ,http://kuzma.russofile.ru)
Кэширование ваших страниц может оказаться красивым и полезным механизмом, особенно, если они генерируются средствами PHP и делают множество SQL запросов. Как только вы примените кэширование, ваш сервер тут же снизит нагрузку и перестанет съедать много памяти на генерацию страниц - он просто будет загружать их из КЭШа. Я покажу вам, как PHP может кэшировать страницы и, в дальнейшем, вы сможете тратить на это минут 5.
Расмотрим технологию кэширования пошагам:
- В домашней директории создаем файлы .htaccess , start_cache.php , end_cache.php , а также папку с названием cache_files .
- Папке cache_files необходимо проставить атрибуты 777 .
- Внутри .htaccess файла пропишите следующие строки: php_value auto_prepend_file /home/username/public_html/start_cache.php php_value auto_append_file /home/username/public_html/end_cache.php Строку /home/username/public_html/ необходимо заменить на путь к вашей домашней директории.
- В скрипт start_cache.php помещаем следующий код: Не забывайте исправлять путь /home/username/public_html/ на путь к вашей домашней директории.
- А следующий код поместите в скрипт end_cache.php :
Все ваши страницы будут кэшироваться на 3600 секунд = 1 час. Этот параметр вы легко можете поменять в скрипте start_cache.php . Кэш страниц будет сохранен в папке cache_files .
Совершенно очевидно, что в данном случае атрибуты 777 являются определенным нарушением безопасности. В связи с чем, рекомендую вынести папку cahce_files за пределы public_html , например, поместить ее на один уровень выше. Это закроет доступ к находящимся в ней файлам пользователей вашего сайта, но никак не повлияет на работоспособность системы.
Также, у данного метода есть еще один серьезный недостаток: автор статьи складывает весь кэш в одну папку, что, при достаточном количестве страниц на вашем сайте, вызовет проблему, например, в системах Unix наблюдается достаточное замедление работоспособности при наличие в папке более чем 1000 файлов. В связи с чем, в алгоритм необходимо внести ряд изменений и раскладывать файлы по отдельным подпапкам внутри папки cache_files . Например, используя для этого первые 3-4 символа md5 КЭШа.
Для динамических ресурсов вполне возможно выбрать время кэширования в несколько (5-10) секунд или 1-2 минуты, что уже значительно снизит нагрузку на сервер, но не нанесет вреда интерактивности сайта.
Для страниц, для которых особо важна интерактивность, можно ввести исключения в .htaccess , что позволит именно им постоянно изменяться, а для остальных страниц можно применять кэширование.
Регенерация содержания на лету
Динамически созданные, но статически обслуживаемые страницы, т.е. страницы которые должны передаваться как чисто статические (считываемые из файловой системы и затем передаваемые по запросу), однако они должны быть динамически сгенерированны веб-сервером если они отсутствуют в файловой системе. Таким образом вы можете иметь страницы сгенерированные PHP которые являются статически обслуживаемыми если только кто-либо (либо планировщик) не удалит статическое содержание. В таком случае содержание обновляется.
Это делается следующим набором директив:
RewriteCond %{REQUEST_FILENAME} !-s RewriteRule ^page\.html$ page.php
Здесь, запрос к page.html приводит к внутреннему запуску соответствующего page.php, если page.html все-ещё отсутствует или имеет нулевой размер. Фокус здесь в том что page.php это обычный PHP скрипт который в дополнение к собственному выводу, записывает свой вывод в файл page.html. Запустив это один раз, сервер передает данные page.html. Когда вебмастер хочет обновить содержание, он просто удаляет page.html (обычно с помощью cronjob).
Проблема с кэшированием страниц у Internet Explorer.
У IE при работе с заголовком "Vary" встречается одна неприятная ошибочка, связанная с кэшированием страниц. Проблема решается добавлением в.htaccess следующих строк:
Кэширования промежуточных данных является наиболее примитивным и в то же время самым полезным способом оптимизации, где вам не нужно возиться с какими-либо сложными алгоритмами или предварительной оптимизацией. Если вы собираетесь работать с PHP, то должны быть в курсе о проверенных методах и необходимых для этого инструментах, чтобы ваш сайт летал.
Статические локальные переменные
Быстрым и эффективным способом кэширования результатов функции/метода является использование статических локальных переменных. Рассмотрим пример, который выполняет сложные вычисления:
Теперь при каждом использовании функции в коде, независимо от количества вызовов, функция будет выполнять вычисления только один раз.
Эта методика кэширования не зависит от внешних расширений и поддерживается на уровне языка. Поскольку статические локальные переменные доступны только в пределах функции, в которой они определены, обновление кэша может быть проблематичным. Как правило, для этого необходимо передать какую-либо логическую переменную $use_cache или использовать вместо них статические переменные класса.
Статические переменные не разделяются между процессами PHP и могут кэшировать только на короткое время – охватывающее время выполнения сценария. Хорошим кандидатом является метод, который много раз вызывается из нескольких мест, например, для хранения состояния пользователя или результата, требующего большого объёма математических расчетов.
Такая же функциональность может быть реализована с использованием глобальных переменных, но это приведет к загрязнению глобального пространства имен, поэтому так делать не рекомендуется.
Функции разделяемой памяти APC
PHP является полу-компилируемым языком, а это значит, что каждый сценарий компилируется непосредственно не в машинный код, а в промежуточный код, известный как набор опкодов(байт-код). Данный шаг компиляции потребляет много ресурсов процессора и должен выполняться каждый раз при выполнении сценария. APC (Alternative PHP Cache) это расширение, которое пропускает этот шаг компиляции за счет кэширования опкодов в памяти.
Хотя основным назначением APC обычно считается функциональность кэширования опкодов, расширение также включает некоторые дополнительные функции доступа к памяти.
Теперь преимущество такого подхода очевидно - это использование разделяемой памяти. Этот тип памяти является общим для различных процессов/потоков и, в отличие от статических переменных, данные, которые кэшируются таким способом, будут существовать между несколькими запросами.
Чтобы сделать кэш недействительным, можно использовать значения продолжительности существования (TTL), как в примере выше, или следующие функции:
Другие примечания по поддержке разделяемой памяти в APC:
В конфигурационном INI файле есть директива для ограничения размера кэша. С соответствующими значениями TTL это дает возможность задавать приоритет кэшированным данным, когда в случае достижения предела памяти истекшие/старые значения будут исключены из кэша.
С точки зрения производительности - статические переменные всегда будет быстрее, чем функции apc_fetch/apc_store , поскольку доступ к разделяемой памяти должен быть заблокирован и синхронизирован, чтобы предотвратить конфликтные ситуации.
APC является довольно популярным расширением, и поддерживается основными разработчиками PHP и (весьма вероятно) будет поставляться в комплекте с PHP 5.4.
Memcached для больших распределенных кэшей
Как только сайт начинает получать много посещений, в конечном счете, появляется задача распределения нагрузки между различными машинами. В результате этого обычно требуется переместить PHP на несколько серверов приложений. Если вы использовали APC кэширование раньше - каждый сервер приложений теперь имеет отдельный и дублирующий кэш.
Memcached с другой стороны, представляет собой распределенную службу для хранения данных ключ-значение. Расширение может быть развернуто на отдельном выделенном сервере или в том же стеке PHP приложений. Важно понимать, что нет никакой синхронизации/репликации между несколькими Memcached серверами, и они совсем ничего не знают друг о друге. Фактический сервер, который будет использоваться для хранения, выбирается на стороне клиента с помощью алгоритма хеширования на основе предоставленных данных "ключа". Именно поэтому, в отличие от APC, кэшированные данные не дублируются между различными машинами, а память лучше используется для крупных распределенных приложений.
API очень похож на функциональность разделяемой памяти в APC. Тот же пример с обменом валют, реализованный с помощью PHP расширения Memcache:
pconnect("..."); function getCurrencyRates() { global $memcache; $rates = $memcache->get("rates"); if ($rates === false) { // Запрос к базе данных или внешним API функциям $rates = ...; // Курс обмена будет кэширован на 1 час $memcache->set("rates", $rates, 0, 3600); } return $rates; } ?>
Обновление кэша такое же, как и в APC – с использованием TTL функциональности или набора функций.
delete("rates"); // Удаляет кэш $rates $memcache->flush(); // Удаляет все кэшированные данные?>
Локальный APC кэш всегда будет более быстрым методом по сравнению с Memcached.
В сети всегда есть задержки, когда клиенту нужно обмениваться информацией с серверной службой через выделенный текстовый протокол.
Таблицы баз данных в оперативной памяти
Хотя это не относится непосредственно к PHP, многие системы управления базами данных имеют реализацию таблиц, находящихся в оперативной памяти. Данные, хранящиеся в таких таблицах, не сохраняются между перезапусками сервера, гарантированно содержатся в памяти и никогда на выгружаются на диск. Это означает более быстрый доступ к записям, что делает их пригодными для кэширования данных.
MySQL предоставляет таблицы в оперативной памяти в подсистеме хранения данных MEMORY. Хотя данные будут очищены после перезагрузки сервера - схемы таблиц будут сохраняться:
CREATE TABLE test (...) ENGINE = MEMORY
В PostgreSQL есть временные таблицы, которые существуют только во время сессии, чтобы кэшировать данные во временной таблице необходимо поддерживать постоянное соединение с базой данных.
CREATE TEMPORARY TABLE test (...)
В SQLite можно создать в памяти целую базу данных, но с теми же ограничениями, как и в PostgreSQL - данные будут существовать только на время сессии, и понадобится использовать постоянные соединения, чтобы поддерживать их между несколькими запросами.
true)); ?>
Так что же можно сделать с таблицей в оперативной памяти? Хотя такая таблица никогда не будет быстрее доступа к данным ключ-значение в APC/Memcached, вы получаете мощь SQL. Кэшированные данные могут быть отфильтрованы, упорядочены, сгруппированы и даже объединены с другими данными в таблицах.
Простой файловый кэш
Кэш на основе плоских файлов должен быть альтернативой упомянутым выше методам и использоваться только когда система не имеет необходимых расширений или данные, о которых идет речь, не могут храниться в памяти (например, из-за размера)
Поскольку кэширование выполняется для повышения производительности, а оптимизация производительности является результатом высокого параллелизма - всегда следует использовать блокировку файлов, чтобы предотвратить состояние гонки при чтении/записи:
Большинство веб-серверов в состоянии обрабатывать достаточное количество трафика. Возможно вы спросите меня: Зачем же тогда использовать кэш на наших сайтах при помощи PHP? Веб-сервер Apache может обслуживать огромное количество файлов, в тоже время все эти файлы должны быть статическими. Скрипты обрабатываются на веб-сервере, интерпретируются, и дальше сгенерированный HTML файл отправляется в клиентский браузер. Это происходит на веб-сервере, и с участием PHP интерпретатора и на это необходима дополнительная память, нежели просто на отправку HTML файла на веб-клиент. Представьте себе, что произойдет, если вы запустите анализ страниц сайта, который стоит на WordPress, и сколько памяти сервера на этой уйдет.
Веб - это не только живые посетители!
Если на вашем сайте мало посетителей, тогда веб-сервер должен быть в состоянии обработать и показать все страницы для посетителей без каких-либо проблем. Пока все идет хорошо, довольны будете и вы, и ваши посетители. Но что будет если доступ к вашему сайту получит какой нибудь робот? Самый плохой исход из этого, это то, что он может "неестественным путем" замедлить либо вообще привести в неисправность ваш сайт, а также остальные сайты расположенные на этом же сервере!
WordPress Super Cache, обязательный плагин WP
Даже если ваш блог не имеет большого числа посетителей, вы должны установить WordPress плагин Super Cache . Этот плагин работает на большинстве серверов и может спасти жизнь вашего сайта! WordPress использует много запросов к базе данных, чтобы показать одну страницу для посетителя сайта. Каждое соединение с базой нуждается в памяти и будет использовать ресурсы процессора. Используя плагин Super Cache, просматриваемые страницы не будут использовать базу данных, а будут храниться в кэш памяти, и ваш сервер сможет обрабатывать гораздо больше количество трафика.
Кэш функции для PHP сайтов
Существует много способов чтобы использовать кэш на вашем сайте. Есть кэш модули, также можно создать кэш версию каждой страницы сайта при помощи некоторого кода на PHP. Какое решение выбрать вам зависит от ситуации, от приложения и от вида хостинга который вы используете.
Проект eAccelerator
Если вы можете настроить веб-сервер и имеете права суперпользователя root, вы должны попробовать в работе eAccelerator . Он работает как расширение для PHP и может создать кэш версии ваших скриптов. Я испробовал eAccelerator на нескольких серверах, и мне очень понравилось как работает данное расширение.
Кэширование на PHP
Если вы ищите способ как кэшировать отдельные страницы вашего сайта, вы должны попробовать следующие. Приведенный фрагмент кода сможет сохранять отображаемые данные как статически HTML странички. Он будет производить чтение/запись и выводить кэш версию страницы.
// функция получает и записывает данные в файл function get_and_write($url, $cache_file) { $string = file_get_contents($url); $f = fopen($cache_file, "w"); fwrite ($f, $string, strlen($string)); fclose($f); return $string; } // функция которая считывает и помещает данные в выходную переменную function read_content($path) { $f = fopen($path, "r"); $buffer = ""; while(!feof($f)) { $buffer .= fread($f, 2048); } fclose($f); return $buffer; } $cache_file = "/home/user/public_html/cache/cache.page.php"; $url = "http://www.domain.com/page.php"; if (file_exists($cache_file)) { // есть кэш файл? $timedif = (time() - filemtime($cache_file)); // когда был создан файл? if ($timedif < 3600*24) { // получить новый файл $html = read_content($cache_file); // считать содержимое кэша } else { // создать новый кэш файл $html = get_and_write($url, $cache_file); } } else { // нету файла? создать новый кэш файл $html = get_and_write($url, $cache_file); } echo $html; exit;
Этот код очень прост, но не динамичен. Чтобы этот пример работал, необходимо создать список для кэш файлов и URL. Далее приведены некоторые некоторые mod_rewrite правила в соответствии с файловой структурой сайта.
В данном случае мы использует часть URL и передаем эту строку в качестве переменной с помощью запроса. Вот несколько примеров URL:
Http://domain.com/page/ajax-tutorial http://domain.com/page/php-parsing http://domain.com/page/jquery-plugin
В файле.htaccess применяем правило:
RewriteEngine on RewriteRule ^page\/(*)$ /page.php?pageurl=$1 [L]
При обращении по адресу "page/" сделаем небольшую проверку. В файле page.php напишем фрагмент кода, чтобы автоматически генерировать кэш версии страниц.
If (!empty($_GET["pageurl"]) && preg_match("/^*$/", $_GET["pageurl"])) { $cache_file = "/home/user/public_html/cache/cache-".$_GET["pageurl"].".php"; $url = "http://www.domain.com/page.php?page=".$_GET["pageurl"]; } else { header ("HTTP/1.1 301 Moved Permanently"); header("Location: ".$url); exit; }
На этом статья закончена, в скором времени будут опубликованы очень интересные обзоры, которые я готовлю. Поэтому, чтобы следить за блогом.
P.S. Код который я использовал в описании всего лишь пример и вам необходимо изменить его, чтобы он работал в конкретно вашей ситуации.
Ни для кого не секрет, что чем быстрее загружается сайт тем удобнее на нем будет пользователям. Если страницы загружаются быстро пользователи не будут уходить из вашего сайта и поисковики будут относиться к сайту лучше. Для многих современных сайтов узким местом становиться движок выполнения динамических скриптов PHP.
Веб-сервер Nginx при правильной настройке может отдавать просто огромное количество страниц мгновенно, чего нельзя сказать про PHP на генерацию страницы может уходить до нескольких секунд. Но PHP тоже можно ускорить с помощью кэширования. В этой статье мы рассмотрим как настраивается кэширование php, каким оно бывает и зачем вообще это нужно. Для примера будем использовать связку php-fpm и Nginx, но информация из статьи подойдет и для других вариантов установки.
Особенность интерпретируемых языков в том, что при каждом запуске скрипта интерпретатор должен скомпилировать программу и проверить ее на ошибки. Но мы можем обойти. Есть два основных вида кэширования:
- Кэширование готовых страниц - страница генерируется php, а потом пользователю отдается готовая страница без обращения к php. Я расскажу как это сделать через fastcgi, но не рекомендую применять такой метод для wordpress или других движков, их лучше кэшировать с помощью специальных плагинов;
- Кэширование байт кода и инструкций - а это уже интересно, кэшируется не вся страница, а только некоторые инструкции, и куски байт кода, которые не изменяются при вызовах скрипта. Перед тем как выполнять скрипт, интерпретатор должен преобразовать его в понятный для него формат, при кэшировании такое преобразование выполняется только первый запуск, а дальше берется версия из кэша;
- Кэширование сессий - по умолчанию php сохраняет сессии пользователей в файлы и мы можем немного ускорить его работу, если будем сохранять сессии в оперативную память.
Кэширования байткода в PHP
Начиная с PHP 5.5 в интерпретатор языка была добавлена поддержка кэширования байткода из ZendFramework. В новых версиях этот кэш позволяет очень сильно увеличить производительность вашего ресурса, например, есть сведения, что на PHP 7 Wordpres и другие движки работают чуть ли не в два раза быстрее. Перед тем как настраивать кєширование opcode php, нужно установить его пакет:
sudo apt install php-opcache
Или для Red Hat дистрибутивов:
sudo yum install php-opcache
Затем, чтобы включить кэширование нужно добавить несколько строк в php.ini, можно также создать отдельный файл в /etc/php/conf.d/
vi /etc/php.d/opcache.ini
zend_extension=opcache.so;
opcache.error_log=/var/log/php-fpm/opcache-error.log
opcache.enable=1;
opcache.memory_consumption=256;
opcache.interned_strings_buffer=8;
opcache.max_accelerated_files=4000;
opcache.revalidate_freq=180;
opcache.fast_shutdown=0;
opcache.enable_cli=0;
opcache.revalidate_path=0;
opcache.validate_timestamps=2;
opcache.max_file_size=0;
opcache.file_cache= /var/www/сайт/opcache;
Рассмотрим что означают эти строки, чтобы вы знали какие значения установить. Первая строка загружает расширение, здесь ничего менять не нужно.
- opcache.error_log - указывает файл для записи лога ошибок, будет полезно при отладке;
- opcache.log_verbosity_level - указывает насколько подробным должен быть лог файл, значение от 1 до 4;
- opcache.enable - включает кэширование;
- opcache.enable_cli - включает кэширование страниц php для консольной версии;
- opcache.memory_consumption - количество оперативной памяти для хранения кэша;
- opcache.max_accelerated_files - число скриптов/файлов, которые нужно кэшировать;
- opcache.validate_timestamps - проверять время изменения данных в файле скрипта;
- opcache.revalidate_freq - частота проверки для предыдущего параметра;
- opcache.revalidate_path - установите в 0 чтобы выполнять проверку при include только первый раз;
- opcache.enable_file_override - кэширует запросы к атрибутам файлов, например, существование и т д;
- opcache.blacklist_filename - список файлов, которые не нужно кэшировать;
- opcache.max_file_size - максимальный размер файла скрипта для кэширования, 0 - не ограниченно;
- opcache.interned_strings_buffer - допустимое количество строк в буфере;
- opcache.fast_shutdown - использовать быстрый способ освобождения памяти.
После сохранения всех настроек вам останется только перезапустить php или ваш веб-сервер:
systemctl restart php-fpm
Для того чтобы убедиться, что все работает вы можете захотеть посмотреть какие скрипты уже закэшированы. Для этого можно использовать скрипт opcache-status . Просто сохраните скрипт в директорию веб-сервера, а затем дайте ему права:
chmod 777 /var/www/сайт/opcode.php
http://localhost/opcache.php
Здесь можно видеть подробную статистику по кєширвоанию, настройки и количество занятой памяти.
Хранение сессий в memcached
По умолчанию php хранит сессии в файловой системе, в некоторых случаях, вы можете достаточно сильно ускорить работу php, если перенесете хранение сессий из файлов в оперативную память, например, memcached. Сначала нужно установить memcached и php библиотеку для работы с ней:
sudo apt install memcached php-memcached
Или для систем на базе Red Hat:
sudo yum install memcached php-memcached
Сначала нам нужно настроить memcached, откройте файл /etc/sysconfig/memcached и найдите строку CACHESIZE, здесь нужно указать объем оперативной памяти, которая выделяется под кэш:
vi /etc/sysconfig/memcached
session.save_handler = memcache
session.save_path = "tcp://localhost:11211"
Осталось перезапустить ваш php интерпретатор:
systemctl restart php-fpm
Если вы хотите проверить все ли правильно кэшируется и есть ли вообще что-либо в кэше, можно использовать phpmemcacheadmin .
Кэширование страниц fastcgi
Я не советую использовать кэширование fastgci для сайтов WordPress, потому что там есть специальные плагины, которые могут точно контролировать кэш, очищать его когда нужно и вовремя обновлять. Но во всех остальных случаях кэш fastcgi может очень сильно ускорить работу сайта. Настраивается он в конфиге, где вы включаете fastgci, например, в конфигурации веб-сервера Nginx. Минимально для настройки кэша fastgci достаточно добавить в блок server такие строки:
vi /etc/nginx/vhosts/site.conf
fastcgi_cache_path /var/nginx/cache levels=1:2 keys_zone=MYAPP:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
Первая строка настраивает сразу несколько параметров, во первых, она добавляет путь к кэшу, можно использовать любой, только чтобы папка существовала и у веб-сервера были права для записи в нее. Директива levels указывает сколько подпапок будет. Следующая строка указывает что будет использоваться в качестве ключа для кэша. Ключ будет хэширован в md5.
Теперь нужно настроить блок обработки php:
location ~ \.php$ {
fastcgi_pass unix:/var/run/php7-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_cache MYAPP;
fastcgi_cache_valid 200 60m;
}
Здесь мы обращаемся к уже настроенной зоне памяти MYAPP, а также указываем время жизни кэша в один час. Для проверки кэширования можно посмотреть содержимое папки:
ls -lR /var/nginx/cache/
С помощью таких методов ваши страницы будут загружаться намного быстрее. Если вам понадобится отключить кєширование php для отдельных страниц, то сначала создаем переменную no_cache со значением 0:
set $no_cache 0;
Затем проверяем нужные параметры, и если соответствует, то устанавливаем значение в 1:
if ($request_method = POST)
{
set $no_cache 1;
}
И на завершение передаем значение этой переменной таким директивам, это отключит кэширование когда не нужно:
fastcgi_cache_bypass $no_cache;
fastcgi_no_cache $no_cache;
Во время разработки проектов на PHP с нуля и без использования библиотек скорость может стать серьезным вопросом. Кеширование может существенно повлиять на скорость веб страниц. В данном уроке мы покажем простой и эффективный способ динамического кеширования страниц, которые нуждаются в ускорении.
Шаг первый. Создаем файл top-cache.php
Нам нужно создать два файла. Первый: создаем файл с именем top-cache.php и копируем в него следующий код:
\n"; include($cachefile); exit; } ob_start(); // Запуск буфера вывода?>
Что происходит в данном коде? Первые 5 строк создают имя файла кеша в соответствии с текущем PHP файлом. Например, если мы используем файл с именем list.php , файл кеша будет иметь вид cached-list.html .
Строка 6 создает переменную $cachetime , которая определяет время жизни кеша.
Строки с 9 по 13 определяют условное выражение, которое служит для проверки наличия файла с именем, определенным в переменной $cachefile . Если файл существует, вставляется комментарий и файл, определенный в переменной $cachefile . Затем выражение exit прерывает выполнение скрипта и файл отправляется браузеру клиента. То есть, если найден статичный файл, то PHP код не будет выполняться сервером.
Строка 14 создает буфер, если файл, определенный переменной $cachefile не найден.
Шаг второй. Создаем файл bottom-cache.php
Теперь создаем второй файл PHP с именем bottom-cache.php и копируем в него следующий код:
Если файл с именем, определенным в переменной $cachefile отсутствует на сервере, выполняется данный код и создается файл. При следующем обращении к странице статичный $cachefile будет обслуживать браузер клиента вместо выполнения всего кода скрипта PHP.
Шаг три. Включаем файлы кеширования в код страницы
Теперь у нас есть два необходимых файла. Просто включаем их в страницу PHP, которую нужно кешировать. Файл top-cache.php нужно включить в начало страницы, а файл bottom-cache.php - в конце:
Теперь, если проверить кеширование на медленных страницах, то можно убедиться, насколько они стали быстрее загружаться.
