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

Question

[PlatinumArcade]

Задача

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


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

То, как я придумал это сделать

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

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

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


Поделитесь, пожалуйста, мыслями по поводу такой реализации. Может кто-то уже внедрял что-то подобное, какие могут возникнуть проблемы? Может сущетсвуют подводные камни, о которых я пока не подозреваю?

Comments

[PlatinumArcade]

Посещалка в районе 30к-40к хостов в сутки. Отсюда и опасения, что хард очень удивится.

Answer 1

[Алексей]

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

P.S. по поводу пункта 1 за хард переживать не стоит, если частые обращения к одному и тому же, скорее всего все будет в дисковом кеше в оперативке. Статистика и прочие каунтеры обновлять раз в 5-10 минут и нормуль.

Comments

[Алексей]

Кстати, можно посмотреть в сторону nginx + proxy_cache. Но он не настолько гибок, как сриптовое свое. Результаты работы этого способа видны здесь на хабре, иногда с глюками :)

[DorBer]

Добавлю, что nginx умеет забирать кэш страницы из memcache, откуда ее можно при желании убивать и генерить новый.

Answer 2

[niko83]

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

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

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

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

Чтоб что-то более конкретное посоветовать нужно смотреть на эту ленту и прочие особенности реализации

Comments

[PlatinumArcade]

Сайт сейчас лежит под DDoS-ом. Там 8к компов нападает, по 5 запросов с каждого. Рандомно по всему сайту на странички заходят. На каждой страничке сайта далеко не одно обращение в БД. Вот и выходит каждую секунду сотни тыс. обращений к БД.

По поводу обнуления кеша — количество просмотров, конечно, это не критично обновлять в реальном времени. А вот новый коммент — это важно. Буду анализировать, спасибо.

[XaosSintez]

По поводу «memcached наше все».
Если сервер один, то лучше использовать в качестве кэша xcache или APC. Причина проста — не создается лишнее TCP соединение. Кроме того они же «ускоряют» обработку php файлов.
А вот если серверов несколько и требуется общий \ распределенный кэш — тогда да, memcached наше все

Answer 3

[Тахир]

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

Answer 4

[DileSoft]

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

Анализируйте тип атаки, анализируйте ее принципы, настраивайте фильтры. Или найдите хостера, который, как ему и положено, будет этим заниматься сам.

Comments

[PlatinumArcade]

Да, хостер параллельно занимается решением проблемы. Уже становится понятно, что статикой горю не поможешь…

Answer 5

[holyorb2]

1. Харду ничего не будет 100%, база мускул тоже храниться на харде и любое движения сайта система пишет кучу логов и сессий и прочего добра, даже если комментарий ни кто не оставляет
2. Статистику лучше перенести в гугл аналитик. там она на порядок мощнее будет и нет нагрузки на ваш сервер

Comments

[PlatinumArcade]

Речь идет от внутренней статистике. Т.е. надпись под заголовком новости «Новость добавил: admin | Просмотров: 1540 | Комментариев: 24».

[holyorb2]

в кеш записывать на места подобной информации ключ. например

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

Answer 6

[holyorb2]

Чем вызван переход на статику?
Если нагрузкой на сервер, то нужно усилять сервер а не сайт рубать, хотя одно другому не мешает.

И как много комментариев пишут? Если комментируют в день не более 10% статей, то пересоздания кеша будет нормальным выходом из ситуации

Comments

[PlatinumArcade]

Сервер вроде успешно справлялся, top показывал среднюю нагрузку <1. Но совсем недавно на сайте случилась DDoS атака и серв успешно лёг. Атака продолжается до сих пор. Суппорт сказал переходить на статику, должно стать легче. Теперь вот пока кэш не сделаю, сайт не включат.

[r0ster]

Мб сменить хостера? Или попросить чтобы защитил от DDoS'а… Есть же средства для этого.

Answer 7

[Renat Ibragimov]

Писать кэш в доступную из веба папку /cache/1500.html
А при запросе, через mod_rewrite проверять сперва нет ли такого файла, отдавать, а если нет то редирект на index.php?id=1500

Answer 8

[Евгений Безымянников]

сделайте «прослойку» из nginx + memcache
nginx настроить получать страницы из мемкэша по url
если такой страницы нет, то делать запрос «бэку», он будет формировать страницу, отдавать её + пихать в мемкэш
в гиг памяти влезет скорее всего весь сайт.

второй вариант чуть проще: связка nginx + varnish +apache. На апач ставить mod_evasive.
ну и настройки подобрать, вроде keepalive = 0.

Answer 9

[Александр]

1) 30-40К это не такая уж и большая посещаемость, у меня сервак выдерживал 65К
используй мемкеш однозначно, в нем, например, можно хранить не только контент, но и информацию об обновление и лишний раз трогать БД

( Статистика количества просмотров новости. При каждом посещении продолжать делать «UPDATE `views` = `views` + 1»).

эту инфу я бы точно держал в памяти. У меня в одном муз проекте вся статистика скачиваний за день (200-250К) хранится в мемкеше. А раньше дергалась БД (именно на UPDATE x=x+1) и сервак не слабо тормозил.

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

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

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