Opcache control что это
Без неё процессор (AMD Ryzen 7 2700 4.1GHz) работает на той же частоте только уже на более низком вольтаже, с ней же был просто чёрный экран в стресс тестах. Никакой производительности она нигде не увеличивает. Она вроде должна отвечать за кеш, связанный с инструкциями, но что-то кроме минусов у неё ничего нету пока что. :)
AV Просветленный (22018) MraMor, зачем тогда спрашиваешь, если тебе лень загуглить эту тему и самому разобраться
Не нужна она. Маркетинг. ФПС - тот же, с ней и без неё.
Я понимаю, что пересказать то, что я написал конечно круто. :) Нооооо! Что она делает то? :)
Чёртовы гении, ахаха :) Ну на самом деле как я понял, она делает не намного меньше задержки у оперативной памяти. Но. Но в какой-то степени можно сказать, что производительность немного ВЫРАСТАЕТ, по крайне мере это видно там, где было 55 FPS, а стало 60.
Странник Искусственный Интеллект (255815) Амуде- есть Амуде ).
Однако теперь вот так:
AMD Ryzen 7 2700 4.1GHz работал с этой функцией с напряжением 1.325V (85 градусов в стресс тестах при 100% вращениях кулера), теперь 1.265V (68 градусов в стресс тестах при 70% вращениях кулера)
Как opcache портил мою жизнь и тратил мои нервы
Все началось с апдейта php, давным давно и в этой же самой галактике. И с того момента меня преследовала одна мерзкая проблема, которая портила мне жизнь на протяжении достаточно длительного времени.
Я использую php лишь для нескольких сайтов: блог на wordpress, форум на phpbb и небольшой сайтик на modx. Сие работает в связке nginx + php-fpm. Apache я принципиально не использую, так как nginx умеет все. У каждого fpm своя учетка, своя home, все зарезано и перерезано, чтобы только работало радовало мою параною.
И вот после того самого древнего апдейта начались странности. При открытии одного из сайтов и последующем открытии другого сайта я получал ошибку от предыдущего.
То есть при открытии сайта на phpbb и следом сайта на modx я видел ошибку о неустановленном блоке от phpbb, при открытии сайта на modx и следом блога на wordpress я видел привет 503 от modx. Как будто каким-то странным образом один fpm поток получал доступ к скриптам с другого, работающего в другой директории, другом порте, другом юзере в другой группе…
С того момента утекло много воды, конфигурации nginx были переписаны несколько раз, fpm'ы менялись, использовал .sock вместо порта. Результат был один и тот же — при быстром открытии двух разных сайтов ответ был от пергого, а второй мне выдавай глюк движка первого сайта.
Если бы сайты были популярные, я бы подсуетился с поиском решения, но форум висел полумертвый, блог посещает несколько человек как и modx. И вот пару дней назад, будучи в рабочем настронии и наводя порядок на сервере нагуглил интересную статью How To Host Multiple Websites Securely With Nginx And Php-fpm On Ubuntu 14.04.
И именно эта цитата прояснила мне «who is ху..»:
Amazingly, if you run again the test steps in the exactly the same order, you'll be able to read the sensitive file regardless of its ownership and permission. This problem in opcache has been reported for a long time, but by the time of this article it has not been fixed yet.
Я сказал себе: «значит это opcache колбасит мои fpm'ы последние 7 месяцев, суя куда не попадя свой кеш и снося башню несччастным CMS'ам!»
Последовала небольшая правка opcache.enable=0
и… проблема исчезла. Ее больше нет. Три несчастных сайта радостно рабоют, сервер мерно сопит в 384 дырки вентиляционного отверсия, а я чуть коснулся нирваны и даже прослушал пару треков.
Что я потерял с отключением opcache? opcache. Как это сказалось на моем перфомансе? Никак. Я использую кеш nginx, на сервере raid, а 8 ядер загружены в среднем на 5-10%. Так что лишний парсинг php скриптов ресурсов не съест. А визуально ничего не тормозит, в том числе и под нагрузочными тестами.
Частный случай? Может быть. Уже не багает? Вполне. Почему не php7? Потому, что. Апдейтить? Неа в топку, я на JSP код пишу.
1. Стоит ли вообще устанавливать OpCache? На какой прирост скорости я могу рассчитывать?
Конечно, это зависит от многих факторов. Если ваш сервер справляется с обработкой входящего трафика и время отклика у вас очень невелико, вероятно, вы не сочтете необходимым работать над увеличением производительности.
Но на большом сайте с большими объемами трафика даже небольшой прирост производительности будет весьма кстати.
Реализация OpCache позволит обрабатывать больше запросов в секунду и возвращать ответ быстрее, чем без движка кэширования байт-кода. Так как OpCache довольно прост в установке и конфигурировании, вся настройка не займет у вас много времени.
Если вам хочется увидеть результаты тестирования OpCache , советую вам прочитать статью AppDynamics по реализации этого кэш-движка.
В результате их тестов после установки OpCache среднее время отклика сайта сократилось на 14%. Снижение времени отклика различных действий веб-приложений составило от 6% до 74%.
Как поясняется в статье, производительность различных частей кода может увеличиться в разной степени. Я рекомендую внимательно прочитать эту статью и решить самим, где вы можете получить высокий прирост производительности.
2. Я уже использую кэширование с помощью APC. Стоит ли мне переходить на OpCache?
Я думаю, стоит. OpCache имеет ряд преимуществ перед APC .
Прежде всего, кэширование APC не будет работать с новейшими версиями PHP . PHP 5.5 он не поддерживает вовсе. Его не рекомендуют устанавливать на PHP 5.4 или, как было сообщено, такая конфигурация может привести к ошибкам выполнения, которые нарушат работу всего приложения.
Просто прочитайте эту статью Википедии по PHP-акселераторам или эту подборку материалов Stack Overflow , если хотите узнать об этом подробнее.
Как правило, OpCache более тесно связан с самим PHP , по сравнению с другими движками кэширования байт-кода – в результате вы будете располагать такими преимуществами, как более частые обновления приложения и меньшее количество ошибок.
Важно только помнить, что при переходе с APC на OpCache последний не работает как движок кэширования данных. Если вы уже реализовали APC , то можете использовать его функции apc_add() и apc_fetch() , которые будут служить в качестве интерфейса для службы кэширования данных.
OpCache является только движком кэширования байт-кода, поэтому он не предлагает аналогичные функциональные возможности по кэшированию данных.
Если вы планируете перейти с APC на OpCache , помните об этом ограничении. Имейте в виду, что если вы хотите сохранить функциональность APC на уровне пользователя, для этого существует специальный проект APCu .
3. Как проверить, на самом ли деле OpCache кэширует мои файлы?
Если вы уже установили и настроили OpCache , для вас может оказаться очень актуальной возможность контролировать, какие PHP -файлы фактически кэшируются. Сам кэш-движок работает в фоновом режиме, и он довольно понятен для пользователей или веб-разработчиков.
Для того чтобы проверить свой статус, вы можете использовать одну из двух функций, которые предоставляют такую информацию: opcache_get_configuration() и opcache_get_status() .
Кроме того, существует ряд готовых скриптов, извлекающих все настройки OpCache , а также данные о состоянии и отображающих их в интуитивно понятной форме. Вам не нужно самим составлять никакого дополнительного кода, просто воспользуйтесь одним из инструментов из приведенного ниже списка:
- opcache-status Расмуса Лердорфа ;
- OpCacheGUI Петера Нордийка ;
- opcache-gui Эндрю Коллингтона .
В своих проектах я использую скрипт opcache-gui , который содержит весь нужный мне функционал. Чтобы проверить, что кэширует движок, просто просмотрите данные, приведенные на вкладке “Overview” страницы графического интерфейса opcache-gui .
Если в соответствующей строке указано, что использование памяти и значение количества переходов больше нуля, это означает, что OpCache кэширует код PHP , а кэшированные файлы используются для обработки запросов.
Чтобы увидеть перечень конкретных PHP файлов, которые кэшируются, просто перейдите к вкладке “File usage” . Просмотрите приведенный там список файлов, чтобы убедиться, что файлы ваших проектов кэшируются:
4. Существуют ли какие либо специфические установки конфигурации для конкретных фреймворков, которые я должен задать?
Но это будет работать, только если конфигурация OpCache задана надлежащим образом. Неправильная конфигурация движка кэширования может поломать весь сайт.
Существует также параметр, который важен для инструментов и фреймворков, использующих аннотации. Если вы работаете с Doctrine , Zend Framework 2 или PHP Unit , не забудьте установить значение true для opcache.load_comments и opcache.save_comments .
В этом случае сопроводительные комментарии документации также будут включены в прекомпилированный код, сгенерированный OpCache . Включение этой опции позволит вам нормально работать с аннотациями.
Если ваш проект базируется на каком-то одном конкретном фреймворке или веб-приложении, всегда стоит ознакомиться с документацией на предмет настроек конфигурации OpCache . Например, существуют специальные настройки для Moodle .
5. Я храню настройки конфигурации своих приложений в файле PHP. Могу ли я запретить его кэширование?
Если ваш проект содержит файлы, которые изменяются намного чаще, чем другие части приложения, вы можете исключить их из кэширования. Это может быть особенно удобно при работе с файлом PHP , содержащим директивы конфигурации сайта.
Если вы запретите их кэширование, то будете уверены, что каждое изменение, хранящееся в таком файле, будет отображаться в вашем приложении сразу же.
OpCache позволяет указать черный список файлов, содержащий все полные пути к файлам, которые не будут обрабатываться движком кэширования. После установки директивы opcache.blacklist_filename , просто добавьте список файлов, которые вы не хотите кэшировать.
На этой странице документации вы сможете найти примеры того, как исключить из кэша определенные файлы.
6. Как я могу работать и со средой разработки, и с рабочей средой на одном сервере, где подключен OpCache?
Если ваш сервер работает с несколькими приложениями, вы можете настроить OpCache таким образом, чтобы он использовался только некоторыми из них. Разработка сайтов и тестирование являются примерами сред, для которых подключение кэширования байт-кода является нежелательным. Это может принести больше вреда, чем пользы.
К счастью, вы можете использовать функции OpCache для одного проекта и отключить его для другого, все на одном сервере. Для этого сначала нужно включить OpCache на глобальном уровне, установив в файле php.ini значение true для директивы opcache.enable .
Затем, если вы не хотите использовать кэширование байт-кода для одного из ваших проектов, просто отключите его, установив для той же директивы значение false с помощью функции ini_set() .
Установив значение false для opcache.enable в верхней части файла в вашем проекте, вы отключите кэширование для этого конкретного проекта, сохраняя его для всех прочих.
Заключение
Я надеюсь, что ответы на эти вопросы дали вам практическую информацию о том, как использовать OpCache в PHP -приложениях. Если у вас есть другие вопросы или замечания относительно темы данной статьи, оставьте их в комментариях.
Разбираемся с OpCache
В Сети вы легко найдете много учебников по установке и настройке OpCache (движок по умолчанию включен в версию PHP 5.5 , но вы можете установить его как расширение в более старых версиях). В приведенной ниже статье вы найдете ответы на некоторые распространенные вопросы, касающиеся различных практических аспектов работы с этим кэш-движком.
Cache-Control
В этой статье мы расскажем, как использовать Cache-Control . Большинство современных сайтов используют Cache-Control для управления кэшированием браузеров.
Основные принципы использования заголовка Cache-Control
Заголовок Cache-Control определяет количество времени, которое файл должен находиться в кэше, и метод кэширования:
Если браузер видит, что файл должен храниться в течение пяти минут, он будет оставаться в кэше браузера в течение этого времени. И этот файл не должен обновляться при его повторном вызове:
В качестве примера можно привести логотип сайта. Если посетитель заходит на одну страниц ресурса, он загружает логотип. Если пользователь переходит на другую страницу, изображение логотипа не будет загружаться снова. Вместо этого будет использоваться кэширование через htaccess .
Что такое max-age?
max-age определяет время, в течение которого файл должен храниться в кэше.
Директива ответа max-age указывает, что ответ следует считать устаревшим после того, как проходит больше времени, чем заданное количество секунд.
Применение max-age
Часть заголовка max-age выглядит следующим образом:
Значение max-age задается в секундах.
Часто используемые значения для max-age :
- Одна минута: max-age=60 ;
- Один час: max-age=3600 ;
- Один день: max-age=86400 ;
- Одна неделя: max-age=604800 ;
- Один месяц: max-age=2628000 ;
- Один год: max-age=31536000 .
При применении max-age для определения времени, которое файл должен храниться в кэше, следует учитывать тип этого файла и то, как он используется.
Директивы кэширования
Часть директивы кэширования в браузере htaccess приведенного выше заголовка выглядит следующим образом:
По умолчанию, большинство элементов считаются публично кэшируемыми ( могут кэшироваться ), но существуют случаи, когда такое поведение нежелательно: для конфиденциальных документов, для контента, предназначенного для конкретного пользователя, и т.д.
Мы рассмотрим три основные директивы Cache-Control :
public
Официальная спецификация определяет ее следующим образом:
Если вы хотите использовать кэширование для ускорения загрузки страницы, и этот ресурс не является частным, то нужно применить директиву public .
private
Директива private означает, что ресурс предназначается только для конкретного пользователя. В качестве примера можно привести страницу Twitter . Когда вы заходите в Twitter , вы видите одно, а другой человек, открывающий тот же URL-адрес , видит другое содержимое. Даже если информация на этой странице общедоступна, она « специфична » для конкретного человека.
Официальная спецификация определяет ее следующим образом:
no-store
Директива no-store является самым категоричным запретом на кэширование. Официальная спецификация определяет ее следующим образом:
Еще раз отмечу, что само по себе это ничего не гарантирует.
Типы файлов
Два вопроса, которые должен задать себе веб-мастер:
- Какие типы файлов нужно хранить с помощью кэширования файлов htaccess?
- Как долго их нужно хранить в кэше?
Какие типы файлов должны храниться в кэше?
Я хотел бы отметить следующие типы файлов:
Что следует учесть
Только вы можете определить, какие инструкции больше всего подходят для вашего сайта. Если вы собираетесь изменить какой-либо ресурс ( например, файл CSS ), и этот ресурс кэшируется в браузере htaccess , то стоит подумать над тем, чтобы изменить имя файла. Тогда обновленный файл CSS будет просмотрен всеми пользователями. Это называется URL-дактилоскопией .
Как добавить Cache-Control на сайт
Cache -Control добавляется к файлам точно так же, как любой другой заголовок на вашем сервере. В этой статье мы говорим о заголовке Cache-Control . Так как его добавить? Это зависит от вашего веб-сервера. Мы рассмотрим наиболее распространенные сценарии.
Файл .htaccess
Большинство использует для добавления заголовков файл .htaccess .
Пример кода файла .htaccess
Общий код для установки заголовка Cache-Control с помощью файла .htaccess :
Но приведенный выше код не позволяет задавать различные инструкции кэширования сайта htaccess для различных типов файлов.
Чтобы применить разные заголовки Cache-Control к различным типам файлов, мы будем использовать:
Приведенный выше код означает следующее:
Предположим, что мы хотим изменить время кэширования изображений на один год, но оставить для файлов CSS и JS срок хранения один месяц.
Мы можем добавить в файл .htaccess следующий код:
Приведенный выше код состоит из двух блоков: один для изображений и один для CSS и JS-файлов . У нас может быть несколько блоков в файле .htaccess .
Более быстрым и предпочтительным способом является установка заголовков с помощью конфигурационного файла. Примеры кода, приведенные выше для htaccess кэширования , будут работать и здесь.
Используйте сочетание filesMatch и Header , чтобы создать отдельные инструкции для конкретных типов файлов ( примеры кода для файла .htaccess подходят ).
NGINX
Используя директивы expires, можно добавить инструкции кэширования в блоки сервера или местоположения:
Приведенный выше код задает инструкции кэширования для каждого из типов файлов, перечисленных в первой строке. Эти типы файлов могут быть добавлены или удалены. Также можно добавить несколько блоков для более гибкой настройки.
Litespeed
Если есть лицензия на несколько процессоров, то вы должны иметь доступ к расширенным директивам кэширования через онлайн-конфигурацию.
Если у вас нет лицензии, то необходимо будет использовать кэширование сайта htaccess . Приведенные выше инструкции для использования в .htaccess подходят также и для серверов Litespeed .
Читайте также: