0% found this document useful (0 votes)
41 views6 pages

Caching

cachec

Uploaded by

ArunGooGle
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
41 views6 pages

Caching

cachec

Uploaded by

ArunGooGle
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

Page caching:

If enables, page caching will only be used for anonymous users.


If you enable page caching, the entire HTML of each page will be stored in the
database. This significantly reduces the amount of queries needed.
This automatically means that blocks will also get cached, disregarded their own
cache settings.
If Varnish is configured, this will also enable varnish caching
The page cache max-age will be used (see below) for each page.
You can check the "X-Drupal-Cache" HTTP header to check if this cache is HIT.
Block caching:
If you enable block caching, without enabling page caching, the block cache
settings will be used (for anonymous and authenticated).
The defaults for most blocks is "don't cache" because that is the default for
blocks who don't have their cache settings specifically declared.
You can use block_cache_alter module to set this for each block.
When it's block created by Views, you can set the cache settings for a block in
Views.
Minimum cache lifetime:
This is the amount of time before the page cache is cleared.
Page caches are cleared on each cron run (system_cron).
Be warned: incorrect settings of your cron and this setting might kill your website
performance. See also this issue.
Expiration of cached pages:
This only applies for external caching mechanisms, for example your browser
cache or Varnish.
It sets the Cache-Control max-age value in the HTTP-HEADERS.
This setting only takes effect when page caching is turned on.
If I'm wrong at any of these points - or am missing something, please let me
know and I will update this page.

Reduce the number of requests to make or the times a calculation is made ia


way to improve the performance of a feature and is necesary.

Different ways to cache


We are going to talk about two different cache techniques that can be used
in Drupal, first the use of static data and then the Drupal Cache.

Scopes

In most web platforms there are different scopes for variables and data beyond
the variable and class scopes. There are normally 4 different
scopes: Request, Session, Application and Server.

Request Scope
The request scope variables are the ones that remain since a client request was
issued until the request ends.

This is the normal level we have in PHP when we use static variables, patterns
like Singleton and any other attempt by code to keep a data alive in memory.

Session variables
In PHP you can save data on the users session variable and these data are only
for that user in that session and they will remain alive during the complete time
of that session.
This is very handy to keep user information that may be required to keep
continuty to the users experience in the site.

Server variables

PHP is not able to keep data at server level by default like other platforms can,
but that doesnt means it cant be achieved.
In PHP you can emulate server variables saving data in the database (that works
only for that server), saving the data in files or using memory dictionaries like
Redit, APC, Memcache or alike (if they are restricted to that server only).
The server variables are identified because they only belong to the server that is
running on, not necesary exclusive of the application, for which it could be used
to share data between applications on the same server.
The data use to be volatil by definition and therefore is lost when the server is
restarted.

Application variables
These are very similar to server variables and they are not supported by PHP by
default either, but they can be implemented in the same way that server
variables are.
The conceptual difference of these variables is that they are not shared between
applications, but on the other side they are shared between servers that are
running the same application.

Why do I need to make cache of data?

Each time we do a data request or some data calculations that require resources.
The requests to a database require memory, CPU and in most cases disk
operations as well.
The processing of files or complex calculus also could have a big weight in
performance.
This may not be a big issue once, but when we are serving a site with high traffic
this could impact the servers performance and the response time.
Reducing the number of requests and/or calculus that are made we multiply the
improvement in performance and response time.
From there we get that if we coiuld reduce the amout of code files or templates
to 10% on 90% of the requests we could see a drastically improvement of the
site performance, or in its defect, not doing so would mean having the site slow
or not able to server the amount of requests of a decent trafic.
Of course, everything has a cost, keeping more data on cache would usually
means that we need more memory to keep them available, which could be
limited by the servers RAM that we have.
For this reason we must have careful and concience of the resources or we could
start having a problem of availablebily of cache, forcing the server to use swap
memory/virtual memory on disk, making the server go slower and heavier.

Static data
Now that we know the different levels for the variables lets see static data.
Using the functionality static in PHP we can keep data in a persistent way
during the code execution (request variables), allowing us to save on requests or
calculus that are required several times during the code execution of the request.
In Drupal 7 you can use the function drupal_static to keep those data. The

function drupal_static receives the name or key of the data, the default
value and an indication if is must clean the existing data.

In that sense this function can be seeing like a similar functionality of the set
Drupal variable_get/set set of functions.

Use of static data exclusive for a function, in Drupal 7:


<?php
function my_funcion() {
// The function name it is used as the key
$data_list = &drupal_static(__FUNCTION__);

// If the data has not being requested/calculated yet we do it now


if (!isset($data_list) {
// Obtain the data from the database and make calculations
}
// The second time that this function is called the data will be alredy define and they
will not be requested again

// Use $data_list
}
?>

Sharing static data between functions in Drupal 7:


<?php
function one_funcion() {
$data_list = &drupal_static("shared data");
// Use $data_list and modify it in the variable
}

function another_funcion() {
$data_list = &drupal_static("shared data");
// Use $data_list and modify it in the variable
}

?>

Use of static data exclusive for a function, in Drupal 6:


<?php
function my_funcion() {
static $data_list;

// If the data has not being defined yet then we defined


if (!isset($data_list) {
// Obtain and calculate data
}
// The second time that the function is called the data will be defined and no need to
get them or calculate them again

// Use the data form $data_list and save modifications to the variable
}
?>

Sharing static data between functions in Drupal 6:


In Drupal 6 we need to do some adjustments because the static function only
applies to the function (or class) where is defined and cant be shared.
To achieve this we have 2 options, use a global variable or create another
function as static container from which we obtain the reference to the static
variable.
<?php
function one_funcion() {
global $data_list
// Use $data_list and modify it in the variable
}

function another_funcion() {
global $data_list
// Use $data_list and modify it in the variable
}

?>

Drupals Cache

Drupal has a series of functions to use the generic cache system that is
implemented.
By default Drupals cache is implemented in the database, but this can be
modified so that it uses another implementation like APC, Memcache, Redit, file
system, etc.
In a future article Ill explain how to configure different type of cache in Drupal.
The advantage of Drupal cache is that the code is agnostic of the
implementation of the cache, when you program the code you dont need to
know which kind of cache are you using.
If we need to do a series of heavy calculations over some data and these data
will stay constant in the site for certain time, we can do something like the
following example to avoid calculating it on every request:
<?php
function calculate_heavy_data() {
$data_calculated = drupal_static(__FUNCTION__); // Drupal 7 version
//static $data_calculated; // Drupal 6 version

if (!isset($data_calculated)) {
if ($cache = cache_get("heavy_data")) {
$data_calculated = $cache->data;
} else {
// Do all the necesary calculations of the data and place them
again in $data_calculated
cache_set("heavy_data", $data_calculated, "cache");
}
}
return $data_calculated;
}
?>

This way the data will not be calculated on each request nor serveral times on
one request.
The use of cache is recommended, but without abuse and having in mind
estimations of how this can impact the memory and improvement on
performance, but this could be the difference between a heavy and slow site or a
fast and fully available site.

You might also like