PHP - how to make an intelligent cache?

Question

PHP

Task
There is a website - a news feed. Engine - self-written, PHP + MySQL. At the moment, with each visit to the page, information is generated from the database.
We urgently need to move from dynamics to statics.
The way I came up with it

• When you visit the page with id=1500 for the first time, the content is taken from the database and written to the cache/1500.html file. Done with ob_start().
  
• When visiting this page again, we look at the creation date of the 1500.html file, if the date is less than 15 minutes from the current date. time, including output 1500.html. If more than 15 minutes, we take it from the database again and overwrite the file.
  

Questions
1. Comments on the news. It turns out that when adding a new comment, it will be necessary to kill the 1500.html file? The site is alive, there are a lot of comments. I don’t know, I don’t get hard with such requests?
2. Statistics of the number of news views. On every visit keep doing "UPDATE `views` = `views` + 1" or is there some other solution? And then it turns out not to the end the static will turn out if there are constantly requests to the database to fly away.
Please share your thoughts on this implementation. Maybe someone has already implemented something similar, what problems can arise? Maybe there are pitfalls that I'm not aware of yet?

Answer 1

I will write how I did it on one of my sites.
Everything is cached in memcached by keys that are built from the hash of a string with parameters (something like id, page, action, etc.). The page is FULLY cached. Everything is delivered instantly. When a comment is written (and any other page change), the memcached entry is killed and re-created on the next page request. Previously, everything was done in files on disk. The cache size is somewhere around 400-500 mb with on-the-fly compression. Pages have a different lifetime depending on the type of page, all sorts of counters and polls are made dynamically through a subquery. There are absolutely no brakes, everything flies. PS dedicated server, of course.
PS Regarding point 1, you should not worry about hard, if frequent calls to the same thing, most likely everything will be in the disk cache in the RAM. Update statistics and other counters every 5-10 minutes and normal.

Answer 2

You can cache the queries to the database themselves, and analyze: the cache of which queries should be cleared after one or another action.
For example, after adding a new comment, you need to clear the comment counter and the selection of all comments on this article, while the request for the number of article views should not be touched. (rough example).
Some data in the cache will need to be cleared immediately after some event, and some data can be cleared over time (the same counter for the number of article views).
You might think about using tags in the cache instead of just storing by key.
Think about using a caching system: on files, memcache, redis, apc, and so on ... For
something more specific, you need to look at this tape and other implementation features

Answer 3

sysoev.ru/nginx/docs/http/ngx_http_proxy_module.html
Allows you to cache responses from Apache as static for a certain time, depending on the number of page visits, cookies, arguments. When adding a comment, you can simply change the url to &updated=timestamp.
In this case, it is better to transfer statistics to ajax and a separate fast server like node.js, so that it puts it in something like redis. Then it can be transferred to a separate server or turned off at any time.

Answer 4

First, if you are under a DDOS attack, you should deal with the DDOS attack, not the server's capacity. It's pointless to increase power, just to beat off the attack. The attack must be repulsed by specialized means for this. And then you optimize something, the attacker will increase the attack, and a meaningless race will go on.
Analyze the type of attack, analyze its principles, set up filters. Or find a hoster who, as he should be, will do it himself.

Answer 5

1. Nothing will be 100% for Hard, the muscle base is also stored on hard and any movement of the site the system writes a bunch of logs and sessions and other good things, even if no one leaves a comment
2. It is better to transfer statistics to Google Analytics. there it will be much more powerful and there is no load on your server

Answer 6

What caused the transition to static?
If the load is on the server, then you need to strengthen the server and not cut the site, although one does not interfere with the other.
And how many comments are there? If no more than 10% of articles are commented per day, then recreating the cache will be a normal way out of the situation

Answer 7

Write the cache to the /cache/1500.html folder accessible from the web
And when requested, through mod_rewrite, first check if there is such a file, give it, and if not, then redirect to index.php?id=1500

Answer 8

make a “layer” from nginx + memcache
nginx configure to receive pages from the memcache by url
if there is no such page, then make a request to the “back”, it will form the page, give it + shove it into the memcache
in a gig of memory, most likely the entire site will fit.
the second option is a bit simpler: nginx + varnish + apache bundle. Install mod_evasive on apache.
well, pick up the settings, like keepalive = 0.

Answer 9

1) 30-40K is not such a big attendance, my server withstood 65K
, use memcash unambiguously, for example, you can store not only content, but also information about the update and once again touch the database

(Statistics of the number of news views. On each visit, continue to do "UPDATE `views` = `views` + 1").

I would definitely keep this information in mind. In one music project I have all download statistics per day (200-250K) stored in memcache. And before, the database was twitching (it was on UPDATE x=x+1) and the server was not weakly slowing down.
2) as already advised above - if you store content in a memcache, then you can configure nginx so that it gives it directly without pulling the backend
3) if there is an Apache - then use php-fpm, well, I hope that all sorts of accelerators are also used.
there are a lot of articles on Habré on how to improve performance