Сведения о вопросе

Fhohir

20:35, 1st October, 2020

Теги

PHP    

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

Просмотров: 325   Ответов: 9

Задача

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


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

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


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

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


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



  Сведения об ответе

padenie

04:58, 29th September, 2020

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

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


  Сведения об ответе

prince

03:36, 29th September, 2020

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

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

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

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

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


  Сведения об ответе

SEEYOU

19:15, 28th September, 2020

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


  Сведения об ответе

SILA

13:18, 30th September, 2020

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

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


  Сведения об ответе

JUST___

14:23, 26th September, 2020

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


  Сведения об ответе

Chhiki

12:24, 27th September, 2020

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

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


  Сведения об ответе

SSESION

11:02, 29th September, 2020

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


  Сведения об ответе

lool

19:08, 25th September, 2020

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

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


  Сведения об ответе

$DOLLAR

03:59, 30th September, 2020

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

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

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

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


Ответить на вопрос

Чтобы ответить на вопрос вам нужно войти в систему или зарегистрироваться