Самое интересное в php 8

Как это работает?

Когда приложения хочет получить некоторые данные из базы, например сущность Post по его id, оно формирует уникальный ключ кеширования для этого случая ( вполне подходяще) и пытается найти значение по этому ключу в быстром key-value хранилище(memcache, redis, или другое). Если значение там — то приложение использует его. Если нет, забирает его из базы данных и сохраняет в кеш по этому ключу для будущих использований.

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

После истечения этого времени memcache или redis «забудут» про него и приложение возьмет свежее значение из базы.

Пример:

Здесь я кладу сущность Post в кеш на 15 минут (начиная с версии 5.8 laravel использует секунды в этом параметре, раньше там были минуты). Фасад также имеет удобный метод для этого случая. Этот код делает ровно тоже самое, что и предыдущий:

Изменение скорости работы сайта после установки акселератора PHP

Блог на WordPress работал сервере с PHP 5.3 без каких-либо акселераторов. Страница генерировалась за 0,37 сек., потребление памяти составляло 37 МБ.
После установки акселератора Zend OPcache скорость генерации страницы снизилась до 0,22 сек, потребление памяти при этом составило 11 МБ.
Комментарии излишни. Использование PHP акселератора положительно сказывается на скорости работы сайта и снижает потребление памяти.

Благодарности

1. Oфициальный форум VestaCP
2. Единая энциклопедия хостинга http://firstwiki.ru
3. http://itbtc.org/ustanovka-zend-opcache-na-debian-ili-centos/

realpath_cache: настоящий виновник

Пожалуй, при использовании функции или автозагрузки PHP нужно вспомнить о realpath_cache. Кеш настоящего пути (real path cache) позволяет кешировать разрешения путей для файлов и папок, чтобы реже тратить время на поиск по диску и улучшить производительность. Это очень полезно при работе со многими сторонними библиотеками или фреймворками вроде Symfony, Zend и Laravel, поскольку они используют огромное количество файлов.

Механизм кеширования появился в PHP 5.1.0. Сегодня эта возможность в официальных документах не упоминается, если не считать функций , , и -параметров и . Из внешних источников я смог найти только старый пост, написанный Джульеном Поли в 2014-м. Поли, широко известный разработчик PHP, объясняет, как работает механизм разрешения путей.

Когда мы обращаемся к файлу, PHP пытается разрешить его путь с помощью , системного вызова Unix: он возвращает атрибуты файла (разрешения, расширение и прочие метаданные) применительно к индексному дескриптору (inode). В мире Unix индексный дескриптор — это структура данных, используемая для описания объекта файловой системы, например файла или директории. PHP кладёт результат системного вызова в структуру данных под названием , за исключением таких вещей, как разрешения и владельцы. Так что если попытаться второй раз обратиться к тому же файлу, то при поиске в bucket в памяти (bucket lookup) нас избавят ещё от одного медленного системного вызова. Если хотите узнать больше, изучите исходный код PHP.

Функция появилась в PHP 5.3.2. Она позволяет получать массив, состоящий из записей кеша настоящих путей. В каждом элементе массива ключом является разрешённый путь (resolved path), а значением — другой массив с данными вроде , , , .

Дальше идут выходные данные ; в нашей тестовой Docker-среде:

Здесь:

• — число с плавающей запятой, оно является хешем пути.
• — булево значение, равно true, если разрешённый путь является директорией; в противном случае равно false.
• — разрешённый путь, строковое.
• — целое число, обозначает время, кеш пути будет инвалидирован. Это значение строго связано с параметром .

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

В посте Джульена Паули также говорится:

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

В нашей реальной production-среде пришлось учитывать, что у нас 15 фронтенд-серверов, на которых хостится много веб-приложений. На каждом сервере по одном пулу PHP-FPM, каждый из которых состоит из 35 воркеров и одного мастер-процесса. Это объясняет, почему «странное поведение» стало заметнее в новой среде. Можно скорректировать влияние кеша настоящего пути на наше веб-приложение, воспользовавшись параметрами и : первый определяет размер bucket, которым будет пользоваться PHP. Это целое число, и увеличить его полезно для веб-приложений, работающих с огромным количеством файлов. Второй параметр , как уже говорилось, представляет собой длительность кеширования информации о настоящем пути (в секундах).

Теперь всё понятно, можно снова включить OPCache и отключить кеш настоящего пути, настроив его размер и время жизни:

Снова запустим тест:

Исполнение с конфигурацией production-no-realpath-cache.

Хочу отметить, что нашу последнюю конфигурацию настоятельно не рекомендуется использовать в production-среде, потому что PHP вынужден разрешать каждый встреченный путь, что плохо влияет на производительность.

Инвалидация кеша

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

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

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

Создаем слушатель этих событий:

Этот код будет удалять закешированные значения после каждого обновления или удаления сущностей Post. Инвалидация списков сущностей, таких как top-5 статей или последних новостей, будет чуток посложнее. Я видел три стратегии:

Стратегия «Не инвалидируем»

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

Но некоторым проектам действительно важно иметь свежие данные в этих списках

Стратегия «Найти и обезвредить»

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

Выглядит уродливо, зато работает.

Стратегия «хранить id»

Если порядок элементов в списке неважен, то в кеше можно хранить только id записей. После получения id, можно сформировать список ключей вида и получить все значения используя метод , который достает много значений из кеша за один запрос (это еще называется multi get).

Установка APC

Для начала надо установить необходимые пакеты:

 # apt-get install apache2-threaded-dev php5-dev php5-pear make gcc g++ 

Затем установить APC при помощи pecl:

 # pecl install apc 

Отредактировать конфигурационный файл:

 #vi /etc/php5/apache2/php.ini 

Добавить в него следующую строку:

extension = apc.so
apc.shm_size = 64 Количество выделяемой оперативной памяти в МБ.
apc.enabled=1 APC включен. Довольно очевидная настройка, но очень важная. 
Отключение APC может привести к уменьшению производительности на рабочем сервере.

apc.shm_segments=1
apc.shm_size=32

Эти настройки показывают сколько памяти выделять под APC. APC.shm_segments=1 — показывает что выделяется один сегмент памяти, а apc.shm_size=32 показывает, что размер этого сегмента 32 мегабайта. Вы можете поменять размер сегмента, скажем на 64 мегабайта и перезапустить Apache. Потом если количество MISS не будет сведено к 1% сделать размер 128 МБ и так далее. Это основной параметр для работы с APC.

apc.cache_by_default=1

apc.filters= Работа APC для всех php скриптов. При этом мы можем закомментировать строчку с apc.filters.

apc.stat=1

Этот параметр напрямую влияет на производительность. При включенной настройке кэш в APC остается там пока не будет удален. В случае когда настройка отключена, то APC будет сравнивать время выполнения скрипта и время последнего изменения файла и добавлять в кэш новую версию. Эта настройка необходима для рабочего сервера, однако для разработки эту настройку лучше всего отключить. И еще при включенной настройке apc.stat необходимо очистить кэш APC при обновление модулей и ядра Drupal.

apc.ttl=0

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

 apc.num_files_hint=2048

Эта настройка может быть очень нужна, когда на сервере несколько сайтов, несколько Drupal. Потому что один Drupal может забивать в кэш более 500 файлов. Чтобы кэш одного сайта не затирал в кэше файлы другого, лучше включить эту настройку побольше (по умолчанию 1024).
Для вступления настроек в силу необходимо перезапустить веб-сервер.

 #/etc/init.d/apache2 restart 

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

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

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

Сначала нам нужно настроить memcached, откройте файл /etc/sysconfig/memcached и найдите строку CACHESIZE, здесь нужно указать объем оперативной памяти, которая выделяется под кэш:

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

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

Настройка кэширования

В случае заметного роста посещаемости грамотная настройка кэширования поможет значительно снизить нагрузку на VDS. Рассмотрим решения для Apache и Nginx.

Директивы, управляющие кэшем в Apache, можно прописывать как в файл виртуального хоста, так и в .htaccess корневого каталога вашего проекта. Наиболее простой способ — использование FilesMatch:

<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf|doc|docx)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>

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

Параметр max-age позволяет указать время хранения в секундах (в данном примере он равен 30 дням).
Больше возможностей предоставляет модуль Expires. Для его активации необходимо сделать следующее:

sudo a2enmod expires
sudo service apache2 restart

В числе преимуществ — возможность точно задать время хранения (запись вида “1 месяц, 3 дня, 2 часа”) и выбрать способ кэширования файла (с момента первого чтения, или модификации). Приведем наглядный пример:

<IfModule mod_expires.c>

Включаем модуль:

ExpiresActive On

Задаем кэширование по умолчанию для всех файлов:

ExpiresDefault "access plus 1 month"

GIF будут хранится в течение 1,5 месяцев, 3 часов и 10 минут с момента доступа:

ExpiresByType image/gif "access plus 1 month 15 days 3 hours 10 minutes"

Картинки JPEG будут сохраняться 2 месяца после последнего изменения:

ExpiresByType image/jpeg "modification plus 2 months"
</IfModule>

Обратите внимание: необходимо указывать полные MIME-types файлов, в формате “тип данных/расширение” (image/png, text/css и т.д.). В Nginx имеется своя специфика

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

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

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

location ~* .(jpg|jpeg|gif|png|ico|css|swf|flv|doc|docx)$ {

Указываем путь к корневой папке сайта:

root /var/www/site.ru;
}

Собственно настройками кэширования можно управлять, создав в директории /etc/nginx/conf.d/ файл cache.conf со следующим содержанием.

Указываем директорию кэша:

proxy_cache_path /var/cache/nginx

Задаем уровень вложенности папок (1:2:3:4 и т.д.):

levels=1:2

Определяем базовый размер кэша (Мб):

keys_zone=static_cache:100m

Указываем время, после которого кэш удаляется, если не было повторных запросов к файлам (в минутах):

inactive=120m

Задаем максимальный размер кэшируемых данных (Мб):

max_size=500M;

Указываем количество обращений, после которых файл попадает в кэш:

proxy_cache_min_uses 1;

После этого убедитесь, что в главном конфигурационном файле nginx.conf имеется следующая строчка:

include /etc/nginx/conf.d/*.conf

В случае отсутствия таковой пропишите директиву самостоятельно. Чтобы активировать настройки, перезапустите сервер:

sudo service nginx restart

What is OPcache or PHP Opcode Caching?

OPcache is a type of OPcode caching. This kind of caching compiles human-readable PHP code to code your server understands which is called opcode. This occurs when the PHP file loads on a web page for the first time. Then, it’s saved to the server’s memory for faster loading at each subsequent page visit.

Bytecode cache engines such as OPcache, APC, and Xcache all complete this process the first time the PHP file is executed without having to do it a second, or third time.

How PHP Opcode Caching Works

When a PHP script executes, your server’s cache memory is checked to see if the script has already been cached. If it hasn’t, it’s parsed, which means the code is analyzed.

Then, the script is compiled into opcode making the file readable by the server. Once that’s done, the opcode is saved to the server’s memory.

In other words, it’s stored in your server’s cache. The next time a visitor loads the page with the PHP script, the cached code is executed and loaded much faster.

On the other hand, if the script is loaded on the page and the cache is checked for opcode and finds it, then it’s loaded lickety-split.

When PHP scripts aren’t in the cache, they’re cached for subsequent page loads.

The Differences Between OPcache and APC Caches

OPcache, APC as well as Xcache are all opcode caching systems. OPcache used to be owned by Zend and Alternative PHP Cache (APC) was a free, open source extension for PHP. Xcache was also an alternative option.

APC was widely used, but it didn’t have the backing that OPcache had so it could be well maintained and stable with each new PHP release.

Fortunately, Zend made OPcache open source and available as an extension since PHP version 5.5. In earlier versions, you have the choice to use APC or OPcache, but if you would like to use the latter, you need to manually install it.

Xcache, on the other hand, is a good alternative to OPcache as a PHP accelerator.

Will OPcache Speed up My WordPress Site?

All three options are suitable for WordPress, but the recommended option for PHP versions 5.5 and above is OPcache. On average, it speeds up WordPress three fold, at the very least for medium to large sites.

If you have a smaller site without many additional PHP scripts or plugins installed, you likely won’t notice much of a difference.

However, you can still install OPcache on even small WordPress sites with no negative effects other than a slight increase in memory usage. But, it won’t be enough to cause any issues. This is similar for medium, large, or enterprise sites.

Flexible Configuration with Environment

We have OPcache enabled, but if we want to make this configuration flexible we can use environment variables to configure INI settings:

Now that we have an environment-powered INI file, let’s provide some defaults for our project in the Dockerfile:

Note that by default we’ll disable timestamps, so we need to override this environment value in development. In this post, we’re not going to cover using Docker Compose to set environment, but this is the rough command you can run to make sure timestamps are validated in development:

With the Apache container running in the background, you can validate that the OPcache timestamp setting is by verifying in the container:

As you can see, our configuration is now powered dynamically by environment variables! In Docker, your code will be cached with OPCache by default and will not update due to timestamps validation being disabled. Please note that if you’re using Nginx + PHP-FPM, you’ll need to either ensure that is in your FPM pool (probably ):

You can also manually add environment variables to the pool if you don’t want to keep the entire environment available to PHP.

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

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

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

Дальше рассмотрим более подробно, как настроить каждый вид кэширования для вашего сервера. Начнем с кэширования opcode php.

Установка eAccelerator:

 #apt-get install php5-dev 

Загрузите архив с исходными кодами eAccelerator:

 #wget http://bart.eaccelerator.net/source/0.9.5/eaccelerator-0.9.5.tar.bz2 

Распаковка архива:

 #tar jxvf eaccelerator-0.9.5.tar.bz2
#cd eaccelerator-0.9.5 

Далее необходимо запустить phpize для создания config-файлов, необходимых для сборки:

#phpize
#./configure –enable-eaccelerator=shared –with-php-config=/usr/bin/php-config
#make
#make install
cp modules/eaccelerator.so path-to-php/lib/php/extensions/no-debug-non-zts-xxxxxxxx/

Акселератор установлен.

Теперь необходимо отредактировать файл path-to-php.ini/php.ini для пользователей php и добавить в него следующие параметры для подключения расширения:

 #vi path-to-php/php.ini
extension=”eaccelerator.so”
eaccelerator.shm_size=”16″
eaccelerator.cache_dir=”/tmp/eaccelerator”
eaccelerator.enable=”1″
eaccelerator.optimizer=”1″
eaccelerator.check_mtime=”1″
eaccelerator.debug=”0″
eaccelerator.filter=””
eaccelerator.shm_max=”0″
eaccelerator.shm_ttl=”0″
eaccelerator.shm_prune_period=”0″
eaccelerator.shm_only=”0″
eaccelerator.compress=”1″
eaccelerator.compress_level=”9″

Максимальный размер кэша в мегабайтах:

 eaccelerator.shm_size="512" 

Корневой каталог для хранения кэша:

 eaccelerator.cache_dir="/var/cache/eaccelerator" 

Включение акселератора:

 eaccelerator.enable="1" 

Подключить или отключить встроенный оптимайзер, которые увеличивает скорость выполнения кода:

eaccelerator.optimizer="1" 

Включает проверку модификации PHP файлов:

 eaccelerator.check_mtime="1" 

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

 eaccelerator.debug="0" 

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

 eaccelerator.filter="" 

Максимально допустимое значение которое может быть отправлено в разделяемую память. По-умолчанию, «ноль» — без ограничений. Размер указывается в байтах, но можно указать приставки, например: 10240, 10K, 1M:

 eaccelerator.shm_max="0" 

Когда акселератору потребуется отправить в разделяемую память какой-то объект и при этом в памяти для этого не окажется места, он попытается удалить файлы, которые не были запрошены в течении последних «shm_ttl» секунд. По-умолчанию, это значение равно «0» — не удалять ничего:

eaccelerator.shm_ttl="0" 

Когда акселератору потребуется отправить в разделяемую память какой-то объект и при этом в памяти для этого не окажется места, он попытается удалить старые скрипты, если предыдущие такие попытки были не больше, чем «shm_prune_period» секунд назад.По-умолчанию, это значение равно «0» — не удалять ничего:

 eaccelerator.shm_prune_period="0" 

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

 eaccelerator.shm_only="0" 

Включить или отключить сжатие закэшированного контента. По-умолчанию, «1» — сжимать:

 eaccelerator.compress="0" 

Уровень сжатия. По-умолчанию, «9» — максимум:

 eaccelerator.compress_level="3" 

Создание cache-директории. Последний важный шаг в настройке акселератора — это создание директории для кэша, имя которой мы задавали в конфигурационном файле. Значение по умолчанию — /tmp/eaccelerator, потому что права на запись в папку /tmp обычно есть у всех пользователей

Не очень хорошим решением будет оставлять права на запись для всех пользователей. Более безопасным будет сменить владельца директории eaccelerator на пользователя, от имени которого запущен PHP (в большинстве случаев это web-сервер. Например apache или lighttpd) и установить на нее права 0644

#mkdir /tmp/eaccelerator
#chown nobody:nobody /tmp/eaccelerator (либо указать пользователя PHP вместо nobody)
#chmod 0644 /tmp/eaccelerator 

Для вступления настроек в силу необходимо перезагрузить web-сервер.

 #/etc/init.d/apache2 restart 

На этом настройка eAccelerator закончена
Если при доступе к созданному файлу с кодом:

 <?php
phpinfo();
?> 

видно информацию о eAccelerator, то все установлено корректно.

Мониторинг VDS

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

• точное число уникальных пользователей, зашедших на сайт;
• количество просмотров;
• источники трафика (поисковые фразы, социальные сети, контекстная реклама и другие);
• время, проведенное пользователем на сайте.

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

Для мониторинга же самого сервера наиболее оптимальным решением можно назвать утилиту atop — небольшую программу, позволяющую отслеживать в реальном времени исполняемые процессы и сетевую активность, а также вести лог событий. Устанавливается она командой:

sudo apt-get install atop

Для ее запуска достаточно ввести:

sudo atop 1

Вывод atop разделен на две половины. В верхней секции можно увидеть основную информацию по системе (загруженность памяти, процессора, диска), ниже приводится сводка по каждому процессу. Утилита поддерживает горячие клавиши, что существенно упрощает ее использование:

• c  — распределение процессов по степени нагрузки на ЦП;
• m — ранжирование по интенсивности расходования памяти;
• d  — сортировка по нагрузке на диск;
• v  — расширенная информация по запущенным процессам (дата и время начала, имя пользователя);
• u  — ранжирование по пользователям, больше всего нагружающим сервер;
• i, затем указать время в секундах и нажать Enter — позволяет изменить время обновления таблиц (по умолчанию 10 секунд);
• g — сброс настроек к настройкам по умолчанию.

Программа ведет запись собранных данных. Ознакомиться с выводом можно, введя команду:

sudo atop -r

Здесь применимы флаги C, M и D, функция которых аналогична соответствующим горячим клавишам. Например, введя:

sudo atop -r -M

мы отсортируем процессы по степени использования RAM.

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

Avoid Unnecessary Filesystem Calls By Disabling Timestamp Validation

With the default settings, whenever a PHP file is executed (for example through
or ) Opcache checks the last time it was modified on disk.
Then it compares this time with the last time it cached the compilation of that
script. When the file was modified after being cached, the compile cache for
the script will be regenerated.

This validation is not necessary in production, when you know the files never
change. To disable timestamp validation add the following line to your php.ini:

With this configuration you have to make sure that during a deployment, all the
caches get invalidated. There are several ways to ensure this happens:

• Restart PHP FPM or Apache — The sledgehammer method of invalidating files in
  Opcache has the downside that it might lead to aborted requests and a very
  small amount of time where requests get lost.

• Calling , which is tricky because it has to be called in a
  script executed by Apache or PHP-FPM to affect the webservers Opcache.
  You can add a special endpoint to your application and secure it using
  a secret hash.

• Changing the document root and reloading the Nginx webserver configuration.
  Nginx completes all the currently running requests and starts new workers in
  parallel that serve requests with the new configuration.

• For Apache, Rasmus has a blog
  post detailing
  their approach at Etsy.

Careful with the last two approaches, with them available Opcache memory is
«full» very fast. See the previous section for more information on how memory
configuration works.

For both cases you might need a maintenance script that calls
on all scripts in old deployments or
directly. Otherwise old deployments crowd out the cache for
new ones and you might end up with a full cache and an unaccelerated
application.

Убираем предупреждение о кешировании.

Поэтому прикручиваем систему кэширования, состоящую из локальной системы кэширования на основе APCu и системы распределённого кеширования Redis.

Ставим APCu

В файле php.ini включаем apcu

вставив в начало

Сохраняем файл и перезапускаем php-fpm.

Редактируем файл config/config.php в директории установки Nextсloud

и вставляем следующую строку перед закрывающем скобкой «);»

Ставим Redis.

Проверяем, что он запустился

В тот же файл config/config.php

вставьте следующее опять перед закрывающей скобкой «);»

Сохраняем файл. Перезапускаем php-fpm, если вы это ещё не сделали и наслаждаемся ускоренной работе Nextcloud.

FFI — Foreign Function Interface

• Это 1000 новых способов выстрелить себе в ногу.
• Требует знания С и иногда ручного управления памятью.
• Не поддерживает С-препроцессор (#include, #define, …) и С++.
• Производительность без JIT достаточно низкая.

только в командной строке

FFI + preloading

Работа со структурами данных С

• Нейронные сети на PHP.
• Компилятор на PHP.

К сожалению, скорость работы FFI пока оставляет желать лучшего.

	Native Arrays	FFI Arrays
PyPy	0,010	0,081
Python	0,212	0,343
LuaJIt -joff	0,037	0,412
LuaJit -jon	0,003	0,002
PHP	0,040	0,093
PHP + JIT	0,016	0,087

Автор выражает благодарность: Zeev Surasky (Zend), Andi Gutmans (ex-Zend, Amazon), Xinchen Hui (ex-Weibo, ex-Zend, Lianjia), Nikita Popov (JetBrains), Anatol Belsky (Microsoft), Anthony Ferrara (ex-Google, Lingo Live), Joe Watkins, Mohammad Reza Haghighat (Intel) и команду Intel, Andy Wingo (JS hacker, Igalia), Mike Pall (автор LuaJIT).этого

The Best PHP Accelerators

PHP was launched in 1995, making it one of the oldest surviving server-side languages today. Throughout its lifetime there have been a lot of accelerators (opcode caching) implemented for it, but for server setups that run on Linux, there’s primarily only one solution that’s well-maintained and useful: PHP OPcache.

For PHP apps running on Windows and Windows Server, there’s an alternative PHP accelerator called Windows Cache Extension for PHP. Plus, there are many extensions to add features to PHP’s built-in opcode caching. I’ll cover all of them in this article.

PHP OPcache (Zend OPcache)

PHP OPcache extension makes PHP code to execute faster through opcode caching and other optimization techniques. It’s bundled along with PHP 5.5 and later versions. 

PHP OPcache is also called Zend OPcache since it’s an implementation of Zend’s opcode caching extension. Zend kept this extension proprietary until PHP 5.5 was released. Hence, for many users Alternative PHP Cache (APC) was the go-to solution for opcode caching in PHP.  

After Zend open sourced the code for their opcode caching and released it as an extension called Zend OPcache, PHP 5.5 made it part of its core and has been using it as the default opcode caching solution ever since. 

PHP OPcache works by storing the opcode cache in shared memory

PHP OPcache improves performance by storing the precompiled bytecode in the server’s shared memory when any PHP script is executed for the first time. This eliminates reading and compiling PHP code for future access. PHP OPcache also applies additional bytecode optimization patterns to make PHP code execution faster.

APC User Cache (APCu)

Alternative PHP Cache (APC) is a free and an open source PHP accelerator. Like Zend OPcache, it’s mainly designed to cache the PHP opcode output in the server’s shared memory. Since it has always been FOSS, it was the most popular opcode caching solution for PHP until a few years ago. 

After PHP OPcache became a part of PHP 5.5, APC’s development slowed down considerably and is considered dead now. However, some APC features are still not available in PHP OPcache. One of them is the userland shared memory cache functionality. It’s also referred to as “in memory data caching.”

To address this issue, the APC developers stripped it of all its opcode caching features and released it as a separate extension called APCu. It adds support for userland caching of PHP variables.  

You can also install the APCu Backwards Compatibility Module to use APCu as a drop in replacement for APC in modern versions of PHP.

You’ll learn later how to enable and configure PHP OPcache and APCu on your server.

Windows Cache Extension for PHP

Windows Cache Extension for PHP is a PHP accelerator that speeds up PHP software on Windows and Windows Server. It doesn’t include support for opcode caching as PHP already includes it in its core, but it includes 4 unique types of cache: 

• File Cache — PHP OPCache only caches the opcode generated by PHP scripts. The PHP engine still has to access the script files on the server. Performing file operations can lead to significant performance overhead, so this extension includes a file cache that can store PHP scripts in shared memory.
• Resolve File Path Cache — Most PHP scripts use relative file paths to refer to each unique file. The PHP engine has to convert these to absolute file paths to access them. If there are a lot of files referenced like this, it can lead to performance issues. This extension stores the mappings of all relative and absolute file paths beforehand so that the PHP engine doesn’t spend too much time resolving file paths.

User Cache — This cache works similarly to APCu’s userland shared memory cache. PHP scripts can use user cache APIs to store objects and variables in the user cache and re-use them on subsequent requests. Not only does it improve the performance of PHP scripts, but it also allows the PHP engine to share data across multiple PHP processes.

Session Handler — This stores the PHP session data in the server’s shared memory to avoid performing file system operations for reading and writing session data. It’s helpful if an enormous amount of data is being generated in a single PHP session. 

Most WordPress installations use a Linux server. In case you’re one of the dozen users who uses a Windows Server to run your site, you can learn more about installing and configuring WinCache on its online manual.

Кеширование отношений

Кеширование сущностей с отношениями требует повышенного внимания.

Этот код выполняет два запроса. Получение сущности по и комментариев по . Реализуем кеширование:

Первый запрос был закеширован, а второй — нет. Когда драйвер кеша записывает Post в кеш, еще не загружены. Если мы хотим кешировать и их тоже, то мы должны загрузить их вручную:

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

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

Убираем предупреждение о 4-х байтовых символах

P.S. Убедитесь, что MariaDB версии выше 10.2. У меня была версия 15.1

Убедитесь, что на вашем сервере MySQL установлены следующие параметры InnoDB в файле:

и если их нет, то вставьте в конец файла.

Перезапустите сервер MariaDB

Выясните был ли изменён формат файла на Barracuda

Если формат файла — «barracuda» для каждой отдельной таблицы, то ничего особенного не остается делать. Продолжайте с инструкциями для MySQL. Во время тестирования формат файла всех таблиц был “Antelope”.

Таблицы должны быть перенесены в “barracuda” вручную, одна за другой. Однако команды SQL можно легко создавать:

Скопируйте появившийся ответ и уберите в нем символ «|». После этого вставляйте текст в консоль mariadb

После всего проделанного формат файла должен поменяться на Barracuda. Проверим.

Инструкции для MySQL

Вводим в режим обслуживания.

Должен быть такой результат

Запускаем конвертацию

Отключаем режим обслуживания.

Вот и всё готово.

Выводы и итоги

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

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