Производительность кэширования объектов PHP

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

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

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

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

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

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

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

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

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

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

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

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

Я просто:

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

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

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

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

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

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

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

Следует помнить следующее: - Самая медленная часть сервера - это жесткий диск. - создание объектов НАМНОГО лучше, чем доступ к диску.

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

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

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

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

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

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