Invalidating cache php
Invalidating cache php - Sex chatting online without registeration nom
The local cache, is a cache on the local disk of the machine running the browser. Be aware that you don't have "exact control" over that cache.Ultimately, the browser decides whether to follow your "suggestions" or not, which means: don't rely on it.
This has changed over the last years, with a multitude of pay-per-use, non-enterprise vendors on the market CDNs became affordable for everybody. The post does not claim to be exhaustive or even completely precise.
Moving the (static) data to Australia with a CDN improves the client's experience. As per their nature, CDNs are also a plain and simple cache; a proxy cache (or edge cache) to be precise.
So, even if the geographic location part is non of your concern, you still should consider using the proxy cache aspect of CDNs to improve the experience of your users.
To make it simple, let's concentrate on # REQUEST GET /HTTP/1.1 Host: RESPONSE HTTP/1.1 200 OK Date: Sun, UTC Server: Apache Last-Modified: Sun, UTC ETag: "8a75d48aaf3e72648a4e3747b713d730" Content-Length: 8 Content-Type: text/plain; charset=UTF-8 the body HTTP/1.1 304 Not Modified Date: Sun, UTC Server: Apache Last-Modified: Sun, UTC ETag: "8a75d48aaf3e72648a4e3747b713d730" Content-Length: 8 Content-Type: text/plain; charset=UTF-8 header in responses to static contents is automatically generated by the web server based on the modified timestamp of the file on the disk.
However a modified date is often useless, because hard to determine, for dynamically generated contents.
Still only one PHP execution, one time database queries, one time rendering. Administrators would probably be most interested in where and how the data is stored and how the data is distributed within the CDN and differentiate by that.
Since this is article is not addressed to administrators but developers let me just say that there are "classic CDNs" and "peer to peer CDNs", the latter being the modern approach.
For a thousand requests/visits: a thousand PHP executions a couple thousand database queries. Sure, you can scale out horizontally, but that would make things a lot more complex, a lot more expensive and there is a much cheaper and far less complex solution: A proxy cache in between allows you to mitigate resource limitations.
Using the above example, with a proxy cache, only the first request would need to execute the PHP script, do the database queries and render the result HTML.
As their name implies, the push CDNs expect you to provide them the content while pull CDNs take care of fetching the content themselves.
This article will primarily address pull CDNs, because they are much simpler to implement and can, in many cases, be integrated transparently before an existing website without much effort. The CDN now accepts any incoming request and either answers it directly from it's cache or delegates it to your web server, caches the response for future requests, and then delivers it to the client.
There will be follow up articles, building on this one, showing how to work with a CDN as caching layer with specific CMS or frameworks.