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» или может есть какое-то другое решение? А то выходит не до конца статика получится, если будут постоянно запросы в БД улетать.


Поделитесь, пожалуйста, мыслями по поводу такой реализации. Может кто-то уже внедрял что-то подобное, какие могут возникнуть проблемы? Может сущетсвуют подводные камни, о которых я пока не подозреваю?
  • Вопрос задан
  • 9537 просмотров
Пригласить эксперта
Ответы на вопрос 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, ну я надеюсь, что всякие акселлераторы тоже используются.

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

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

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