Comments 25
Лет 5 назад на одном з проектов прикрутил какой акселератор, работающий по такому же принципу
Действительно получил ускорение в 2-3 раза в самых нагруженных скриптах
и забыл про него, работает там сам по себе, менять на другой ни за что не буду.
А как это работает? Какими функциями пользоваться для сохранения / получения переменной из общей памяти? Ничего такого в документации OPCache не нашел. К примеру, в APC есть функции apc_store() и apc_fetch(). А в OPCache как?
Памяти по сравнению с 5-кой жрет в 1.5 раза меньше в среднем.
Эффект дает процентов на 50 лучше.
Правда 7-ку на продакшен в серьезные проекты пока ставить немного стремно, но готовится уже к этому пора)
Правда 7-ку на продакшен в серьезные проекты пока ставить немного стремно, но готовится уже к этому пора)
У меня 7-ка в продакшене уже месяцев 8 и все хорошо. Правда все сильно упирается в задачи которые вы решаете. Ну и да, в случае существующих проектов если у вас нет тестов — придется проводить полное регрессионное тестирование.
Есть анализаторы кода на предмет совместимости с 7.
если у вас есть что-то работающее, и вы что-то в этом меняете (например меняете версию PHP), то есть шанс что что-то сломается. Вот когда то что работало раньше после изменений ломается — это называется регрессией. Тестирование на предмет выявления "сломанного" называется регрессионным тестированием. Все ж логично.
Есть анализаторы кода на предмет совместимости с 7.
Увы анализаторы не справляются с такими вещами. Вы будете смеяться, а я подобные штуки видел.
И смех в том, что если проект не покрыт тестами, шанс наткнуться на какую-нибудь такую ахинею выше.
если у вас нет тестов — придется проводить полное регрессионное тестирование
:)
А как его провести, если проект не покрыт тестами? :)
Увы анализаторы не справляются с такими вещами.
Это как раз правильная оптимизация.
И
If two members compare as equal, their relative order in the sorted array is undefined.
А как его провести, если проект не покрыт тестами? :)
Есть такая штука как ручное тестирование. И полное регрессионное тестирование руками — это очень дорого.
Это как раз правильная оптимизация.
Вот приходит вам проект на самописном фреймворке, тестов нет, кода много, логики много, многое писалось еще под php5.2 (хоть сейчас это и работает под 5.5), и вы тут думаете "а не перейти ли мне на 7.0", и у вас нет 100% уверенности даже после статического анализа не сломается ли чего. Просто потому что анализаторы не хэндлят такие вещи ибо и так очевидно что если чувак завязал логику на детали реализации самого пыха — он дурак.
С таким подходом нужно покрывать тестами весь PHP :)
А ручные поверхностные тесты никто в любом случае не отменял.
Я сомневаюсь, что даже при наличии тестов, они будут проверять именно эту функцию. :)
1) тесты покрывают не функции php, а код, который их использует. Соответственно если тесты писал адекватный человек, то такие изменения в поведении они выявят.
2) сомневаюсь что адекватный человек, который бы написал адекватный тест, завязывался бы на это поведение пыха, так что… все совсем плохо)
Я бы немного перефразировал: «стрёмно переводить большие серьезные проекты на php 7, потому что надо всё хорошо проверить, а потом еще ухитриться с минимальным простоем обновиться». У нас на подготовительные работы ушло несколько месяцев, когда выгребали из разных неожиданных мест разные ошибки, связанные с пхп-7. И потом за ночь мы без даунтайма переключили продакшен.
UPDATE. Причем как раз примерно год назад мы приняли решение, что будем на продакшене 7-ку ставить. А дальше пришлось работать.
Очень интересно. Спасибо буду перечитывать статью. Весь материал бегло не охватить.
Их главная задача — единожды скомпилировать каждый PHP-скрипт и закэшировать получившиеся опкоды в общую память, чтобы их мог считать и выполнить каждый рабочий процесс PHP из вашего production-пула (обычно используется PHP-FPM).
Вроде у каждого PHP-процесса свой кеш. Или когда это изменилось?
Его необходимо активировать с помощью обычного процесса активации через php.ini.
Оно, вроде, включено по-умолчанию.
Поэтому никогда не допускаете истощения общей памяти.
Так если низкое значение грязной памяти (читай файлы не менялись), то никакого перезапуска не будет.
Но будьте осторожны, потому что он использует realpath_cache, а это может вам навредить.
То есть для всех ссылок кешируется только исходный файл 1 раз?
Есть realpath_cache_ttl, который равен по умолчанию 120с.
Если вы используете современный стек приложений, на базе фреймворка, с большим количеством зависимостей и т.д… тут не обойтись как минимум без гигабайта.
Это ведь не для одного проекта?
Например, Gitlab на рельсах кушает гигабайт. Сколько надо отдать Opcache для аналогичного проекта на Laravel/Symfony?
Лучшая статья про конфигурирование OPCache, которую встречал. Наиподробнейшая! Спасибо. В сети русскоязычной много повторяющейся информации про opcache, которая несколько устарела, здесь же и практика конфигурирования и подробная теория работы.
Обзор расширения OPCache для PHP