Php кэширование: Кэширование в PHP

Содержание

PHP: Введение — Manual

Change language: EnglishBrazilian PortugueseChinese (Simplified)FrenchGermanJapaneseRomanianRussianSpanishTurkishOther

Windows Cache Extension для PHP — это кеширующий модуль, позволяющий увеличить скорость работы PHP-приложений на Windows и Windows Server. Как только вы включаете Windows Cache Extension и он загружается движком PHP, приложения начинают получать все его преимущества без необходимости менять их код.

Модуль включает 5 различных типов кешей. Далее рассказывается про назначение и преимущества каждого типа кеша.

PHP Opcode Cache — PHP является скриптовым языком, который читает входящий поток данных, содержащий текст и/или инструкции языка и выдаёт новый поток данных, обычно в формате HTML. Т.е. на стороне веб-сервера, PHP читает, разбирает, компилирует и запускает PHP-скрипт каждый раз, когда его запрашивает клиент.
Чтение, разбор и компиляция создают дополнительную нагрузку на процессорные ядра и файловую систему сервера, что сказывается на конечной производительности приложения. Кеширование байт-кода (опкода) PHP позволяет держать уже скомпилированный код в разделяемой памяти и использовать его при следующих запросах к тому же скрипту.
Поддержка кеширования опкодов была удалена в Wincache 2.0.0. Так что если она вам нужна, то следует использовать модуль OPcache, который включён в PHP.
File Cache — даже если включено кеширование опкодов, PHP всё равно обращается к файлам на файловой системе. Когда PHP-скрипт размещён в удалённой файловой папке, файловые операции значительно снижают производительность. Windows Cache Extension включает файловое кеширование, которое используется для сохранения контента скриптов в разделяемой памяти, что сильно сокращает количество операций доступа к файловой системе для PHP.
Resolve File Path Cache — скрипты PHP довольно часто включают или оперируют файлами, используя относительные пути. Каждый такой путь сначала нормализуется PHP до абсолютного пути. Когда приложение использует большое количество файлов и обращается к ним по относительным путям, операции выведения абсолютных путей могут негативно сказаться на производительности. Модуль Windows Cache Extension предоставляет инструмент кеширования Resolve File Path, который используется для сохранения сопоставления относительных и абсолютных файловых путей, позволяя снизить количество операций их выведения.
User Cache (доступно с версии 1.1.0) — скрипты PHP могут получить преимущества кеширования в разделяемой памяти посредством API пользовательского кеширования. Объекты и переменные PHP могут быть сохранены в пользовательском кеше и переиспользованы в последующих запросах.
Это может как повысить производительность приложения, так и разделить данные между несколькими процессами PHP.
Session Handler (доступно с версии 1.1.0) — обработчик сессий WinCache может быть использован для сохранения данных сессии в кеше в разделяемой памяти. Это позволяет избежать дисковых операций при записи и чтении данных сессии, что может сильно увеличить производительность, если таких данных много.

There are no user contributed notes for this page.

Кэширование PHP | Losst

Ни для кого не секрет, что чем быстрее загружается сайт тем удобнее на нем будет пользователям. Если страницы загружаются быстро пользователи не будут уходить из вашего сайта и поисковики будут относиться к сайту лучше. Для многих современных сайтов узким местом становиться движок выполнения динамических скриптов PHP.

Но PHP тоже можно ускорить с помощью кэширования. В этой статье мы рассмотрим как настраивается кэширование php, каким оно бывает и зачем вообще это нужно. Для примера будем использовать связку php-fpm и Nginx, но информация из статьи подойдет и для других вариантов установки.

Содержание статьи:

Кэширование PHP

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

Кэширование готовых страниц — страница генерируется php, а потом пользователю отдается готовая страница без обращения к php. Я расскажу как это сделать через fastcgi, но не рекомендую применять такой метод для wordpress или других движков, их лучше кэшировать с помощью специальных плагинов;

Кэширование байт кода и инструкций — а это уже интересно, кэшируется не вся страница, а только некоторые инструкции, и куски байт кода, которые не изменяются при вызовах скрипта. Перед тем как выполнять скрипт, интерпретатор должен преобразовать его в понятный для него формат, при кэшировании такое преобразование выполняется только первый запуск, а дальше берется версия из кэша;
Кэширование сессий — по умолчанию php сохраняет сессии пользователей в файлы и мы можем немного ускорить его работу, если будем сохранять сессии в оперативную память.

Дальше рассмотрим более подробно, как настроить каждый вид кэширования для вашего сервера. Начнем с кэширования opcode 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

opcache.enable_cli=0;
opcache.revalidate_path=0;
opcache.validate_timestamps=2;
opcache.max_file_size=0;
opcache.file_cache= /var/www/losst.ru/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/losst.ru/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

CACHESIZE=256

Дальше осталось указать php использовать memcached для хранения сессий:

vi /etc/php.ini

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;

Не забудьте перезапустить Nginx перед тем как проверять:

systemctl restart nginx

Выводы

В этой статье мы рассмотрели как настроить кэширование php скриптов, разобрали виды кэширования, кэширование opode php, а также как все это работает. Надеюсь, эта информация была полезной для вас.

Оцените статью:

Загрузка…

Кэширование: Кэширование динамического содержимого | Полное руководство по Yii 1.1

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

Для решения этой проблемы мы можем варьировать содержимое кэша в зависимости от имени пользователя, но это было бы очень большой тратой драгоценного места для кэширования практически одинакового содержимого, кроме имени пользователя. Мы также можем разделить страницу на несколько фрагментов и кэшировать их по отдельности, но это усложняет наше представление и делает код слишком сложным. Наилучший способ — использование возможности динамического содержимого, предоставляемой классом CController.

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

Мы вызываем метод CController::renderDynamic() для вставки динамического содержимого в нужное место.

…другое HTML-содержимое…
<?php if($this->beginCache($id)) { ?>
…фрагмент кэшируемого содержимого…
    <?php $this->renderDynamic($callback); ?>
…фрагмент кэшируемого содержимого…
<?php $this->endCache(); } ?>
…другое HTML-содержимое…

В коде выше $callback — это корректный обратный PHP-вызов. Это может быть строка с именем метода текущего контроллера или глобальной функции. Также это может быть массив, ссылающийся на метод класса. Любые дополнительные параметры в методе renderDynamic() должны быть переданы обратному вызову. Обратный вызов должен не отображать динамическое содержимое, а возвращать его.

Настройка кэширования: серверное, браузерное, кэширование PHP | Примеры http-ответов сервера

Кэширование — это “складирование” информации в хранилище быстрого доступа (кэш) для ускорения работы web-сайта. Используется специальный буфер для промежуточного сохранения данных, доступ к которому происходит намного быстрее, чем к источнику данных.

Применительно к сфере хостинга и сайтостроения можно описать несколько ситуаций, в которых используется кэширование:

кэширование страниц и изображений в браузере пользователя;
серверное кэширование страниц сайта;
кэширование кода интерпретатора PHP;
кэширование запросов к базе данных.

HTTP-кэширование страниц и изображений в браузере

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

статические;
динамические.

Статические данные — это файлы:

изображений и шрифтов;
стилей CSS и скриптов JavaScript.

Динамические данные — это вся информация, хранящаяся в базе данных (учетные записи пользователей, списки товаров, новостей и т.д.)

Принцип действия кэширования

1. Когда сайт загружается в браузер, тратится время на получение с сервера всех компонентов, из которых состоит страница.
2. Не изменяющиеся статические данные загружаются лишь один раз, а затем хранятся в файловом кэше браузера на компьютере пользователя.
3. При повторном заходе на страницу браузер уже не закачивает эти данные с сервера, а отображает их прямо из своего кэша, экономя время на загрузку и пропускную способность канала связи с интернетом.

Эта технология называется кэширование интернет-ресурсов в браузере или HTTP-кэширование.

Чтобы управлять HTTP-кэшированием, браузер использует специальные HTTP-заголовки Expires и Cache-control, которые отправляет web-сервер при отдаче страниц.

Примеры заголовков

Просмотреть HTTP-заголовки ответа сервера можно при помощи специальных онлайн-сервисов.
1. Например, в SEO-auditor нужно в специальном поле указать URL проверяемой страницы. Во втором поле выбрать в выпадающем списке браузер, которым вы пользуетесь в данный момент.

2. После этого нажмите на кнопку “Проверить”и дождитесь результата.

Expires: Thu, 21 Aug 2021 01:00:00 GMT
Заголовок означает, что конкретная страница не будет изменяться до часа ночи 21 августа 2021-го года. До истечения этого времени при запросе данного ресурса браузеру необходимо брать ее из кэша, а по истечении — снова скачать с сервера.

Cache-Control: max-age=3600
Заголовок означает, что страница с момента скачивания браузером гарантированно не будет меняться в течение 3600 секунд, то есть одного часа. На протяжении этого времени при повторном запросе браузеру предписано брать ее из кэша.

Также браузер может взаимодействовать с web-сервером, посылая запрос о том, была ли изменена конкретная страница за определенное время. В этом случае web-сервер отправляет вместе со страницей заголовок Last-Modified с указанием времени последнего изменения страницы, например:
Last-Modified: Sun, 1 Aug 2020 01:00:00 GMT.

После этого браузер при каждом обращении к странице посылает заголовок запроса If-Modified-Since, например, If-Modified-Since: San , 1 Aug 2020 01:00:00 GMT.

Если web-сервер знает, что с момента времени, указанного в запросе, страница не менялась, то он отвечает специальным кодом HTTP 304 (Not Modified), увидев который, браузер заберет страницу из кэша. В противном случае происходит загрузка новой версии страницы с сервера (и заодно получение нового заголовка Last-Modified).

К недостаткам этой схемы HTTP-кэширования можно отнести необходимость постоянных запросов от браузера к серверу.

Вместо HTTP-заголовков Last-Modified и If-Modified-Since, можно использовать другую комбинацию заголовков: ETag и If-None-Match, принцип действия которых аналогичен.

Сценарий работы HTTP-кэширования должен выглядеть так.

Нужно, чтобы ответ сервера для запроса браузером страницы содержал сразу два заголовка: Last-Modified и Cache-Control/Expires. Браузер будет выбирать оптимальную стратегию для кэширования, исходя из содержащейся в них информации.

Настройка кэширования в браузере со стороны web-сервера

Рассмотрим, как можно настроить кэширование страниц в браузере для популярного web-сервера Apache.

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

Например, чтобы включить HTTP-кэширование в браузере пользователя для файлов с изображениями сроком на 1 месяц, а для файлов скриптов и CSS — на 1 неделю, нужно добавить следующие строки в файле .htaccess:

Включить отдачу информации для кэширования
ExpiresActive On
#кэшировать изображения один месяц
ExpiresByType image/x-icon «access plus 30 days»
ExpiresByType image/jpeg «access plus 30 days»
ExpiresByType image/png «access plus 30 days»
ExpiresByType image/gif «access plus 30 days»
#кэшировать файлы-иконки один год
ExpiresByType image/ico «access plus 365 days»
#кэшировать css, javascript файлы одну неделю
ExpiresByType text/css «access plus 7 days»
ExpiresByType text/javascript «access plus 7 days»
ExpiresByType application/javascript «access plus 7 days»
ExpiresByType application/x-javascript «access plus 7 days»

Схема настройки кэширования скриптов

У пользователей VPS/VDS и выделенных серверов есть полный контроль над работой своего сервера. Они могут, вместо применения .htaccess, изменять конфигурацию web-сервера соответствующим образом для отдачи нужных HTTP-заголовков. Для этого необходимо зайти в конфигурационный файл web-сервера. В зависимости от версии веб-сервера и дистрибутива, нужный файл может располагаться по пути /usr/local/apache2/conf/httpd.conf или /etc/httpd/conf/httpd.conf.

Для управления кэшированием в браузере используют заголовок Cache-Control. Например, добавление заголовка в указанный файл Cache-Control: private, max-age=60 будет кэшировать результат запроса в браузере на 60 секунд.

Кэширование страниц сайта на сервере

Второй тип кэширования, с которым сталкиваются владельцы сайтов, — это кэширование страниц сайта на сервере.

Простая схема отдачи для пользователя динамических страниц выглядит так:
1. Web-сервер запрашивает информацию из базы данных (или других источников).
2. Затем из этих данных создает HTML-код страницы.

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

Выгода от такого подхода понятна: экономия времени и аппаратных ресурсов сервера.

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

Схема работы серверного кэширования для самописного сайта на PHP

Ускорение WordPress с помощью кэширования

Практически для всех популярных CMS существуют модули серверного кэширования страниц. Рассмотрим на примере CMS WordPress, как настраивается такой модуль и режим кэширования.

Дополнительные модули для WordPress распространяются в виде плагинов. Разработано много различных плагинов WordPress, обеспечивающих серверное кэширование, например:

Один из самых популярных плагинов кэширования — это LiteSpeed Cache.

1. Чтобы его установить, зайдите в панель администрирования WordPress и найдите раздел “Плагины”.
2. Нажмите на кнопку “Установить”.

3. После установки LiteSpeed Cache он появится в списке плагинов, и нужно будет его активировать в WordPress.

4. После активации LiteSpeed Cache сразу готов к работе и производит кэширование страниц сайта со стороны сервера.
5. Для тонкой настройки опций кэширования вам станет доступен специальный раздел в административной панели WordPress.

Этот плагин также поддерживает кэширование страниц сайта в оперативной памяти сервера, что дает еще большую скорость, по сравнению с использованием кэширования на диске.

Для этого на сервере должно быть установлено программное обеспечение Redis или Memcached.

Их установка подходит для пользователей услуги VPS/VDS и выделенных серверов.

Авторы плагина даже разработали свой собственный web-сервер LiteSpeed, в комбинации с которым этот плагин работает наиболее эффективно.

Для серверного кэширования сайтов на WordPress использование LiteSpeed Cache как автоматически настроенной услуги предлагают многие провайдеры виртуального хостинга в рамках особых тарифных планов “Хостинг WordPress”.

Кэширование PHP-скриптов

Эта техника кэширования непосредственно касается сайтов, созданных на языке программирования PHP, и используется на VPS/VDS и выделенных серверах.

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

Механизм кэширования этих кодов работает по принципу: если код конкретной страницы не изменялся, то можно использовать уже готовые опкоды для этой страницы и не проводить заново процесс разбора кода и его преобразования.

Для этого используется специальное расширение PHP OPCache, которое занимается оптимизацией и кэшированием опкодов.

Вы как администратор сервера можете самостоятельно настроить свою систему и подключить на сервере расширение OPCache для движка PHP.

Данный метод экономит вычислительные ресурсы сервера и хорошо помогает ускорить работу нагруженных сайтов с высокой посещаемостью.

Кэширование запросов к базе данных

Современные системы управления базами данных, такие как MySQL, поддерживают кэширование запросов прямо “из коробки”.

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

Пользователи VPS/VDS и выделенных серверов могут управлять количеством оперативной памяти, выделяемой под кэширование запросов к базе данных. Для нагруженных сайтов с большим объемом данных в базе и высокой посещаемостью оптимальный размер кэша запросов может достигать нескольких сотен мегабайт.

Решено: Как отключить eAccelerator, OPcache или Xcache в ISPmanager, Cpanel, Plesk?

eAccelerator

Полностью отключить eAccelerator нельзя. Внесение директив в файл php.ini также не поможет, так как большинство CMS смотрят на само наличие eAccelerator на сервере. Удалить eAccelerator тоже не представляется возможным — для части клиентов его наличие является необходимым.

Если ваш проект работает некорректно с eAccelerator, в качестве решения проблемы мы рекомендуем использовать сборку PHP c OPcache или Xcache. Для этого нужно сменить версию PHP на версию с поддержкой OPcache или Xcache по инструкции Как сменить версию PHP на хостинге. На странице Хостинг с PHP вы можете посмотреть, какие версии PHP поддерживают эти модули.

OPcache и Xcache

Отключение OPcache или Xcache происходит в конфигурационном файле php.ini. Сначала установите на файл php.ini права 600 или 644 (rw-r—r—) по инструкции Как изменить права на файлы и папки. Затем внесите изменения в файл php.ini по одной из инструкций ниже:

1. Войдите в панель управления хостингом.
2.
Выполнение этого шага зависит от пути, по которому хранятся настройки PHP. Подробнее в статье Где находятся настройки версий PHP в ISPmanager.
- Если вы храните настройки PHP отдельно для каждого домена по пути /var/www/php-bin/имя-домена/php.ini, в разделе «Главное» нажмите Менеджер файлов. Перейдите в каталог /var/www/php-bin/имя-домена/. Выберите файл php.ini и нажмите Изменить:
- Если вы используете общую версию PHP и храните настройки для всех доменов по пути /var/www/php-bin-php(номер-версии)/php.ini, в разделе «Главное» нажмите Менеджер файлов. Перейдите в каталог /var/www/php-bin-php(номер версии)/. Выберите файл php.ini и нажмите Изменить:
3.
В зависимости от того, какое расширение вы хотите отключить, пропишите строку в редакторе:
```
# отключить OPcache 
opcache.enable = Off

# отключить Xcache 
xcache.cacher = Off
```
4.
Сохраните изменения и закройте файл.

1. Войдите в панель управления хостингом.
2.
В разделе «Файлы» нажмите Диспетчер файлов:
3.
Перейдите в каталог php-bin/имя-домена. Кликните по строке с файлом php.ini и нажмите Edit:
4.
В зависимости от того, какое расширение вы хотите отключить, пропишите строку в редакторе:
```
# отключить OPcache 
opcache.enable = Off

# отключить Xcache 
xcache.cacher = Off
```
5.
Сохраните изменения и закройте файл.

1. Войдите в панель управления хостингом.
2.
В разделе «Файлы» перейдите в каталог etc/имя-домена. Кликните по строке с файлом php.ini и нажмите Редактировать как код:
3.
В зависимости от того, какое расширение вы хотите отключить, пропишите строку в редакторе:
```
# отключить OPcache 
opcache.enable = Off

# отключить Xcache 
xcache.cacher = Off
```
4.
Сохраните изменения и закройте файл.

Готово, вы отключили расширение.

Помогла ли вам статья?

14 раз уже
помогла

Кэширование PHP | Losst | DevsDay.ru

Веб-сервер Nginx при правильной настройке может отдавать просто огромное количество страниц мгновенно, чего нельзя сказать про PHP на генерацию страницы может уходить до нескольких секунд. Но PHP тоже можно ускорить с помощью кэширования. В этой статье мы рассмотрим как настраивается кэширование php, каким оно бывает и зачем вообще это нужно. Для примера будем использовать связку php-fpm и Nginx, но информация из статьи подойдет и для других вариантов установки.

Содержание статьи:

Кэширование PHP

Кэширование готовых страниц — страница генерируется php, а потом пользователю отдается готовая страница без обращения к php. Я расскажу как это сделать через fastcgi, но не рекомендую применять такой метод для wordpress или других движков, их лучше кэшировать с помощью специальных плагинов;
Кэширование байт кода и инструкций — а это уже интересно, кэшируется не вся страница, а только некоторые инструкции, и куски байт кода, которые не изменяются при вызовах скрипта. Перед тем как выполнять скрипт, интерпретатор должен преобразовать его в понятный для него формат, при кэшировании такое преобразование выполняется только первый запуск, а дальше берется версия из кэша;
Кэширование сессий — по умолчанию php сохраняет сессии пользователей в файлы и мы можем немного ускорить его работу, если будем сохранять сессии в оперативную память.

Кэширования байткода в 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/losst.ru/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

chmod 777 /var/www/losst.ru/opcode.php

Дальше можно открыть скрипт в браузере для просмотра статистики:

http://localhost/opcache.php

Здесь можно видеть подробную статистику по кєширвоанию, настройки и количество занятой памяти.

Хранение сессий в memcached

sudo apt install memcached php-memcached

Или для систем на базе Red Hat:

sudo yum install memcached php-memcached

vi /etc/sysconfig/memcached

CACHESIZE=256

Дальше осталось указать php использовать memcached для хранения сессий:

vi /etc/php.ini

session.save_handler = memcache session.save_path = "tcp://localhost:11211"

Осталось перезапустить ваш php интерпретатор:

systemctl restart php-fpm

Кэширование страниц fastcgi

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";

Теперь нужно настроить блок обработки 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; }

ls -lR /var/nginx/cache/

set $no_cache 0;

Затем проверяем нужные параметры, и если соответствует, то устанавливаем значение в 1:

if ($request_method = POST) { set $no_cache 1; }

fastcgi_cache_bypass $no_cache; fastcgi_no_cache $no_cache;

Не забудьте перезапустить Nginx перед тем как проверять:

systemctl restart nginx

Выводы

Оцените статью:

Загрузка…

Запрет кэширования посредством PHP. Справочник по PHP

Понимание кеширования PHP. Все дело в кеширующем младенце! —

Что такое PHP?

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

Что такое кеширование?

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

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

Другой пример — Twitter или новостная лента.Необязательно 10 раз просматривать один и тот же новостной сайт или ленту Twitter. Просто сделай это один раз.

Объяснение кеша Varnish. Если вы новичок в Varnish и хотите узнать больше об этом невероятно быстром инструменте кэширования, то этот пост для вас. Мы поговорим о том, что такое лак, как он работает и кому он подходит.

Поваренная книга программиста

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

PHP также кэширует вызовы API. API — это то, как один веб-сайт получает контент с другого. Например, внутристраничная реклама работает с API. Но это противоположный пример, поскольку вы не кешируете рекламу, поскольку рекламодатель показывает разные объявления разным людям.

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

PHP сам по себе не кэширует. Но существуют фреймворки с открытым исходным кодом, позволяющие программисту разрабатывать свой код таким образом. Другими словами, он позволяет коду проверять, были ли данные уже получены, перед отправкой и извлекает их снова, что является относительно медленным процессом, поскольку он должен запрашивать базу данных.Благодаря фреймворку программисту не нужно беспокоиться о технических деталях кеширования, поэтому его легко использовать.

Кэширование PHP и WordPress

WordPress не запрограммирован на использование кеша PHP. Но вы можете добавить для этого плагины W3 Total Cache или WP Super Cache. Это также поможет ускорить публикацию вашей системы управления контентом. И любой собственный код WordPress, который вы пишете, может использовать кеширование, если вы добавите фреймворк.

Кэширование также работает с виджетами. Виджеты — это предварительно запрограммированные фрагменты кода, которые выполняют некоторые общие функции, например, проверяют фразу CAPTCHA.Эти виджеты почти всегда кодируются на PHP, поскольку WordPress написан на PHP.

Настройка кэша

Итак, если вы мыслящий человек, а мы предполагаем, что так оно и есть, поскольку все наши клиенты — умные люди, тогда вы можете сказать: «Это не панацея. Как он может узнать, какие последние 5 заголовков из новостей? » не проверяя это. Ответ — нет.

Кэширование зависит от размера и времени. Таким образом, вы можете установить время кеширования на 5 секунд или 5 минут.

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

Также его можно настроить по размеру, чтобы действительно загруженные сайты очищали кеш и снова заполняли его после определенного количества обращений к странице.

Изоморфное программирование

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

Facebook работает так. Внутренний код выталкивает код JavaScript, который обрабатывает взаимодействие с пользователем.Это делает веб-страницу очень быстрой. Вы заметите изоморфные страницы, когда посмотрите на Facebook и что-то щелкнете: это не перезаписывает адресную строку в браузере.

Это означает, что он заменяет способы программирования GET и PUT логикой in situ, которая извлекает только то, что изменилось. Вся страница в основном состоит из JavaScript. Посмотрите на код Facebook, и вы увидите, что почти вся страница написана на JavaScript.

Итог

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

От Varnish до MemCached, до множества готовых плагинов кэширования PHP, доступных для различных CMS, кэширование теперь встроено в рабочий процесс каждого уважающего себя программиста PHP. Мы надеемся, что вам понравилось это краткое введение в мир кэширования PHP, и если у вас есть какие-либо вопросы — оставьте комментарий ниже.

Томас

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

Производительность

— Выбор метода кэширования PHP: кэширование вывода в файлы или кеширование кода операции

Вы знаете, для меня optcache, filecache и т. Д. Используются только для уменьшения количества обращений к базе данных. Они не могут ускорить ваш код. Однако они улучшают загрузку страницы, используя кеш для обслуживания посетителей.

Что касается меня, APC достаточно хорош для VPS или выделенного сервера, когда мне нужно кэшировать виджеты, $ object для сохранения моего сервера mySQL.

Если у меня более 2 серверов, мне нравится использовать Memcache, они хорошо используют память для кеширования. Однако решать вам, не всем нравится memcached, и не всем нравится APC.

Для кеширования всей веб-страницы я использовал много WordPress и использовал APC, Memcache, Filecache в некоторых плагинах кеширования, таких как W3Total Cache. И я вижу (мой собственный опыт): Filecache хорош для кеширования всего веб-сайта, кеш памяти хорош для кеширования объекта $

Filecache увеличит ваш процессор, если ваш жесткий диск работает медленно, и кеш памяти ужасен, если у вас недостаточно памяти на вашем VPS.

Жесткий диск SSD обеспечивает очень хорошую скорость чтения / записи файла, но память всегда быстрее. Однако Человек не может увидеть, в чем разница между этими скоростями. Вы выбираете только один метод для своего проекта и вашего сервера (RAM, HDD) или используете общий веб-хостинг?

Если я нахожусь на общем хостинге, без прав root, без php.ini, мне нравится использовать phpFastCache, это простой метод кеширования файлов с только set, get, stats, delete.

Кроме того, люблю пользоваться.htaccess для кеширования статических файлов, таких как изображения, js, css или заголовками html. Они помогут посетителям ускорить вашу страницу и сэкономить пропускную способность вашего сервера.

И если вы можете использовать .htaccess для перенаправления в статический кеш .html, если вы кешируете всю страницу, это здорово.

В будущем APC или какой-либо Optcache будут включены в версию PHP, но я уверен, что весь кеш не может ускорить ваш код, они используют для:

Уменьшите количество обращений к базе данных / запросам.
Повышение скорости загрузки страницы за счет использования кеша для обслуживания.
Сохраните транзакции API (например, Bing) или запрос cURL …

и т.д …

Более быстрый веб-сайт с кешем PHP и кешированием объектов

У вас есть динамический веб-сайт, созданный с использованием MySQL и PHP? Если ваш веб-сайт и аудитория растут, возможно, возникла проблема с его производительностью. Без какого-либо механизма кэширования ваш сайт становится медленным, если ваш сайт получает больше посетителей, чем может обработать веб-сервер. Хотите узнать больше о кешировании PHP, Redis и Memcached? Продолжайте читать…

Зачем вашему сайту нужен кеш PHP?

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

Например…

Мы протестировали страницу из веб-сайта, созданного с помощью WordPress. Мы провели первый тест без включения кеширования. Во время теста оба процессора должны были работать интенсивнее, и нагрузка была немного высокой. На момент посещения веб-сайта 50 одновременных пользователей было использовано 15 процессов PHP.Время загрузки URL-адреса (95-й процентиль) было выше 100 мс.

Затем мы провели тот же тест с включенным кешированием. Нагрузка была намного ниже, а ЦП вообще не использовался. На тот момент, когда сайт посетили 50 одновременных пользователей, было использовано всего 5 процессов PHP. Кешированная версия была намного быстрее: время загрузки URL составляло менее 50 мс (95-й процентиль).

Разница не такая большая, за исключением количества PHP-процессов (15 против 5).

Какой PHP-кеш можно использовать для ускорения работы своего сайта?

Существуют разные типы кэшей, и все они имеют разные функции.В наш список включены только типы кеша на стороне сервера, которые используются вместе со скриптами PHP. Другие типы кешей, такие как кеш браузера, кеш базы данных или кеш прокси, не рассматриваются в данной статье.

Кэширование всей страницы

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

Если вы выполните поиск по запросу «php cache», вверху вы найдете веб-сайт PHP Cache.Компания по кешированию PHP является хостом для различных библиотек кеширования PHP и адаптеров для APC, Redis, MemCached, FileSystem и многих других. Их библиотеки PHP не очень хорошо поддерживаются в последнее время, и они советуют использовать для новых проектов компонент Symfony Cache.

Sinds. Большинство профессиональных библиотек являются частью более крупных фреймворков PHP, не так-то просто найти хорошую библиотеку кеширования PHP. Но я нашел один…

PageCache

Эта библиотека кеширования, возможно, лучший выбор для начинающего разработчика PHP.Его легко установить, и вы можете адаптировать необходимый код к существующим сценариям PHP. Даже если ваш веб-сайт на основе PHP более старый и написан с использованием процедурного кода, PageCache — хороший выбор. Ниже приводится краткое изложение наиболее важных характеристик.

Работает «из коробки» с нулевой конфигурацией!
Адаптер кеш-памяти, совместимый с PSR-16 (Redis или Memcached).
Встроенное кеширование страниц для мобильных устройств.

PageCache Пример PHP

Как я уже сказал, использовать PageCache просто.Просто установите библиотеку с помощью Composer и добавьте следующий фрагмент кода PHP в верхнюю часть вашего сценария PHP, и библиотека кеширования PHP создаст и предоставит кэшированный файл.

Кэш страниц PHP и популярные фреймворки

Если вы начинаете новый проект, вам всегда следует подумать об использовании фреймворка PHP, такого как Laravel, Symfony, CodeIgniter, Yii или Zend. Они предлагают все свои собственные подключаемые модули или компоненты кеширования PHP. Если вы используете PHP-фреймворк, вам не нужно писать весь код, потому что наиболее важные библиотеки уже включены в комплект.Вам не нужно самостоятельно выбирать (и тестировать) все необходимые библиотеки.

Большинство компонентов кэша PHP могут кэшировать целые страницы PHP, а также предоставляют адаптеры для кеширования объектов с Redis или Memcached.

Кэширование объектов

В то время как кеширование всей страницы происходит в вашей файловой системе, кеш объектов работает совершенно иначе. Кэширование объектов в основном используется для хранения строк, объектов массивов или даже наборов результатов базы данных. Эти объекты хранятся в оперативной памяти, а иногда и в базе данных.В этом сообщении в блоге я расскажу вам больше о двух системах хранения, которые вы можете использовать в качестве кеша объектов: Memcached и Redis.

Что такое Memcached?

Memcached был первоначально разработан Брэдом Фицпатриком в 2003 году. Это довольно давно, в том же году мы использовали PHP 4 и MySQL 3.2.3. Вы можете использовать Memcached с разными языками программирования, а для PHP есть 2 расширения, одно называется как объектный кеш, а другое — Memcache (обратите внимание на отсутствующую букву «d»). Не используйте последний, он не очень ухожен.

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

PHP Пример Memcached

Добавление и чтение объектов очень простое и требует меньше кода, чем добавление / получение той же информации из базы данных MySQL.

Кэш объектов Redis

Redis — это хранилище структур данных в памяти, которое в основном поддерживается Сальваторе Санфилиппо и спонсируется Redis Labs. Вы можете установить расширение phpredis с помощью PECL.В настоящее время вы не можете найти никакой информации об этом расширении в документации PHP. На самом деле это не проблема, потому что Redis очень популярен в мире разработки, и в Интернете доступно много информации.

Пример PHP Redis

Функции или методы очень похожи на код, который мы использовали для Memcached.

Какой объектный кеш выбрать — решать вам, и то, и другое быстрое и простое в использовании. Лично мне нравится структурированная документация PHP для Memcached.

Вы понимаете, почему библиотеки и фреймворки PHP используют адаптеры для Redis или Memcached. Вы можете использовать одни и те же методы для хранения данных в разных системах кеширования объектов.

Кэширование фрагментов

Этот кэш немного похож на кэширование страницы, но используется для создания кэшированной версии для частей веб-страницы. Это очень полезно, если какая-то часть страницы должна быть динамической. Очень простой пример — текст «Здравствуйте, имя пользователя» на веб-сайте портала, где вся информация одинакова для всех пользователей, кроме имени.

Вы можете хранить фрагменты кода, такие как кеш страниц, через файловую систему или кеш объектов.

Этот кеш PHP работает иначе. Он не кэширует сгенерированный HTML-код, как кеш страницы, а кеширует PHP-код скрипта. PHP OpCache скомпилирует код PHP и сохранит эту версию в оперативной памяти. Таким образом, PHP может обрабатывать PHP-код намного быстрее, используя меньшую мощность процессора. Вот некоторые важные функции PHP в OpCache:

Эта библиотека кеширования PHP является одним из самых крупных проектов и не является частью какой-либо структуры.Если вам нужен кеш для веб-сайта с высокой посещаемостью, PhpFastCache — это то, что вам нужно. Вы можете использовать библиотеку для разных типов кешей, таких как файловый кеш, SQLite, MongoDB, Redis и Memcached.

Пример кода PhpFastCache

С помощью следующего кода мы получаем тот же объект, что и в примере кода Memached. Это немного больше кода, но если вы измените некоторые значения, вы можете использовать тот же код для Redis или другой системы кеширования.

PHP-кеш и WordPress

Как этот веб-сайт (или блог) WordPress, в наши дни я много работаю над веб-разработкой с помощью WordPress.Есть несколько зрелых плагинов кеширования для создания полностраничного кеша, а также несколько плагинов для кэширования объектов с помощью Redis или Memcached. WordPress имеет собственный интерфейс кеширования объектов. Это будет означать, что если вы подключаете API кеширования объектов к Memcached и сохраняете какое-то значение внутри объекта, значение сохраняется не в базе данных, а в Memcached.

Вот список плагинов кеширования WordPress, которые я часто использую.

WP Super Cache

Если ваш сервер основан на Apache, этот плагин кеширования страниц очень быстрый и стабильный.Он поддерживается Automattic, компанией, стоящей за WordPress. Он не предлагает кеширование объектов, но поддерживает кеширование фрагментов (для опытных пользователей).

WP Rocket

Этот плагин кеширования WordPress также является плагином полностраничного кеширования, но у него есть несколько приятных дополнений (интеграция с Cloudflare, пользовательский кеш…) и очень приятный интерфейс. Этот плагин не бесплатный, но, на мой взгляд, стоит каждой копейки. Я использую WP rocket для этого блога, и плагин сэкономил мне 1 секунду времени загрузки (по сравнению с WP Super Cache).

Simple Cache

Этот простой плагин кеширования, разработанный Тейлором Ловеттом, не так популярен, но имеет почти уникальную особенность: кеширование объектов (Memcached или Redis). У него не так много параметров, просто включите кеш, и все готово.

Я нашел Simple cache, когда искал плагин, который хорошо работает с Nginx. В Simple Cache вам нужно изменить только одну строку в конфигурации Nginx. Вы также можете использовать два других плагина для Nginx, но вам нужно изменить (и протестировать) больше конфигураций Nginx.Спросите меня, хотите ли вы узнать, что я изменил в Nginx для WP Rocket.

Заключение

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

Опубликовано в: PHP-скрипты · Разработка веб-сайтов

PSR-6: Интерфейс кэширования — PHP-FIG

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

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

Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом документе должны быть интерпретируется, как описано в RFC 2119.

Цель

Цель данного PSR — позволить разработчикам создавать библиотеки с поддержкой кеширования, которые могут быть интегрированы в существующие структуры и системы без необходимости индивидуальная разработка.

Определения

Библиотека вызовов — Библиотека или код, которому действительно нужен кеш. Сервисы. Эта библиотека будет использовать службы кеширования, которые реализуют это стандартных интерфейсов, но в противном случае не будет знать реализация тех служб кеширования.
Библиотека реализации — Эта библиотека отвечает за реализацию этот стандарт для предоставления услуг кэширования любой библиотеки вызовов.В Библиотека реализации ДОЛЖНА предоставлять классы, реализующие Интерфейсы Cache \ CacheItemPoolInterface и Cache \ CacheItemInterface. Реализация библиотек ДОЛЖНА поддерживать как минимум функциональность TTL, как описано ниже с точностью до секунды.
TTL — Время жизни (TTL) элемента — это количество времени между когда этот элемент хранится и считается устаревшим. TTL обычно определяется целым числом, представляющим время в секундах, или объектом DateInterval.
Срок действия — Фактическое время, когда элемент настроен на устаревание. Это обычно рассчитывается путем добавления TTL ко времени хранения объекта, но также может быть явно задан с помощью объекта DateTime. Предмет с TTL 300 секунд хранящиеся в 1:30:00, будут иметь срок действия 1:35:00. Реализация библиотек МОЖЕТ истекает срок действия элемента до его запрошенного времени истечения срока действия, но ДОЛЖЕН рассматривать элемент как истек после истечения срока его действия. Если вызывающая библиотека запрашивает элемент для сохранения, но не указывает время истечения срока действия или указывает нуль время истечения срока действия или TTL, Реализационная библиотека МОЖЕТ использовать настроенное по умолчанию продолжительность.Если продолжительность по умолчанию не установлена, Библиотека реализации ДОЛЖНА интерпретировать это как запрос на кеширование элемента навсегда или до тех пор, пока базовая реализация поддерживает.
Ключ — Строка по крайней мере из одного символа, который однозначно идентифицирует кешированный элемент. Реализующие библиотеки ДОЛЖНЫ поддерживать ключи, состоящие из символы A-Z , a-z , 0-9 , _ и . в любом порядке в кодировке UTF-8 и длина до 64 символов.Реализация библиотек МОЖЕТ поддерживать дополнительные символы и кодировки или более длинные, но должны поддерживать как минимум это минимум. Библиотеки несут ответственность за собственное экранирование ключевых строк. при необходимости, но ДОЛЖЕН иметь возможность возвращать исходную неизмененную строку ключа. Следующие символы зарезервированы для будущих расширений и НЕ ДОЛЖНЫ быть поддерживается за счет реализации библиотек: {} () / \ @:
Попадание — Попадание в кеш происходит, когда вызывающая библиотека запрашивает элемент по ключу и для этого ключа найдено соответствующее значение, и это значение не истекло, и значение недействительно по какой-либо другой причине.Вызов библиотек ДОЛЖЕН сделать обязательно проверяйте isHit () на всех вызовах get ().
Промах — Промах в кэше противоположен попаданию в кэш. Происходит промах кеша когда вызывающая библиотека запрашивает элемент по ключу и это значение не найдено для этого ключ, или значение было найдено, но срок его действия истек, или значение недействительно для некоторых другая причина. Значение с истекшим сроком действия ДОЛЖНО всегда считаться промахом в кэше.
Отложено — Отложенное сохранение кеша указывает, что элемент кеша не может быть настаивал сразу у бассейна.Объект Pool МОЖЕТ задержать сохранение отложенного элемент кеширования, чтобы воспользоваться преимуществами операций массового набора, поддерживаемых некоторыми двигатели хранения. Пул ДОЛЖЕН гарантировать, что любые отложенные элементы кэша в конечном итоге будут сохраняются, и данные не теряются, и МОГУТ сохранять их до вызова библиотеки просит, чтобы они были сохранены. Когда вызывающая библиотека вызывает commit () все невыполненные отложенные элементы ДОЛЖНЫ сохраняться. Библиотека реализации МОЖЕТ использовать любую подходящую логику, чтобы определить, когда сохранять отложенный элементы, такие как деструктор объекта, сохраняющие все при save (), тайм-аут или проверка max-items или любая другая подходящая логика.Запросы для элемента кеша, который был отложен ДОЛЖЕН возвращать отложенный, но еще не сохраненный элемент.

Данные

Реализующие библиотеки ДОЛЖНЫ поддерживать все сериализуемые типы данных PHP, включая:

Strings — Символьные строки произвольного размера в любой PHP-совместимой кодировке.
Целые числа — Все целые числа любого размера, поддерживаемые PHP, вплоть до 64-битных чисел со знаком.
Floats — Все значения с плавающей запятой со знаком.
Boolean — Верно или неверно.
Null — Фактическое нулевое значение.
Массивы — Индексированные, ассоциативные и многомерные массивы произвольной глубины.
Объект — любой объект, поддерживающий сериализацию без потерь и десериализация таким образом, что $ o == unserialize (serialize ($ o)) . Объекты МОГУТ использовать сериализуемый интерфейс PHP, магические методы __sleep () или __wakeup () , или аналогичные языковые функции, если это необходимо.

Все данные, переданные в библиотеку реализации, ДОЛЖНЫ быть возвращены точно так, как прошедший. Это включает тип переменной. То есть возвращать ошибку (строка) 5, если (int) 5 было сохраненным значением. Реализация библиотек МОЖЕТ использовать PHP serialize () / unserialize () выполняет внутренние функции, но не обязательны для этого. Совместимость с ними просто используется в качестве основы для приемлемых значений объекта.

Если по какой-либо причине невозможно вернуть точное сохраненное значение, реализуя библиотеки ДОЛЖНЫ отвечать промахом в кэше, а не повреждением данных.

Ключевые концепции

Бассейн

Пул представляет собой набор элементов в системе кэширования. Бассейн логический репозиторий всех содержащихся в нем элементов. Извлекаются все кешируемые элементы. из пула как объект предмета, и все взаимодействия со всей вселенной кэширование объектов происходит через пул.

Товаров

Элемент представляет собой одну пару ключ / значение в пуле. Ключ — это первичный уникальный идентификатор для статьи и ДОЛЖЕН быть неизменным.Значение МОЖЕТ быть изменено в любое время.

Обработка ошибок

Хотя кеширование часто является важной частью производительности приложения, оно никогда не должно быть важной частью функциональности приложения. Таким образом, ошибка в системе кеширования НЕ ДОЛЖНА приведет к сбою приложения. По этой причине реализация библиотек НЕ ДОЛЖНА генерировать исключения, отличные от тех, которые определены интерфейсом, и ДОЛЖЕН перехватывать любые ошибки или исключения, вызванные базовым хранилищем данных и не позволяющие им всплывать.

Реализующей библиотеке СЛЕДУЕТ регистрировать такие ошибки или иным образом сообщать о них в администратор по мере необходимости.

Если вызывающая библиотека запрашивает удаление одного или нескольких элементов или очистку пула, НЕ ДОЛЖНО считаться ошибкой, если указанный ключ не существует. В постусловие такое же (ключ не существует или пул пуст), поэтому есть состояние ошибки отсутствует.

Интерфейсы

Интерфейс CacheItem

CacheItemInterface определяет элемент внутри системы кэширования.Каждый объект Item ДОЛЖЕН быть связан с конкретным ключом, который может быть установлен в соответствии с системы реализации и обычно передается Cache \ CacheItemPoolInterface объект.

Объект Cache \ CacheItemInterface инкапсулирует хранение и извлечение элементы кеша. Каждый Cache \ CacheItemInterface создается Cache \ CacheItemPoolInterface , который отвечает за все необходимые setup, а также связать объект с уникальным ключом. Cache \ CacheItemInterface Объекты ДОЛЖНЫ иметь возможность хранить и извлекать любой тип Значение PHP определено в разделе «Данные» этого документа.

Вызывающие библиотеки НЕ ДОЛЖНЫ создавать экземпляры самих объектов Item. Они могут только быть запрошенным из объекта Pool с помощью метода getItem () . Вызов библиотек НЕ СЛЕДУЕТ предполагать, что элемент, созданный одной реализационной библиотекой, является совместим с пулом из другой библиотеки реализации.

`CacheItemPoolInterface`

Основная цель Cache \ CacheItemPoolInterface - принять ключ от Вызов библиотеки и возврат связанного объекта Cache \ CacheItemInterface.Это также основная точка взаимодействия со всей коллекцией кешей. Вся настройка и инициализация пула оставлены на усмотрение разработчика. Библиотека.

`CacheException`

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

Любое исключение, созданное Реализующей библиотекой, ДОЛЖНО реализовывать этот интерфейс.

`InvalidArgumentException`

Начиная с версии 2.0 psr / cache, вышеупомянутые интерфейсы были обновлены для добавления подсказок типа аргумента. Начиная с версии 3.0 psr / cache, вышеупомянутые интерфейсы были обновлены для добавления подсказок типа возвращаемого значения.Ссылки на массив | \ Traversable были заменены на итеративный .

 Кэширование памяти - последняя версия руководства по администрированию Nextcloud последняя версия 
 Вы можете значительно улучшить производительность вашего сервера Nextcloud с помощью памяти
кэширование, при котором часто запрашиваемые объекты хранятся в памяти для более быстрого
поиск. Есть два типа кешей, которые можно использовать: кеш кода операции PHP, который
обычно называемый  opcache , и кэширование данных для вашего веб-сервера.Если ты не
установите и включите локальный кэш памяти, вы увидите предупреждение на вашем Nextcloud
страница администратора.  Кэш памяти не требуется, и вы можете игнорировать предупреждение.
Если вы предпочитаете. 
 Примечание
 Если вы включите только распределенный кеш в
ваш  config.php  ( memcache.distributed ), а не
локальный кеш ( memcache.local ), вы все равно увидите предупреждение о кешировании.
 В opcache PHP хранятся скомпилированные скрипты PHP, поэтому их не нужно перекомпилировать.
каждый раз их вызывают.PHP объединяет Zend OPcache в ядро, начиная с версии
5.5, поэтому вам не нужно устанавливать opcache вручную.
 Кэширование данных предоставляется пользователем (APCu), Memcached или Redis.
 Nextcloud поддерживает несколько бэкэндов кэширования памяти, поэтому вы можете выбрать тип
кэша памяти, который наилучшим образом соответствует вашим потребностям. Поддерживаемые серверные части кэширования:
 Требуется APCu, APCu 4.0.6 или более поздней версии.
 Локальный кеш для систем.
 Redis, модуль PHP 2.Требуется версия 2.6 и выше.
 Для локального и распределенного кэширования, а также транзакционной блокировки файлов.
 Memcached
 Для распределенного кэширования.
 Memcache необходимо явно настроить в Nextcloud путем установки
и включив желаемый кеш, а затем добавив соответствующую запись в  config.php  (См. Параметры конфигурации для обзора
все возможные параметры конфигурации).
 Вы можете использовать как локальный, так и распределенный кеш.Рекомендуемые кеши - APCu
и Redis. После установки и включения выбранного кэша памяти убедитесь, что он
активен, запустив версию и информацию PHP.
 Примечание
 Если вы запускаете несколько веб-серверов и включаете распределенный кеш в
ваш  config.php  ( memcache.distributed ) или поставщик блокировки файлов
( memcache.locking ) вам необходимо убедиться, что они ссылаются на
тот же сервер memcache, а не  localhost  или сокет unix.
 APCu 
 APCu - это кэш данных, и он доступен в большинстве
Дистрибутивы Linux. В системах Red Hat / CentOS / Fedora установить  php-pecl-apcu . В системах Debian / Ubuntu / Mint установите  php-apcu .
 После перезапуска веб-сервера добавьте эту строку в файл  config.php :
 'memcache.local' => '\ OC \ Memcache \ APCu',
 
 Обновите страницу администратора Nextcloud, и предупреждение кеша должно исчезнуть.
 Предупреждение
 APCu по умолчанию отключен в интерфейсе командной строки, что может вызвать проблемы с nextcloud.
cron вакансии.Убедитесь, что вы установили  apc.enable_cli  на  1  на вашем  php.ini  config или добавьте  --define apc.enable_cli = 1  к вызову задания cron.
 Redis 
 Redis - отличный современный кэш памяти для распределенного кэширования, а также
в качестве хранилища "ключ-значение" для транзакционной блокировки файлов, поскольку оно гарантирует
что кэшированные объекты доступны до тех пор, пока они необходимы.
 Модуль Redis PHP должен быть версии 2.2.6+.Если вы используете Linux
дистрибутив, в котором не упакованы поддерживаемые версии этого модуля, или
не упаковывает Redis вообще, см. дополнительную справку по установке Redis.
 В Debian / Ubuntu / Mint установите  redis-server  и  php-redis . Установщик
автоматически запустит  redis-server  и настроит его для запуска в
запускать.
 В CentOS и Fedora установите  redis  и  php-pecl-redis . Я не буду
запускается автоматически, поэтому для запуска необходимо использовать диспетчер служб.  redis  и запускать его при загрузке как демон.
 Вы можете убедиться, что демон Redis работает с  ps ax :
 пс топор | grep redis
22203? SSL 0:00 / usr / bin / redis-server 127.0.0.1:6379
 
 Перезагрузите веб-сервер, добавьте соответствующие записи в файл  config.php  и
обновите страницу администратора Nextcloud. В этом примере конфигурации  config.php  используется
Redis для распределенного серверного кеша:
 'memcache.distributed' => '\ OC \ Memcache \ Redis',
'redis' => [
     'хост' => 'redis-host.example.com ',
     'порт' => 6379,
],
 
 Для лучшей производительности используйте Redis для блокировки файлов, добавив это:
 'memcache.locking' => '\ OC \ Memcache \ Redis',
 
 Если вы хотите подключиться к Redis, настроенному на прослушивание сокета Unix (который
рекомендуется, если Redis работает в той же системе, что и Nextcloud) используйте этот пример  config.php  конфигурация:
 'memcache.local' => '\ OC \ Memcache \ APCu',
'memcache.distributed' => '\ OC \ Memcache \ Redis',
'redis' => [
     'host' => '/ run / redis / redis-server.носок',
     'порт' => 0,
     'dbindex' => 0,
     'пароль' => 'секрет',
     'timeout' => 1,5,
],
 
 Требуются только переменные host и port, остальные - необязательны.
 Обновите конфигурацию redis в файле  /etc/redis/redis.conf  соответственно: раскомментируйте параметры сокета Unix и убедитесь, что параметры «сокет» и «порт» соответствуют вашей конфигурации Nextcloud.
 Обязательно установите правильные разрешения для redis.sock, чтобы ваш веб-сервер мог
прочтите и напишите в него.Для этого обычно необходимо добавить пользователя веб-сервера
в группу Redis:
 usermod -a -G redis www-data
 
 Возможно, вам потребуется перезапустить apache, чтобы изменения вступили в силу:
 systemctl перезапустить apache2
 
 Redis легко настраивается; обратитесь к документации Redis, чтобы узнать больше.
  Использование обработчика сеанса Redis:  Если вы используете Redis для блокировки и / или кэширования,
вы также можете использовать Redis для управления сеансом. Redis можно использовать для централизованного
управление сеансами на нескольких серверах приложений Nextcloud, в отличие от стандартного  файла  обработчик.Если вы используете обработчик Redis,  ДОЛЖЕН  гарантировать, что сеанс
блокировка включена. На момент написания этой статьи обработчик сеанса Redis не включает , а НЕ .
блокировка сеанса по умолчанию, что может привести к повреждению сеанса в некоторых приложениях Nextcloud
которые интенсивно используют сеансовые записи, такие как Talk. Кроме того, даже при блокировке сеанса
включен, если приложению не удается получить блокировку, обработчик сеанса Redis не
в настоящее время возвращает ошибку. Добавление следующих настроек в ваш  php.ini  будет
предотвращение повреждения сеанса при использовании Redis в качестве обработчика сеанса:
 redis.session.locking_enabled = 1
redis.session.lock_retries = -1
redis.session.lock_wait_time = 10000
 
 Более подробную информацию о настройке обработчика сессий phpredis можно найти на
PhpRedis GitHub, страница
 Memcached 
 Memcached - надежный старомодный инструмент для совместного кэширования на распределенных серверах,
и хорошо работает с Nextcloud с одним исключением: он не подходит для использования
с блокировкой транзакционных файлов
потому что он не хранит блокировки, и данные могут исчезнуть из кеша в любой момент
(Redis - лучший кеш памяти для этого).
 Примечание
 Обязательно установите модуль  memcached  PHP, а не memcache, как
в следующих примерах. Nextcloud поддерживает только  memcached  PHP.
модуль.
 Установить Memcached очень просто. В Debian / Ubuntu / Mint установите  memcached  и  файл php-memcached . Программа установки автоматически запустит  memcached  и
настроить его на запуск при запуске.
 В Red Hat / CentOS / Fedora установить  memcached  и  файл php-pecl-memcached .Он не запустится автоматически, поэтому вы должны использовать
ваш диспетчер служб, чтобы запустить  memcached  и запустить его при загрузке как
демон.
 Вы можете проверить, что демон Memcached работает с  ps ax :
 пс топор | grep memcached
19563? Сл 0:02 / usr / bin / memcached -m 64 -p 11211 -u memcache -l
127.0.0.1
 
 Перезагрузите веб-сервер, добавьте соответствующие записи в свой  config.php  и обновите страницу администратора Nextcloud. В этом примере используется APCu
для локального кеша, Memcached как распределенный кэш памяти, и перечисляет все
серверы в общем кеш-пуле с номерами портов:
 'memcache.local '=>' \ OC \ Memcache \ APCu ',
'memcache.distributed' => '\ OC \ Memcache \ Memcached',
'memcached_servers' => [
     ['server0.example.com', 11211],
     ['server1.example.com', 11211],
     ['server2.example.com', 11211],
 ],
 
 Расположение каталога кэша 
 Каталог кеша по умолчанию -  data / $ user / cache , где  $ user  - это
текущий пользователь. Вы можете использовать директиву  'cache_path'  в  config.php  (См. Параметры конфигурации), чтобы выбрать другое местоположение.
 Рекомендации в зависимости от типа развертывания 
 Малый / частный домашний сервер 
 Используйте только APCu:
 'memcache.local' => '\ OC \ Memcache \ APCu',
 
 Организации с односерверными и кластерными настройками 
 Используйте Redis для всего, кроме локального кэша памяти:
 'memcache.local' => '\ OC \ Memcache \ APCu',
'memcache.distributed' => '\ OC \ Memcache \ Redis',
'memcache.locking' => '\ OC \ Memcache \ Redis',
'redis' => [
     'хост' => 'redis-host.example.com ',
     'порт' => 6379,
],
 
 Дополнительные примечания для Redis и APCu по кэшированию памяти 
 APCu выполняет локальное кэширование быстрее, чем Redis. Если у вас достаточно памяти, используйте APCu для кэширования памяти.
и Redis для блокировки файлов. Если у вас мало памяти, используйте Redis для обоих.
 Дополнительная справка по установке Redis 
 Если ваша версия Mint или Ubuntu не содержит требуемую версию  php-redis , затем попробуйте это руководство Redis на Tech and Me для полной установки Redis на Ubuntu 14.04 с помощью PECL.
Эти инструкции можно адаптировать для любого дистрибутива, в котором отсутствует
поддерживаемая версия, или в которой Redis вообще отсутствует, например SUSE Linux
Корпоративный сервер и Red Hat Enterprise Linux.
 Для PHP 7.0 и PHP 7.1 используйте модуль Redis PHP 3.1.x или новее.
 См. Https://pecl.php.net/package/redis
 В Debian / Mint / Ubuntu используйте  apt-cache  для просмотра доступных  php-redis  version, или версия вашего установленного пакета:
 политика apt-cache php-redis
 
 В CentOS и Fedora команда  yum  показывает доступную и установленную версию
информация:
 поиск yum php-pecl-redis
 
 Caching делает все быстрее.Верно? 
 Сбор данных о покрытии кода замедляет выполнение тестов. В предыдущей статье мы с Себастьяном Хойером объяснили, как уменьшить замедление при использовании Xdebug.
 С тех пор, как мы написали эту статью, Джо Уоткинс выпустил PCOV, новое расширение PHP для сбора информации о покрытии кода. PCOV значительно быстрее собирает информацию о покрытии линии, чем Xdebug 2. Но там, где Xdebug может собирать информацию о покрытии линии, покрытии ответвления и покрытии пути, PCOV может только собирать информацию о покрытии линии.PHPUnit 8 добавил поддержку PCOV в феврале 2019 года.
 Недавно Дуг Райт не только добавил поддержку покрытия ветвей и путей в php-code-cover, библиотеку, используемую PHPUnit для сбора, обработки и представления информации о покрытии кода. Он также выполнил некоторые просроченные очистки и рефакторинги, которые делают параметры интерфейса командной строки PHPUnit  --dump-xdebug-filter  и  --prepend , которые мы обсуждали в нашей статье, излишними. Сейчас они устарели и планируется удалить в PHPUnit 10 следующего года.
 Лучшая информация благодаря PHP-Parser 
 PHPUnit 9.3 был выпущен 7 августа 2020 года и использовал php-code-cover 9.0 для своей функциональности покрытия кода. Эти выпуски впервые предоставили пользователям PHPUnit покрытие ветвей и путей.
 В дополнение к новой функциональности, было много изменений под капотом php-code-покрытия. Объекты-значения были введены для замены загадочных структур массивов, которые было трудно понять из-за недостаточной безопасности типов.
 Однако наиболее актуальным для данной статьи изменением стал переход на использование превосходной библиотеки PHP-Parser Никиты Попова в качестве основы для статического анализа. Теперь мы используем абстрактное синтаксическое дерево, например, для анализа того, является ли строка кода исполняемой или нет. Результат этого анализа теперь более точен, чем был раньше, и код для этого анализа теперь намного легче понять и поддерживать.
 Шаблон проектирования Visitor применяется при анализе кода с помощью PHP-Parser:  объектов NodeVisitor  посещают каждый узел абстрактного синтаксического дерева исходного файла.Вот список посетителей узла, используемых в php-code-cover 9.0:
 Мы используем этих посетителей, чтобы выяснить, какие строки кода содержат исполняемые операторы, какие строки кода следует игнорировать (например, на основе аннотаций  @covers  или  @codeCoverageIgnore ), какие единицы кода (классы, черты, функции ) объявлены в исходном файле, сколько физических / комментариев / без комментариев / логических строк кода имеет исходный файл и какова цикломатическая сложность функций и методов в исходном файле.
 О нет. Это медленно! 
 Я ожидал, что использование PHP-Parser для статического анализа в покрытии php-кода замедлит анализ покрытия кода с помощью PHPUnit. Однако в ограниченных тестах, которые я проводил перед выпуском PHPUnit 9.3, я не заметил значительного замедления. Вот почему я был удивлен падением производительности, о котором было сообщено почти сразу после выпуска.
 Очевидное решение для дорогостоящей операции (статический анализ в нашем случае), когда результат изменяется только при изменении входных данных (исходных файлов в нашем случае) кэширования.И поэтому я сконцентрировал использование PHP-Parser для исходных файлов, которые покрываются хотя бы одним тестом, в новом классе  ParsingCoveredFileAnalyser . Затем я извлек из этого класса интерфейс  CoveredFileAnalyser :
 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12  интерфейс 
 CoveredFileAnalyser 
 { 
 общественный 
 функция 
 классы
 (
 нить 
 $ filename
 )
 : 
 множество
 ; общественный 
 функция 
 черты
 (
 нить 
 $ filename
 )
 : 
 множество
 ;
 общественный 
 функция 
 функции
 (
 нить 
 $ filename
 )
 : 
 множество
 ;
 общественный 
 функция 
 linesOfCodeFor
 (
 нить 
 $ filename
 )
 : 
 LinesOfCode
 ;
 общественный 
 функция 
 ignoredLinesFor
 (
 нить 
 $ filename
 )
 : 
 множество
 ; 
} 
 Наконец, я создал дополнительную реализацию, которая выполняет кэширование,  CachingCoveredFileAnalyser :
 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21 год
 22
 23
 24
 25
 26
 27
 28 год
 29
 30  окончательный 
 класс 
 Кэширование 
 расширяется 
 Кеш 
 орудия 
 CoveredFileAnalyser 
 { 
 частный 
 $ CovedFileAnalyser
 ; общественный 
 функция 
 __construct
 ( 
 нить 
 $ каталог
 , 
 CoveredFileAnalyser 
 $ CoatedFileAnalyser 
 ) 
 { 
 родитель
 ::
 __construct
 (
 $ каталог
 )
 ;
 $ это
 ->
 coverFileAnalyser 
 знак равно 
 $ CoatedFileAnalyser
 ; 
 }
 общественный 
 функция 
 классы
 (
 нить 
 $ filename
 )
 : 
 множество 
 { 
 если 
 (
 $ это
 ->
 кеш
 (
 $ filename
 , 
 __METHOD__
 )
 ) 
 { 
 возвращаться 
 $ это
 ->
 кешЧитать
 (
 $ filename
 , 
 __METHOD__
 )
 ; 
 }
 $ данные 
 знак равно 
 $ это
 ->
 coverFileAnalyser
 ->
 классы
 (
 $ filename
 )
 ;
 $ это
 ->
 cacheWrite
 (
 $ filename
 , 
 __METHOD__
 , 
 $ данные
 )
 ;
 возвращаться 
 $ данные
 ; 
 }
 
} 
  ParsingCoveredFileAnalyser  используется напрямую, когда кэш для результатов статического анализа отключен. CachingCoveredFileAnalyser  используется, когда включен кэш для результатов статического анализа. Этот класс делегирует  ParsingCoveredFileAnalyser , когда происходит промах в кэше, и в противном случае возвращает кэшированный результат.
 Это оказалось "достаточно хорошо", и была выпущена версия 9.1.0 для php-кода. Помните, что я написал в начале этой статьи? Кэширование ускоряет работу ... кроме случаев, когда это не так.
 Плохой кеш хуже ... 
 В середине сентября 2020 года я получил электронное письмо от Мартина Фёлькера, который работает ИТ-менеджером и разработчиком программного обеспечения в Crew United.К настоящему времени я знаю, что тот, кто работает в немецкоязычной киноиндустрии, не может пройти мимо этой сети. Мартин Фёлькер обратился ко мне с проблемой, но я лучше позволю ему сообщить об этом самому:
 Организация опытно-конструкторских работ и автоматизация тестирования 
 Разработка нашей платформы организована в виде спринтов. Улучшения и новые функции выпускаются примерно каждый месяц.
 Система API, основанная на PHP, служит серверной частью.Вторичные цели разработки включают улучшение качества кода, измеряемого многочисленными метриками, такими как отчеты CheckStyle, детектор сообщений PHP (PHPMD), статический анализ кода и отчеты о покрытии кода. Спринт включает в себя цель не ухудшить эти показатели, несмотря на растущий размер базы кода. В лучшем случае числа, сообщаемые Checkstyle и PHPMD, в конце будут ниже.
 Каждый коммит Git в ветке  develop  выполняет цепочку заданий в нашей системе Jenkins CI:
 PHPUnit выполняет все модульные и функциональные тесты (в течение примерно пяти минут) - в настоящее время около 8 300 тестов; если нет ошибки...
 код загружен на два тестовых сервера - один для ручного тестирования и принятия функций спринта, другой для автоматического тестирования и внешнего тестирования Behat; это занимает полминуты
 после этого другое задание генерирует описанные метрики программного обеспечения, а с помощью PHPUnit создается отчет о покрытии кода - это занимает много времени и в целом занимает около 21 минуты; если ошибки нет ...
 выполнены тесты Behat для внешнего интерфейса - на данный момент около 250 сценариев и около 4000 отдельных шагов; это занимает около 40 минут
 Поскольку все этапы тестирования - все, кроме развертывания на этапе 2 - выполняются в одной и той же тестовой системе, они должны выполняться исключительно и блокировать другие задания Jenkins на это время.
 Если время выполнения шага или задания значительно увеличивается, это отрицательно сказывается на других. Например, для того, чтобы новые реализованные функции стали доступны в тестовой системе, требуется больше времени.
 Между прочим, в системе Jenkins есть еще два или три задания, которые также должны выполняться исключительно - например, автоматические тесты с PHPUnit на главной ветви  .
 Следовательно, другая вторичная цель - ускорить тесты, выполняемые с помощью PHPUnit.И, следовательно, также более быстрое создание отчета о покрытии кода. Прежде чем изменения могут быть помещены в репозиторий, тесты должны выполняться без ошибок. Разработчики могут почувствовать изменения в среде выполнения прямо здесь.
 Как стали заметны проблемы во время выполнения 
 На сентябрь 2020 г. было запланировано обновление с PHPUnit 9.2 (с покрытием php-code 8.0) до PHPUnit 9.3 (с покрытием php-кода 9.1). Поскольку для этого требуются изменения в файлах конфигурации PHPUnit XML для покрытия кода, в спринте для этого было зарезервировано некоторое время.К счастью, новый формат стал намного понятнее, четыре или пять файлов в проекте были быстро изменены.
 Первый сюрприз случился после первого запуска системы Jenkins. В новых версиях необходимое время увеличилось примерно на 90%. Это может быть воспроизведено на локальном компьютере разработчика.
 Первые шаги анализа первопричин 
 Тесты на компьютере разработчика выполняются в среде Windows. Это не первый случай, когда причину можно найти здесь.Но и в локальной системе Linux была обнаружена такая же картина. Система Jenkins также работает в Linux. Везде очень похожее поведение. Так что об этом не могло быть и речи.
 «Я не могу быть первым и единственным, у кого есть эта проблема» - обычная мысль. Кроме того, в новом PHPUnit уже есть десятая подверсия - 9.3.10. Вероятно, это тоже не будет проблемой для прорезывания зубов.
 Итак, вы проверяете отчеты об ошибках на GitHub на предмет наличия PHPUnit и покрытия php-кода. И о чудо, билет 789 как раз описывает нашу проблему.Так что просто сделайте все, что там описано для решения ... и проблема решена!
 Звучит очень просто и логично: библиотека, используемая для статического анализа кода, была изменена, потому что старую было трудно поддерживать. Новый - PHP-Parser - построен чисто, но медленнее из-за своей концепции. Однако это приемлемо с учетом явно преобладающих преимуществ.
 Чтобы смягчить эффект - медленнее, чем раньше - есть новый кеш для результатов сложного статического анализа.Вам нужно только указать папку для кеша в файле конфигурации. При первом запуске кеш заполняется, и с этого момента он работает так быстро, что лишь незначительно отличается от предыдущей версии.
 Итак, кеш активируется и, как также описано, вызывается PHPUnit с новым параметром  --warm-extension-cache . Примерно через минуту это было сделано на машине разработки.
 Но тут пришел следующий сюрприз. Даже во время второго и третьего прогонов для генерации отчета о покрытии кода время выполнения было не ниже - оно было примерно в 3 раза выше с активированным кешем, чем без него.
 Исследование причин проблемы с кешем 
 Можете ли вы сделать что-то совершенно неправильное, если в файле конфигурации укажете путь только к файлам кеша? Возможно, параллельно выполнялись другие процессы? Также четвертая и пятая попытки дали - за исключением нескольких секунд отклонения - одинаковый результат. PHPUnit потребовалось почти один час для генерации данных для отчета. Может быть, теперь это проблема только Windows - может быть. Но на сервере Jenkins результат тот же.Тенденция времени выполнения на Рисунке 1 ясно показывает это.
  Рисунок 1: Время выполнения сборок Jenkins в Crew United 
 A. PHPUnit 9.2 с покрытием php-кода 8.0 
 B. PHPUnit 9.3 с покрытием php-кода 9.1 без кеша 
 C. PHPUnit 9.3 с покрытием php-кода 9.1 с кешем 
 D. PHPUnit 9.2 с php-кодом- покрытие 8.0 и Xdebug вместо PCOV
 Следующий сюрприз оказался в самой папке с кешем.В нем было почти 38 000 файлов. Это сериализованные данные PHP. После краткого анализа можно было увидеть, что пространство имен классов также включено. Первое предположение заключалось в том, что, возможно, для каждого класса или файла из каталога  поставщика  был создан один файл кэша. Это было бы мыслимой ошибкой. Отчеты о покрытии кода создаются только для пространств имен Crew United; классы в папке  vendor  не актуальны. Однако это предположение можно было быстро опровергнуть.В файлах в кеше не было чужих классов.
 Связаться с Себастьяном Бергманном 
 В этот момент мне было ясно, что я не могу пойти дальше и что причина должна быть найдена «где-то» в PHPUnit или php-code-cover. Проблема, которую раньше никто не замечал. Может быть, это просто размер проекта в несколько тысяч файлов. Здесь эффекты могут быть более очевидными, чем в более мелких. Но кеш всегда должен ускоряться.
 Я подумал, теперь я просто пишу ему по электронной почте.Я знаю его по нескольким крупным конференциям по PHP и по группе пользователей PHP в Мюнхене. Он как оратор, я как слушатель. С очень большой вероятностью он меня не знает, тем более по имени. Будет ли ответ, и если да, то когда?
 В электронном письме были описаны три основные проблемы:
 Время работы увеличилось примерно на 90% по сравнению с предыдущей версией
 Утроение времени выполнения с активированным кешем
 Удивительно большое количество файлов в кеше
 Кроме того, запускаются конкретные числа из PHPUnit - как показано выше.
 Два дня спустя я действительно получил ответ в моем почтовом ящике. По поводу моих вопросов следующий отзыв:
 Новый синтаксический анализатор PHP медленнее, да. Но пока об этом не известно.
 С кешем шустрее работает. Также это поведение неизвестно.
 На файл PHP в проекте шесть файлов попадают в папку кэша.
 Кроме того, предлагается провести видеоконференцию с демонстрацией экрана - до одного часа.Затем я должен показать, как проблемы влияют на меня.
 Я с радостью принял это неожиданное предложение. Мы договорились о встрече, и я заверил, что подготовлю материал в срок. Конкретно я должен был предложить:
 Вызов PHPUnit с кешем и без - разница в скорости была четко видна при рисовании точек
 Данные профилирования (сгенерированные с помощью Xdebug) с кешем и без него для первых 100 из 8300 тестов
 Видеоконференция 
 После краткого описания проекта мы просмотрели конфигурационный файл PHPUnit - никаких заметных особенностей.Снова исключение, что это проблема только Windows.
 Первое удивление произошло, когда мы посмотрели на данные профилирования из прогона с активированным кешем (см. Рисунок 2).
  Рисунок 2: Оценка данных профилирования в PhpStorm 
 С помощью PhpStorm вы можете открывать файлы данных, созданные с помощью профилировщика Xdebug, таблица - это их представление.В столбце «Вызываемые» вы можете увидеть имена вызываемых функций, в «Собственное время» вы можете увидеть процент времени выполнения функции. Яркие вызовы функций отмечены *). Почему "php: filemtime" с 7% вверху? Почему «CachingCoveredFileAnalyse-> cacheHas» с 6,2% пока на вершине?
 Подозрение быстро упало на проблему с самим кешем. Поскольку PHPUnit и покрытие php-кода интегрированы в проект через Composer, мы можем вносить изменения напрямую и проверять эффекты.Однако быстро стало очевидно, что решение здесь невозможно даже быстро получить с двумя или тремя измененными линиями.
 В то время Себастьян Бергманн не мог воспроизвести проблему на своем собственном компьютере. Мы закончили видеоконференцию следующим планом:
 Себастьян Бергманн проверяет заметно медленные методы, определяемые профилированием, и восстанавливает кэш.
 Когда изменения готовы, я вношу их в проект, запускаю PHPUnit и даю отзыв.
 Следующие часы - успех 
 Согласно плану, указанному выше, было проведено несколько прогонов по следующей схеме:
 Себастьян Бергманн: «Я изменился ...»
 Мартин Фёлькер: «К сожалению, я пока не заметил никаких улучшений».
 На следующий день - очень рано около 06:15 - пришла обратная связь:
 Я снова исключил несколько операций ввода-вывода
 Теперь я могу воспроизвести проблему
 Итак, еще раз загрузите последний код PHPUnit и php-code-cover в проект и... это было действительно сделано. Также мои сроки обработки с кешем были лучше.
 Мой ответ Себастьяну Бергманну: «Последние оптимизации работают, увеличивают пропускную способность для меня и решают проблему с кешем. Большое спасибо!»
 Здесь я хотел бы поблагодарить Мартина Фёлькера за прекрасную видеоконференцию, а также за хорошее сотрудничество в решении этой проблемы.
 Так что же вызвало это? 
 Причина значительного снижения производительности, о которой сообщил Мартин Фёлькер, была двоякой.Результат статического анализа, выполненного  ParsingCoveredFileAnalyser , был сохранен в пяти файлах кэша на каждый исходный файл с помощью  CachingCoveredFileAnalyser . Следовательно, для чтения кэшированного результата работы, выполненной  ParsingCoveredFileAnalyser , потребовалось пять операций ввода-вывода. Но подождите, становится еще хуже. Методы  classesIn () ,  traitsIn () ,  functionsIn ()  и  linesOfCodeFor ()  вызываются только один раз для каждого исходного файла.Однако метод  ignoredLinesFor ()  вызывается один раз для каждого покрытого исходного файла после каждого теста. Исходная реализация кеша считывает информацию для  ignoredLinesFor ()  снова и снова из кеша. Оглядываясь назад, становится очевидно, что это была очень плохая идея.
 Реализация  CachingCoveredFileAnalyser  теперь выглядит следующим образом:  CachingCoveredFileAnalyser.php . Информация больше не хранится в пяти отдельных файлах кэша, и одна и та же информация больше не считывается с диска несколько раз.
 Работая над этим, я узнал, что  file_exists ()  до 100 раз медленнее, чем  is_dir ()  или  is_file () . Хотя я не смог измерить разницу в производительности, когда в коде php-code-покрытия использовалось  file_exists () , я все же заменил вызовы  file_exists ()  на вызовы  is_file () .
 Не менее 
 Первая реализация кеширования результатов статического анализа кода была слишком наивной.Ни чистый дизайн, ни интерфейс  CoveredFileAnalyser  с реализациями  ParsingCoveredFileAnalyser  и  CachingCoveredFileAnalyser , ни автоматизированные тесты не могли помочь выявить эту наивность. Наконец, автоматические тесты могли только убедиться, что кеш работает. Конечно, тесты не проверяли цель по качеству производительности. Только усиленное тестирование в смысле сравнительного анализа могло бы раскрыть проблему.
 Мартин Фёлькер писал ранее:
 Я подумал, теперь я просто пишу ему по электронной почте.[...] Будет ли ответ, и если да, то когда?
 Конечно, вы можете связаться со мной по электронной почте. И, конечно же, я стараюсь отвечать на каждое письмо, которое доходит до меня.
 О проблемах с PHPUnit (или другими проектами с открытым исходным кодом) в первую очередь следует сообщать в соответствующей системе отслеживания проблем. Однако иногда бывает непросто или вообще невозможно сообщить о проблеме публично. Например, если проблема воспроизводима только в вашей собственной среде или только с вашим собственным кодом, который вы не можете или не хотите публиковать публично.В таких случаях я всегда предлагаю то, что предлагал Мартину Фёлькеру и то, что он подробно описал выше.
 Кстати: по проблемам, которые напрямую не связаны с моими проектами с открытым исходным кодом, я тоже могу помочь.
 Ускорьте PHP с помощью APC - Альтернативный кеш PHP 
  APC  или  Альтернативный кеш PHP , это бесплатный плагин для кэширования кода операции (кода операции) с открытым исходным кодом для PHP. Благодаря кэшированию APC выполнение сценариев PHP может выполняться более эффективно, за счет сокращения количества динамических выполнений PHP.
 Если вы уже знаете об APC, вы можете перейти к нашему руководству по установке APC.
 У нас также есть руководство, в котором рассказывается, как просмотреть и очистить кэш APC.
 Из этой статьи вы узнаете, как  ускорить PHP с помощью APC .
 Зачем вам устанавливать APC? 
 PHP - это динамический язык сценариев, поэтому при каждом запросе страницы сервер должен сначала проанализировать код в вашем сценарии PHP, чтобы сгенерировать результирующий HTML-код, видимый веб-браузером посетителя.
 PHP идеально подходит для веб-страниц, содержание которых постоянно обновляется, поскольку каждый посетитель получает новую копию страницы. Так, например, если у вас есть PHP-скрипт, извлекающий данные из базы данных, как только в базе данных появятся новые данные, они автоматически появятся в сгенерированном HTML-коде для следующего посетителя, запрашивающего эту страницу.
 В большинстве случаев необходимость повторного запуска сценариев PHP для данных, которые, возможно, изначально не были изменены, может обременить сервер.Внедряя APC, вы сокращаете количество повторений выполнения скриптов PHP, пропуская этапы синтаксического анализа и компиляции. APC сохраняет код операции, и он просто выполняется каждый раз при повторном вызове скрипта.
 В чем разница между APC и другими типами кэширования? 
 APC для PHP - одно из наиболее широко используемых сегодня решений для кэширования кода операции PHP. Вы можете использовать APC на VPS Â или выделенном сервере, на котором работает PHP как DSO или FastCGI. Возможно, вы захотите прочитать о выборе лучшего обработчика PHP для ваших конкретных потребностей, а также более подробное объяснение того, что такое DSO и FastCGI.
 Другой распространенный модуль кэширования - это Memcached, и основное различие между ним и APC заключается в том, что Memcached является распределенной и более надежной универсальной платформой кэширования, в то время как APC специфичен для PHP. APC отлично подходит, когда вам нужно локальное кэширование объектов для ваших PHP-скриптов, которые относительно малы и часто используются.
 Как установить APC 
 APC - это модуль PECL, который можно загрузить в PHP, но, поскольку он работает на уровне сервера, его нельзя запускать на наших серверах общего хостинга.
No related posts.

PHP: Введение — Manual

Кэширование PHP | Losst

Кэширование PHP

Кэширования байткода в PHP

Хранение сессий в memcached

Кэширование страниц fastcgi

Выводы

Оцените статью:

Кэширование: Кэширование динамического содержимого | Полное руководство по Yii 1.1

Настройка кэширования: серверное, браузерное, кэширование PHP | Примеры http-ответов сервера

HTTP-кэширование страниц и изображений в браузере

Принцип действия кэширования

Примеры заголовков

Настройка кэширования в браузере со стороны web-сервера

Кэширование страниц сайта на сервере

Ускорение WordPress с помощью кэширования

Кэширование PHP-скриптов

Кэширование запросов к базе данных

Решено: Как отключить eAccelerator, OPcache или Xcache в ISPmanager, Cpanel, Plesk?

eAccelerator

OPcache и Xcache

Кэширование PHP | Losst | DevsDay.ru

Кэширование PHP

Кэширования байткода в PHP

Хранение сессий в memcached

Кэширование страниц fastcgi

Выводы

Оцените статью:

Запрет кэширования посредством PHP. Справочник по PHP

Читайте также

Спецификация кэширования

Практическое запрещение кэширования

Разрешение кэширования

Загрузка и скачивание файлов посредством FTP

Настройка сервера, предназначенного только для кэширования

13.4.1. Настройка кэширования на DNS-сервере

Отмена кэширования пароля (Internet Explorer 4 и выше)

Загрузка и выгрузка файлов посредством FTP

Реализация паттерна «Стратегия» посредством указателей на функции

Реализация паттерна «Стратегия» посредством класса tr::function

Правило 38: Моделируйте отношение «содержит» или «реализуется посредством» с помощью композиции

Разрешение конфликтов посредством линейного зондирования

Разрешение конфликтов посредством связывания

Разрешение конфликтов посредством группирования

Понимание кеширования PHP. Все дело в кеширующем младенце! —

Что такое PHP?

Что такое кеширование?

Поваренная книга программиста

Кэширование PHP и WordPress

Настройка кэша

Изоморфное программирование

Итог

— Выбор метода кэширования PHP: кэширование вывода в файлы или кеширование кода операции

Более быстрый веб-сайт с кешем PHP и кешированием объектов

Зачем вашему сайту нужен кеш PHP?

Какой PHP-кеш можно использовать для ускорения работы своего сайта?

Кэширование всей страницы

PageCache

PageCache Пример PHP

Кэш страниц PHP и популярные фреймворки

Кэширование объектов

Что такое Memcached?

PHP Пример Memcached

Кэш объектов Redis

Пример PHP Redis

Кэширование фрагментов

Пример кода PhpFastCache

PHP-кеш и WordPress

WP Super Cache

WP Rocket

Simple Cache

Заключение

PSR-6: Интерфейс кэширования — PHP-FIG

Цель

Определения

Данные

Ключевые концепции

Бассейн

Товаров

`CacheItemPoolInterface`

`CacheException`

`InvalidArgumentException`

`Связаться с Себастьяном Бергманном`

`Видеоконференция`

`Следующие часы - успех`

`Так что же вызвало это?`

`Не менее`

`Ускорьте PHP с помощью APC - Альтернативный кеш PHP`

`Зачем вам устанавливать APC?`

`В чем разница между APC и другими типами кэширования?`

`Как установить APC`

`Добавить комментарий Отменить ответ`