PHP and Web. Caching

The introduction.

For optimization of job with a network the mechanism of preservation once received on HTTP documents in keshe is used with the purpose of their reuse without the reference{manipulation} to a server - source. The document saved in keshe will be accessible at the following reference{manipulation} to it , without a unloading from a server - source that is called to raise{increase} speed of access of the client to it  and to reduce the charge of the traffic of a network.

Caches I am two kinds - local and the general{common}. Local it kesh, stored{kept} directly on a disk at the client, created and controlled by his  browser. The general{common} - the cache of a proxy of the organization or the provider also can consist of one or several proxies. Local kesh is present, probably at each browser, the significant part of people using Internet uses the general{common}. And if a small part of sites now estimate under the charge of the traffic, speed of loading - the important criterion which should be taken into account by development of your web-project.

To the dynamic pages created as a result of job of the PHP-program, apparently, caching harmful. The maintenance{contents} of page are formed on search of the user on the basis of any source of the data. However, caching can be useful. Operating you can make him  job with your server more comfortably for the user, allowing{resolving} loading of a cache of the certain pages, preventing thus their repeated unloading from your server and saving the user time and the traffic.

Kehshirovat` whether or not?

The opportunity of preservation in a cache of page is defined{determined} by dynamism of the information in a source of the data. Thus necessity of use of a cache is defined{determined} by you, proceeding from planned time of a life of page.

If the question is formation of sample on base (for example, search of the word entered by the user) such page necessarily it is necessary to request from the server by each call without use a cache as quantity{amount} of variants of required words hugely and if we besides deal with the varying data file caching is senseless. Or the question is formation we admit{allow} the schedule of coming visitors (which changes with each visit, that is practically with each call) keshirovanie already simply harmful.

However, if we speak about the same schedule but for a yesterday caching is recommended as given to change any more there will be no also we we can save to ourselves both the user resources and time for loading of such pages by their premise{room} in a local or general{common} cache. As continuation of this situation formation of the schedule not in real time, and hourly. Here you can predict a date closed of "working life" of the generated data beforehand.

The general{common} principles of preservation of pages in a cache.

The PHP-program can operate caching of results of its{her} job forming additional fields in heading HTTP of the answer a call of function Header ().

Some the general{common} statements characteristic not only for PHP-programs:

?         Pages transmitted on POST are never saved in a cache.

?         Pages required on GET and containing parameters (in URL is present '? ') are not saved in a cache if not the opposite is specified.

Thus in the majority of situations of additional instructions in the program to add it is not necessary. The basic moments on which it is necessary to pay attention it is possible to reduce to two:

?         An interdiction of caching of documents, kehshiruemykh by default

?         Caching the documents which are not subject to caching by default.

Interdiction of caching of documents, kehshiruemykh by default

This problem  arises for PHP-scripts caused without parameters or being indexes of the directories however forming the data personally under the user (for example on a basis cookies or user agent) or quickly changing data working on a basis. Under specification HTTP/1.1 we can operate the following fields:

?         Expires - Sets an expiration date of the validity of the document. Its{her} task in the past defines{determines} an interdiction a cache for the given page.

?         Cache-control: no-cache - Management a cache. Value no-cache defines{determines} an interdiction a cache of the given page. For the version of report HTTP/1.0 operates « Pragma: no-cache ».

?         Last-Modified - Date of last change of contents. The field is actual only for static pages. Apache replaces this field with value of field Date for dynamically generated pages, including for pages containing SSI.

On a site the following code for an interdiction keshirovanija www.php.net is given.

header (" Expires: Mon, 26 Jul 1997 05:00:00 GMT "); // Date in the past

header (" Last-Modified: ". gmdate (" D, d M Y H:i:s "). "GMT"); // always modified

header (" Cache-Control: no-cache, must-revalidate "); // HTTP/1.1

header (" Pragma: no-cache "); // HTTP/1.0

However, I think, that the given heading is superfluous. In most cases it is enough:

header (" Expires: Thu, 01 Jan 1970 00:00:01 GMT ");

To mark the document as "already out-of-date" it is necessary to establish Expires equal to field Date.

header (" Expires: ". gmdate (" D, d M Y H:i:s "). "GMT");

Well also it is not necessary to forget, that the forms requested on POST also are not subject to caching.

Caching of the documents which are not subject to caching by default

The return problem , can seem at first sight absurd. However and in it there is a need{requirement}. Except for simple minimization of the traffic by development of the web-program it is necessary to take into account comfort of job with her the user. For example, some pages of your server are formed on the basis of the static data of great volume. The opportunity of their inclusion in a cache will essentially improve speed of job of the server for the user and in part will release{exempt} yours from numerous repeated generacij such page. Heading allowing{resolving} preservation on proxies:

header (" Cache-control: public ");

If the page takes into account the information saved in a browser of the user (type and the version of a browser, keys, authorization, etc.) cannot be saved such page on a proxy, its{her} preservation in local a cache of a browser however is possible:

header (" Cache-control: private ");

Caching before the expiration of a correctness

The decisions described above are rather rectilinear, though approach for the majority of problems{tasks}. But report HTTP/1.1 has means for more thin management a cache of pages, and there are problems{tasks} demanding applications of these mechanisms. As an example - web-applications working with the data of great volume and predicted dynamism. The correctness of the data can be established both by date of predicted updating, and on change of the maintenance{contents}. For these cases different headings of management a cache are used.

Caching with predicted updating

Let's consider an example - a price a sheet updated on Mondays. You beforehand know, that the maintenance{contents} of page can be stored{kept} in a cache before new week, as it is necessary to specify in heading of the answer providing the necessary behaviour of page in a cache.

The primary goal - to receive date of the next Monday in format RFC-1123

$dt_tmp=getdate (date ("U"));

header (" Expires: ". gmdate (" D, d M Y H:i:s ",

date ("U") - (86400 * ($ dt_tmp ["wday"]-8))). "GMT");

header (" Cache-control: public ");

This method can be operated effectively behaviour of page in a cache and premenim but for the big number of pages - anyhow it is possible to allocate time intervals during which maintenance{contents} of page remains to constants. The real state of affairs is those, that pages of the majority of dynamic sites have certain time of a life proceeding from which developer can make the server more pleasant for job.

Other approach used at more operative updating of the information and simultaneous high attendance of the server (differently caching will not be effective) will consist in use of heading Cache-control: max-age=sekundy, determining after which the document is considered time out-of-date and a having greater priority at calculation of "freshness" of the document.

If you publish news with an interval 30 minutes:

header (" Cache-control: public ");

header (" Cache-control: max-age=1800 ");

Caching under the maintenance{contents}

Even more intellectual kind of management gives HTTP/1.1 on the basis of contents with the help of Vary directives. I very much recommend to apply it  at formation of images or texts of great volume which as are shown with practice change extremely seldom. Thus the user in case of return will not have their repeated unloading if the maintenance{contents} remained former, and the page will be taken from your server if its{her} maintenance{contents} has changed.

Let's consider an example of delivery of the image from a database indentificiruemykh on ID. The call of page looks as follows:

http: // www.your.server/viewpic.php3? id=23123

So by rules the page will not be saved in a cache (there are parameters), but through heading it is possible to operate it.

<? php

mysql_connect ("host", "user", "passwd");

$image=mysql ("db", " select pics, type from pictures where id = $ id ");

Header (" Cache-Control: public, must-revalidate ");

Header (" Vary: Content-ID ");

Header (" Content-ID: " .md5 (mysql_result ($image, 0, "pics")));

Header (" Content-type: " .mysql_result ($image, 0, "type"));

echo mysql_result ($image, 0, "pics");

mysql_freeResult ($image);

mysql_close ();

?>

For management the sum of contents of the image is used MD5. While the maintenance{contents} has not changed, the sum will be postojanoj. In case of change of the maintenance{contents} in base on the server the client will execute search for repeated formation of the maintenance{contents}. While the image contents will be constantly displayed from a cache.

Notes for Russian Apache

And pleasant (or unpleasant) the message for users Russian Apache. As the server he gives out olden time under the user coding automatically supplies ALL pages (not only dynamic) with headings of an interdiction of caching.

Expires: Thu, 01 Jan 1970 00:00:01 GMT

So all pages not kehshiruemye. Formation in a script of heading Expires of effect has no. What for it is made also some methods of struggle are described on apache.lexa.ru and there is no necessity to reproduce this advice{councils} here. Considering{examining} job PHP+Russian Apache here is how it is possible to affect on kehshiruemost`.

For scripts deducing{removing} images the situation simple - Russian Apache will not recode (so not ustanavlivaetsrok the expiration of the validity) documents having MIME type image/*. For use the cache of text documents probably should be used « Cache-control: private, max-age = » for the sanction of caching of pages in a browser. Though this theoretical assumption which has been not checked up in practice.