Стоит ли когда-нибудь «механизм кэширования» только для PHP? - PullRequest
3 голосов
/ 20 марта 2010

Я написал довольно небольшой скелет для своих веб-приложений и подумал, что я бы также добавил для него небольшой кеш.

Это довольно просто:

  • Если текущая страница существует в виде файла в кэше и файл не слишком старый, прочитайте его и выйдите из программы, а не перестраивайте страницу

  • Если текущая страница не кэширована / устарела, перечитайте страницу и сохраните ее

Однако, плохая вещь об этом:

  • Мои тесты производительности со страницей, которая получает 40 относительно длинных постов по запросу MySQL, показали, что с использованием кеша, для обработки одного запроса (1000 тестов каждый) * потребовалось еще больше 1021 *

  • Как это может произойти?

  • Как выполнение запроса MySQL, циклически просматривая результаты в первый раз, передавая результаты в шаблон и затем повторяя циклически повторяющиеся результаты во второй раз, быстрее, чем проверка filemtime() и считывание?

  • Должен ли я просто удалить весь кэш raw-PHP и воспользоваться доступностью некоторого кеша PHP, такого как memcached или около того?

Ответы [ 4 ]

2 голосов
/ 26 марта 2010

Преждевременная оптимизация - корень всего зла. Если вам не нужен кеш, не используйте кеш.

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

Если вы просто хотите кэшировать элементы, лучше всего использовать что-то вроде memcached или APC-кеша. Преимущество APC в том, что он более доступен (на ваших серверах должен быть установлен APC для кэша кода операции, если вы вообще заботитесь о производительности), а в memcached есть опция, позволяющая вам иметь кеш, доступный нескольким веб-серверам (и / или несколько кешей)

0 голосов
/ 27 марта 2010

Возможно -

Если вы используете кэш запросов apc и mysql (по умолчанию включено), то ваш php-код уже выполнен и сохранен как код операции в apc, и если вы неоднократно нажимаете на один и тот же запрос, кеш запросов mysql также будет кешировать результаты базы данных. В этом случае большая часть данных поступает из памяти, поэтому чтение файла может быть медленнее. Реальное преимущество этого подхода заключается в том, что вы будете экономить количество подключений mysql, но производительность может не увеличиться.

Использование кеширующего прокси-сервера, такого как squid, должно быть идеальным решением в вашем случае, чтобы страница обслуживалась непосредственно из кеша до ее истечения. Другая оптимизация для вышеупомянутой ситуации будет заключаться в том, чтобы просто кэшировать вывод mysql в memcache, что было бы лучше, чем нажатие mysql, а кеш запросов мал по размеру. Наконец, если вы действительно хотите кэшировать сгенерированную разметку, вы можете использовать буферизацию вывода (ob_start) и сохранять результаты непосредственно в memcache.

0 голосов
/ 20 марта 2010

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

http://www.mnot.net/cache_docs/

http://blog.digitalstruct.com/2008/02/27/php-performance-series-caching-techniques/

0 голосов
/ 20 марта 2010

Я думаю, что нет.

Самой медленной частью приложения, вероятно, является трафик базы данных.

Если вы включите кэшированный файл HTML / PHP, он должен быть быстрее.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...