PHP — как сделать толковый кэш?

Задача

Есть сайт — новостная лента. Двиг — самописный, PHP + MySQL. В данный момент с каждым посещением страницы информация формируется из БД.


Срочно надо перейти с динамики на статику.

То, как я придумал это сделать
  • При первом посещении странички c id=1500 — содержимое берется из БД и записывается в файл cache/1500.html. Делается с помощью ob_start().
  • При повторном посещении этой странички — смотрим дату создания файла 1500.html, если дата меньше 15 минут от тек. времени, инклудом выводим 1500.html. Если больше 15 минут — снова берем из БД и перезаписываем файл.


Вопросы
1. Комментарии к новостям. Получается, при добавлении нового комментария необходимо будет убивать файл 1500.html? Сайт живой, комментов много. Вот не знаю, я хард не задолбаю такими запросами?

2. Статистика количества просмотров новости. При каждом посещении продолжать делать «UPDATE `views` = `views` + 1» или может есть какое-то другое решение? А то выходит не до конца статика получится, если будут постоянно запросы в БД улетать.


Поделитесь, пожалуйста, мыслями по поводу такой реализации. Может кто-то уже внедрял что-то подобное, какие могут возникнуть проблемы? Может сущетсвуют подводные камни, о которых я пока не подозреваю?
  • Вопрос задан
  • 9371 просмотр
Пригласить эксперта
Ответы на вопрос 9
alexxxst
@alexxxst
Напишу, как я это сделал на одном из своих сайтов.
У меня все кешируется в memcached по ключам, которые строятся из хеша строки с параметрами (что-то типа id, page, action и т.д.). Страница ПОЛНОСТЬЮ складывается в кеш. Достается все моментально. При написании коммента (и любом другом изменении страницы) запись в memcached убивается и пересоздается при следующем запросе страницы. Раньше все было сделано в файлах на диске. Размер кеша где-то 400-500 мб со сжатием на лету. Странички имеют время жизни разное в зависимости от типа страницы, всякие каунтеры и голосовалки сделаны динамически через подзапрос. Тормозов нет абсолютно, все летает. P.S. сервак выделенный, конечно.

P.S. по поводу пункта 1 за хард переживать не стоит, если частые обращения к одному и тому же, скорее всего все будет в дисковом кеше в оперативке. Статистика и прочие каунтеры обновлять раз в 5-10 минут и нормуль.
Ответ написан
@niko83
Можно кэшировать сами запросы к БД, и проанализировать: кеш каких запросам следует очищать после того или иного действия.
Например после добавление нового комментария нужно почистить счётчик комментариев и выборку всех комментариев к данной статье, при этом запрос на кол-во просмотров статьи трогать не надо. (пример грубый).

Какие-то данные в кеше нужно будет очищать сразу после какого-то события, а какие-то данные можно очищать по времени (тот же счётчик кол-ва просмотров статьи).

Можно подумать о использовании тегов в кэше, а не просто по ключу сохранять.

Подумать об использовании системы кеширования: на файлах, memcache, redis, apc, и прочее…

Чтоб что-то более конкретное посоветовать нужно смотреть на эту ленту и прочие особенности реализации
Ответ написан
@Tagire
sysoev.ru/nginx/docs/http/ngx_http_proxy_module.html
Позволяет кэшировать ответы от апача как статику на определенное время, в зависимости от количества посещений страницы, cookie, аргументов. При добавлении коммента можно просто url менять на &updated=timestamp.
Статистику в данном случае лучше перевести на ajax и отдельный быстрый сервер типа node.js, чтобы оно клало ее в что-то типа redis. Тогда ее можно будет в любой момент перенести на отдельный сервер или выключить.
Ответ написан
@DileSoft
Во-первых, если на вас идет DDOS-атака, следует разбираться с DDOS-атакой, а не мощностями сервера. Это бессмысленно, увеличивать мощности, только чтобы атаку отбивать. Атаку отбивать надо специализированными для этого средствами. А то вы что-нибудь оптимизируете, атакующий усилит атаку, и пойдет бессмысленная гонка.

Анализируйте тип атаки, анализируйте ее принципы, настраивайте фильтры. Или найдите хостера, который, как ему и положено, будет этим заниматься сам.
Ответ написан
holyorb2
@holyorb2
1. Харду ничего не будет 100%, база мускул тоже храниться на харде и любое движения сайта система пишет кучу логов и сессий и прочего добра, даже если комментарий ни кто не оставляет
2. Статистику лучше перенести в гугл аналитик. там она на порядок мощнее будет и нет нагрузки на ваш сервер
Ответ написан
holyorb2
@holyorb2
Чем вызван переход на статику?
Если нагрузкой на сервер, то нужно усилять сервер а не сайт рубать, хотя одно другому не мешает.

И как много комментариев пишут? Если комментируют в день не более 10% статей, то пересоздания кеша будет нормальным выходом из ситуации
Ответ написан
MpaK999
@MpaK999
Буду!
Писать кэш в доступную из веба папку /cache/1500.html
А при запросе, через mod_rewrite проверять сперва нет ли такого файла, отдавать, а если нет то редирект на index.php?id=1500
Ответ написан
сделайте «прослойку» из nginx + memcache
nginx настроить получать страницы из мемкэша по url
если такой страницы нет, то делать запрос «бэку», он будет формировать страницу, отдавать её + пихать в мемкэш
в гиг памяти влезет скорее всего весь сайт.

второй вариант чуть проще: связка nginx + varnish +apache. На апач ставить mod_evasive.
ну и настройки подобрать, вроде keepalive = 0.
Ответ написан
akalend
@akalend
программирую
1) 30-40К это не такая уж и большая посещаемость, у меня сервак выдерживал 65К
используй мемкеш однозначно, в нем, например, можно хранить не только контент, но и информацию об обновление и лишний раз трогать БД
( Статистика количества просмотров новости. При каждом посещении продолжать делать «UPDATE `views` = `views` + 1»).
эту инфу я бы точно держал в памяти. У меня в одном муз проекте вся статистика скачиваний за день (200-250К) хранится в мемкеше. А раньше дергалась БД (именно на UPDATE x=x+1) и сервак не слабо тормозил.

2) как уже советовали выше — если хранить контент в мемкеше, то можно настроить nginx так, чтоб он отдавал его напрямую не дергая бэкенд

3) если есть Аппач — то его в топку, используй php-fpm, ну я надеюсь, что всякие акселлераторы тоже используются.

есть куча статей на Хабре как можно улучшить производительность
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы