PHP APC кэшировать или не кэшировать?
У меня нет никакого опыта с кэшированием вообще, поэтому это может показаться глупым вопросом, но как вы знаете, когда кэшировать данные? Я даже не смог найти один сайт, который говорил об этом, но это могут быть просто мои навыки поиска или, может быть, слишком много переменных для рассмотрения?
Я, скорее всего, буду использовать APC. У кого-нибудь есть примеры того, какой наименьший объем данных вам понадобится для его кэширования? Например, предположим, у вас есть массив с 100 элементов, и вы используете цикл foreach на нем и выполняете простую манипуляцию массивом, следует ли кэшировать результат? Как насчет того, если бы у него было 1000 предметов, 10000 предметов и т. д.?
следует ли кэшировать результаты запроса к базе данных? Какие запросы вы должны кэшировать? Я предполагаю, что простой select и, возможно, пара присоединяет оператор к MySQL db не нуждается в кэшировании или нет? Предполагая, что кэш запросов mysql включен, означает ли это, что вам не нужно кэшировать в приложении слой, или вы все еще должны это делать?
Если вы создаете экземпляр объекта, следует ли кэшировать его? Как определить, должен ли он быть кэширован или нет? Таким образом, общее руководство по кэшированию было бы неплохо, примеры также были бы очень полезны, спасибо.
2 ответов
когда вы смотрите на кэширование данных, которые были прочитаны из базы данных в APC/memcache/WinCache/redis / etc, вы должны знать, что он не будет обновляться при обновлении базы данных, если вы явно не код для синхронизации базы данных и кэша. Поэтому кэширование наиболее эффективно, когда данные из базы данных не меняются часто, но также требует более сложного и / или дорогостоящего запроса для извлечения этих данных из базы данных (в противном случае вы можете также прочитать его из базы данных, когда вам это нужно)... поэтому дорогостоящие запросы соединения, которые возвращают одни и те же записи данных при каждом запуске, являются основными кандидатами. И всегда проверяйте, быстрее ли запросы считываются из базы данных, чем из кэша. Правильное индексирование базы данных может значительно улучшить время доступа к базе данных, особенно поскольку большинство баз данных также поддерживают свой собственный внутренний кэш, поэтому не используйте APC или эквивалент данных кэша, если накладные расходы базы данных не оправдывают его.
вы также должны знать о пространстве использование в кэше. Большинство кэшей имеют фиксированный размер, и вы не хотите их переполнять... поэтому не используйте их для хранения больших объемов данных. Используйте БТР.PHP скрипт доступен с APC для мониторинга использования кэша (хотя убедитесь, что он не является общедоступным для всех, кто обращается к вашему сайту.... плохая безопасность).
при хранении объектов в кэше объект будет сериализован() при его хранении и несериализован () при его извлечении, поэтому есть накладные расходы. Объекты с атрибуты ресурсов потеряют этот ресурс; поэтому не храните объекты доступа к базе данных.
разумно использовать только кэш для хранения информации, к которой обращаются многие / все пользователи, а не пользовательские данные. Для информации о сеансе пользователя придерживайтесь обычных сеансов PHP.
самый простой ответ заключается в том, что вы кэшируете данные, когда все становится медленным. Очевидно, что для любого приложения среднего и большого размера вам нужно сделать гораздо больше планирования, чем просто ждать и видеть подход. Но для подавляющего большинства веб-сайтов там вопрос, чтобы спросить себя: "вы довольны временем загрузки". Конечно, если вы одержимы временем загрузки, как и я, вы захотите попытаться сделать это еще быстрее.
Далее, вы должны определить, что конкретно это причина медлительности. Вы предположили, что ваш код приложения является источником, но его стоит изучить, есть ли другие внешние факторы, такие как большой размер файла страницы, чрезмерные запросы, отсутствие gzip и т. д. Используйте сайт какhttp://tools.pingdom.com/ или расширение, подобное yslow, для начала. (Быстрый совет убедитесь, что keepalives и gzip работают).
предполагая, что проблема заключается в продолжительности выполнения кода приложения, вы захотите профилировать ваш код с чем-то вроде xdebug (http://www.xdebug.org/) и просматривать выходные данные с помощью kcachegrind или wincachegrind. Это позволит вам узнать, какие части вашего кода занимают много времени для запуска. Оттуда вы будете принимать решения о том, что кэшировать и как кэшировать (или вносить улучшения в логику вашего кода).
существует так много возможностей для того, что проблема может быть и связанные с ней решения,что не стоит гадать. Таким образом, как только вы определите проблему, вы можете хотите опубликовать новый вопрос, связанный с решением этой конкретной проблемы. Я скажу, что если не используется должным образом, кэш запросов mysql может быть контрпродуктивным. Кроме того, я обычно избегаю кэша пользователя APC в пользу memcached.