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

Question

Есть ли разница между кэшированием объектов PHP на диске, а не нет? При кэшировании объекты будут создаваться только один раз для ВСЕХ посетителей сайта, а если нет, то они будут создаваться один раз для каждого посетителя. Есть ли разница в производительности или я бы потратил на это время?

В основном, когда дело доходит до этого, главный вопрос:

Несколько объектов в памяти, на пользователя PER (каждый пользователь имеет свой собственный набор экземпляров объектов)

VS

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

Answer 1

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

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

Дисковый кеш не обязательно большой выигрыш. Если вы используете PHP и беспокоитесь о производительности, вы должны запускать приложения в среде кэширования кода, например, APC или Zend Platform. Эти инструменты также обеспечивают кэширование, которое вы можете использовать для сохранения объектов PHP в вашем приложении. Memcached также является популярным решением для быстрого кэша памяти для данных приложений.

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

Answer 2

Есть ли разница между кэшированием объектов PHP на диске, а не нет?

Как и во всех настройках производительности, вы должны измерять то, что вы делаете, а не просто слепо выполнять некоторые ритуалы вуду, которые вы не до конца понимаете. Когда вы сохраняете объект в $_SESSION, PHP фиксирует состояние объектов и генерирует из него файл (сериализация). После следующего запроса PHP создаст новый объект и повторно заполнит его этим состоянием. Этот процесс намного дороже, чем просто создание объекта, поскольку PHP должен будет выполнить дисковый ввод-вывод, а затем проанализировать сериализованные данные. Это должно происходить как при чтении, так и при записи.

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

Answer 3

Кэширование объектов в памяти обычно лучше, чем на диске:

http://code.google.com/p/php-object-cache/

Однако, сравните для себя и сравните результаты. То, что они только вы можете знать наверняка.

Answer 4

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

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

=> Держитесь как можно дальше от жесткого диска и по возможности кэшируйте данные в ОЗУ.

Если у вас нет проблем с производительностью, я бы посоветовал сделать ... ничего.

Если у вас есть проблемы с производительностью: бенчмарк, бенчмарк, бенчмарк. (Единственный реальный способ найти лучшее решение).

Интересное видео на эту тему: Масштабируемость YouTube

Answer 5

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

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

Однажды я использовал это для сериализации кэшированных объектов в файлах на относительно статичном контенте на домашней странице, принимая 200+ ударов в секунду с сильно загруженной БД одного экземпляра с неизбежными запросами (на моем уровне). На этой домашней странице вы получили около 40% производительности.

Код - при разработке с нуля - очень быстрый и простой, с кучей_пользователей / get_contents и un / serialize. Вы можете назвать свой файл после, скажем, контрольной суммы md5 вашего запроса.

Answer 6

Я использовал результаты кэширования SQL-запросов и результаты вычислений, требующие больших затрат времени, и добился впечатляющих результатов. сейчас я работаю над приложением, которое выбирает более 200 записей базы данных (в которых много функций SQL и вычислений в них) из таблицы, содержащей более 200 000 записей, вычисляет результаты по извлеченным данным для каждого запроса. Я использую компонент Zend_Cache Zend Framework для кэширования вычисленных результатов, поэтому в следующий раз мне не нужно:

1. подключиться к базе данных
2. ждать, пока сервер базы данных найдет мои записи, вычислит функции sql, вернет результаты
3. извлечение не менее 200 (может даже 1000) записей в память
4. перебери все эти данные и посчитай, что я от них хочу

Я просто делаю:

1. вызов метода Zend_Cache :: load (), который будет выполнять чтение некоторых файлов.

, что сэкономит мне по крайней мере 4-5 секунд при каждом запросе (очень неточно, я не профилировал его на самом деле. Но прирост производительности вполне заметен)

Answer 7

Я думаю, вы бы потратили время, если данные не являются статичными и сложными для генерации.

Скажем, у вас есть объект, представляющий ACL (список контроля доступа), в котором указано, какие пользовательские уровни имеют разрешения для определенных ресурсов.

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