Повторная проверка opcache только после git push

Я использую PHP с OPcache. Я использую git-push только для того, чтобы развернуть мой веб-сайт в рабочей среде (не совсем, это сразу после модульных тестов, но неважно). В файле php.ini настройки OPcache касаются «времени» и «частоты». Но я просто хочу сбросить кеш после git pull на моем сервере.

Поэтому я думаю, что мне просто нужно вызвать opcache_reset после git-pull на моем рабочем сервере и установить opcache.validate_timestamps на 0 (никогда не сбрасывать кеш)

Я ничего не читал об этом, поэтому сомневаюсь: не знаю, хорошая ли это практика. Я что-то пропустил? Есть ли риск или это нормально?

Большое спасибо!

P.S. : я использую PHP-фреймворк и композитор (composer install запускается сразу после git-pull)


git php optimization composer-php opcache
person rap-2-h    schedule 18.01.2015    source источник
comment
Может быть интересно почитать: codeascraft.com/2013/07/01/ atomic-deploys-at-etsy   -  person halfer    schedule 18.01.2015
comment
@halfer Да, интересное чтение, спасибо :)! Это не ответ на мой вопрос, но я буду иметь это в виду.   -  person rap-2-h    schedule 19.01.2015
comment
Вы не должны запускать composer update, потому что это захватит программное обеспечение, с которым ваши тесты не выполнялись. Всегда запускайте composer install при использовании автоматических сценариев.   -  person Sven    schedule 23.01.2015
comment
@Sven Я запускаю composer install, но я написал composer update в своем вопросе :/ Спасибо, я отредактирую свой пост!   -  person rap-2-h    schedule 23.01.2015

Ответы (1)


arrow_upward
2
arrow_downward

Чтобы получить наибольшую выгоду от OPCache, вы должны отключить opcache.validate_timestamps. Если впоследствии вы будете вызывать opcache_reset() из скрипта каждый раз, когда развертываете свой код на сервере, то ваш OPCache очищается один раз для каждого нового набора файлов, и система не тратит ресурсы на постоянную проверку файлов.

Однако есть пара «подводных камней»:

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

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

<?php

if (php_sapi() != "cli") die("Not accessible from web");
opcache_clear();

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

Если очистка из командной строки не работает, рассмотрите возможность создания аналогичного сценария и вызова его через Интернет с помощью curl или wget. Например, curl http://example.com/clear_cache.php?secret=abc123. Если вы создаете сценарий для доступа в Интернете, убедитесь, что он проверяет секретный ключ, чтобы предотвратить загрузку вашего сервера кем-либо, постоянно очищая кеш.

Наконец, как предлагали другие, чтобы сделать ваши сборки полностью воспроизводимыми между тестированием и развертыванием, подумайте о том, чтобы в конце процесса тестирования создать файл .zip всего кода, используемого для тестирования, включая библиотеки, извлеченные композитором. Вместо git pull на вашем сервере просто разархивируйте файл в корень кода. Я понимаю, что git pull && composer update легко. Однако, как предполагали другие, если библиотека обновляется между временем запуска тестов и временем развертывания, ваш код может больше не работать должным образом.

person jwriteclub    schedule 22.07.2016
comment
Хорошо, спасибо! Что касается вашего последнего пункта, это не проблема, потому что я не использую composer update, я использую composer install (так что нет никакой разницы между тестами и продом, composer.lock то же самое) - person rap-2-h; 23.07.2016