Drupal Performance Tuning

May, 2010

Germán Villacreces
Performance Tuning Drupal
Table of C ontents
Introduction 3
Tes t environment 4
The Tes t S ite 4
The Virtual S erver 5
Tes ting tools 5
S ingle P age Load Tes ting Tools 5
Load Tes ting Tools 6
E valuating the current performanc e 7
S ingle P age Load R es ults 7
Load Tes ting R es ults 12
Optimizing Drupal 12
Front-end Optimization 12
Us e a C DN 13
Make Fewer R eques ts 13
Add E xpires Headers 13
C onfigure E ntity Tags (E -Tags ) 14
Us e C ookie-Free Domains 14
B ack-end Optimization 15
P age & B lock C aching 15
B oos t 15
Optimizing your s erver 16
Tuning Apache 17
Tuning MyS QL 17
Tuning P HP 19
AP C 19
Memcac he 21
E valuating the performance after optimization 22
S ingle P age Load R es ults 22
Load Tes t R es ults 24
C onclus ion 25
Drupal S ucc es s S tory 26
Additional Drupal R es ourc es from Os hyn 28
About G erman Villacreces 29
About Os hyn 29
 Introduction

This paper evaluates the performanc e of a s mall s ite built with Drupal on a
s tandard virtual s erver running Ubuntu S erver E dition 9. 10. T he evaluation will
focus on the res ults of tes ting the res pons e time and amount of reques ts per
s econd (R P S ) that the s erver c an hold before the average load time is
unac ceptable. The firs t evaluation will be done with the default c onfiguration of
Drupal and the s erver. The s econd evaluation will take plac e after optimizing
both. The res ults from the evaluations will be compared to get to a good idea
of how fas t c an Drupal run on a virtual s erver with the minimum s pecs . K eep in
mind that this public ation is to evaluate the performanc e of Drupal for s mall
s ites with low traffic. T he s erver will have the minimum s pecs . After reading
this paper, you will know whether a s imple virtual s erver is more than enough
for a low traffic s mall webs ite and you will learn how much the performance of
Drupal can be improved by jus t tuning the s ettings and the s erver.
 Tes t environment
The Tes t S ite
The s ite us ed for this benchmark was built with the lates t Drupal 6 releas e at
the time of this writing (Drupal 6. 16). The s ite makes us e of the following
modules in addition to the required core modules :

Administration menu Token and token actions ImageAPI with GD2

Views and ViewsUI Database logging ImageCache & ImageCacheUI
CCK and all Submodules Help CKEditor
FileField, ImageField Locale FlashNode
Panels (CTools, MiniPanels Menu Global redirect
and PanelNodes) Path Pathauto
Blog PHP Filter PDF version
Color Search Printer-friendly pages
Comment Taxonomy Send by e-mail
Contact Update status SWFTools and SWFObject
Content Translation Upload Google Analytics

The s ite was built us ing the features from all the above modules . The
homepage will be the target for all the tes ting. This is what it looks like:

This page is built with the P anels module, 5 different views are us ed.
The page has numerous elements :
1 HTML page reques t (4. 5 kb)
1 XML as ynchronous page reques t (510 b)
16 s tyles heet reques ts (10. 9 kb)
5 J avaS c ript reques ts (29. 6 kb)
9 image reques ts (102. 5 kb)
1 intial Flas h reques t (45 kb)
4 additional fFas h reques ts (712. 6 kb)
Lazy loading is us ed for the Flas h additional reques ts and the XML s o the total
initial page reques t s ize is 19 0. 6 kb and the additional reques t s ize is 713. 1
kb
The average total page s ize ac cording to a res earch made is 130kb. S o the
homepage is a little over the above bec aus e of the main Flas h element. We
s hould keep that in mind.

The Virtual S erver

The virtual s erver us ed has the following s pecs :
Intel C ore 2 Duo 2. 0 G hz 64-bit architec ture
70G B dis k s pac e
2G B R am
The virtual s erver runs under VMware E S X 3i, 3. 5. 0
The OS ins talled is Ubuntu S erver E dition 9. 10 64-bit.

The web s erver L AMP s tack vers ions are:

Apache 2. 2. 12
P HP 5. 2. 10
MyS QL 5. 1. 37 ins talled
Apache and P H P configurations are s et with Drupal' s requirements :
 Apache mod_rewrite extens ion enabled
 P HP G D library extens ion enabled
 P HP R egis ter G lobals variable is s et to off.
 Memory limit is s et to 96Mb bec aus e this is the minimum rec ommended
library when us ing the ImageC ache module.

Tes ting tools

When tes ting the performance of a s ite, we as k ours elves , how we s hould
meas ure this ? T he res pons e time when loading a page? The volume of us ers
that c an ac ces s the s ite at the s ame time without the s erver c ras hing? T he
ans wer is both.
Our approach will evaluate the performance of a Drupal s ite in a virtual s erver
by meas uring the res pons e time of the homepage and the number of reques ts
per s econd the s erver c an take without c ras hing or c aus ing reques t queues .

S ingle P age Load Testing Tools

We need to meas ure how long it takes to load all the page elements that form
the homepage. This inc ludes the HT ML, J avaS cript files , C S S files , images
and Flas h files . T here are great meas uring tools that let you know how fas t or
s low your page is loading.
The firs t tool we are going to us e is very popular, it’ s c alled YS low. Y S low is a
Firebug extens ion which is a Firefox plugin. YS low grades your s ite' s load time
us ing s everal c riteria. T o improve your overall res ult you mus t get a better
grade on each criteria.
The s econd meas urement tool we are going to us e is an online web page tes t
tool. The s ite webpagetes t. org c onduc ts a tes t to the s ite you want from the
different loc ations in the world and returns s everal res ults , including a
"waterfall" view of the page load. T he total page load time and a grade are the
two main values we are interes ted in.

Load Tes ting Tools

The load tes ting tools are needed to meas ure the amount of traffic that your
s erver can take before us er reques ts are queued or the s erver cras hes . This
tas k is not c omplic ated; we c an us e Apache' s jMeter to run the tes ts .
The load tes ting will be executed with different R P S values each time while
monitoring the s erver' s health. The R P S value will increas e until the s erver' s
res pons e time is not acc eptable. B efore beginning to tes t, we need to define
the maximum waiting time we are to ac cept before cons idering that the s erver
cannot take any more load. This can be very complicated to ans wer if we try
to generalize a univers al acc eptanc e res pons e time. This is bec aus e this value
is different for people depending on the content they are waiting to s ee. To
keep things s imple for thes e tes ts , we are going to s tick to the traditional 8-
s econd rule. As s oon as we have an average res pons e time above 8 s econds ,
we will conc lude that the s erver c an’ t take any more reques ts .
It is important to point out that the tes ts are made from average 0. 62 Mb/s
connections . T his is under the average IS P s peed in the US but can be
cons idered as an average worldwide ac cording to this global report from mos t
popular s peed tes ts s ites s peedtes t. net.
 E valuating the current performance
S o far, we have not changed anything in the Drupal s ite to optimize it. We are
s tarting with 1G B of R AM in the s erver and evaluating all the res ults .

S ingle P age Load R esults

The next figure dis plays the detailed grading provided by Y S low:
T he overall grade is D, this is pretty bad but we c an' t really as k for more
cons idering that none of the Drupal optimization features are enabled. Thanks
to this tool we know what we c an do to get a better grade and feel confident
that our s ite is optimized as
much as pos s ible in the
front-end.
YS low als o dis plays that the
page load time was :
onload: 2. 88s
total load: 10. 32s
This means that the page
took 2. 88 s econds to
initially load but the total
page res pons e that inc ludes
the 4 additional Flas h
objec ts and the XML file
that are loaded
as ynchronous ly took 10. 32
s econds to load. T his
s econd number may s eem
high, but you need to
unders tand that it’ s
bec aus e of the Flas h and
XML files that s um up to a
total load weight of 713. 1
kb.
Now, we can’ t really judge
by making a s ingle page
load, s o we will try this 20
times to obtain average
values .
 Here are the res ults ; the graph for thes e res ults is dis played below:

Num Initial Load Total Load

1 2.88 10.32
2 3.72 10.32
3 3.27 11.42
4 4.24 11.75
5 4.88 10.54
6 3.307 10.3
7 5.195 10.31
8 2.141 10.26
9 7.387 10.12
10 3.67 10.17
11 3.87 11.36
12 3.49 10.9
13 3.29 10.26
14 3.913 10.41
15 2.818 10.41
16 2.627 10.29
17 2.333 10.68
18 4.261 10.24
19 3.347 10.62
20 4.953 10.26
Average 3.7796 10.547
 12

10

8
Seconds

6
4
Initial Load
Total Load 2
0
1 2 3 4
5 6 7 8
9 10 11 Initial Load
12 13 14 15
16 17 18
19 20

Number of Request

The average initial load takes 3. 78 s econds ; the average total load takes 10. 55
s econds . The initial load is within the ac ceptanc e limits , but we can improve
this and we als o want to get a good grade to leave the s ite as optimized as
pos s ible in the front- end.
The meas urements dis played by Y S low are pretty good, but you are probably
thinking that they c an' t really be cons idered as clos e to reality as pos s ible
bec aus e we are trying from a s ingle loc ation. This is why we are going to us e
the s econd tool we talked about before, webpagetes t. org. Us ing this tool will
give us more ac curate meas urements bec aus e the tes ts are conducted from
different locations around the world. We will again make an average of all the
res ults , this time cons idering meas urements from different loc ations in the
world:
 Virginia, US A
 C alifornia, US A
 G louc es ter, UK
 J iangs u, C hina
 Wellington

Note: All thes e locations have a 1. 5 Mbps ADS L connection.

Here is a s c reens hot of the res ults from the firs t location (E as t C oas t US A)

As you c an s ee, the average initial load of the page takes 7. 06 s econds ; the
total load time is 15. 207 s econds . This is a little higher than the res ults we
made from
Here are the res ults for all the locations .
 40
35
30
25
Seconds

20
15
Initial Load 10
Total Load 5
Initial Load
0

Location

Jiangsu, China
Virginia, USA

Gloucester,UK

Average (seconds)
Wellington, New
Zealand
California, USA

Initial Load 7.06 6.554 18.308 15.382 21.249 13.7106

Total Load 15.207 6.554 23.109 35.194 21.807 20.3742

The res ults s how that the average initial load value is 1 3. 7 1 s ec onds , and the
average total load is 2 0. 3 7 s ec onds . This is above the ac ceptanc e limit (8s ).
E vidently, we do need to make a few adjus tments to the front- end
optimization.
 Load Tes ting R esults
To tes t the amount of load the s ite c an handle, we mentioned we were going
to us e jMeter. T his is a great tool and it’ s all we need for the purpos es of this
public ation. The res ults after increas ing the amount of R P S are the following:

Average Load Time

16.000
14.000
12.000
10.000
Seconds

8.000
6.000
4.000
Average Load Time 2.000
0.000
10 RPS 20 RPS Average Load Time
30 RPS 40 RPS
50 RPS

Requests per Second

10 RPS 20 RPS 30 RPS 40 RPS 50 RPS

Average Load Time 4.027 6.654 9.943 11.685 15.031

The average load time when making 30 R P S is 9. 943 s econds , this is above
our ac c eptanc e value. W e c an s afely s ay that the virtual machine, with the
current configuration c an only ac cept 20 reques ts per s econd. This value is
low, but do keep in mind the s erver s pec ifications and that no optimization
changes have been done to the s erver or the s ite.

Optimizing Drupal
Front-end Optimization
Let’ s s ee how we c an optimize the s ite to get a better load time. We are going
to bas e our actions on the recommendations that Y S low gives us s o we c an
get a better grade. R emember, our current overall grade is D, s o lets apply all
the recommendations pos s ible and get A' s on all pos s ible c riteria.
 Use a C DN
Integrating a C DN is not s omething we are going to do for now s ince it
requires a cons iderate ec onomic inves tment. It does help front- end
performanc e enormous ly, but in this paper we are going to try to inc reas e the
performanc e of Drupal with what we have at hand.

Make Fewer R equests

In this criterion, our grade is F bec aus e we have too many reques ts . Drupal
can gather all the s tyles heets and J avaS c ript files to two s ingle reques ts . We
do this by login in as the admin, going to S ite C onfiguration > P erforma nc e
and enabling the "O ptimize C S S files " and "O ptimize J avaS c ript files " in the
B andwidth Optimizations fields et.

S ave the form and lets continue.

Add E xpires Headers

Us ing expires headers avoids unneces s ary HTT P reques ts when the us er vis its
the s ite more than onc e by making files cacheable. To add the expire headers
to c acheable files , you need to firs t enable the mod_expires module in Apac he
by unc ommenting the line in the httpd. conf file that looks like this :

#LoadModule expires_module libexec/apache2/mod_expires.so

K eep in mind that the exac t path of this line will vary on the different type of
Linux dis tributions . In mos t c as es , this module will be loaded by default, s o
you will not need to do anything.
In this Ubuntu s erver edition, module enabling is done a little differently; all we
have to do is create a s ymbolic link of /etc /apac he2/mods -
available/expires . load in /etc /apache2/mods - enabled. W e do this running the
following command in the s erver:

sudo ln -s /etc/apache2/mods-available/expires.load
/etc/apache2/mods-enabled/.

The next s tep is to s et the expires value. If you are us ing a Linux dis tribution
other than the one we are us ing here you might have to s et this value by
adding the following line at the end of the httpd. c onf file:

<IfModule expires_module>
ExpiresActive On
ExpiresDefault "access plus 6 months"
</IfModule>

In our dis tribution, ins tead of adding thes e lines to the httpd. conf file, we add
thos e likes to an empty file we c reate c alled expires . conf. This file needs to be
place in the /etc/apache2/mods -available directory and we c reate a s ymbolic
link to it on /etc/apac he2/mods -enabled:

sudo ln -s /etc/apache2/mods-available/expires.conf
/etc/apache2/mods-enabled/.

Note: T he directive value "ac ces s plus 6 months " means we s et the expire to
be added to the eac h file s o that it caches the file for the next 6 months s inc e
the firs t time it was acc es s ed.
You c an res tart Apac he to tes t if this works . You s hould now get an A grade
on the E xpires Headers c riteria.

C onfigure E ntity Tags (E -Tags )

E -Tags help the brows er identify files in the cache. When a s ite runs on a
s erver farm, e- tags c an degrade performanc e becaus e the tags c an make two
identic al res ourc es s eem different and therefore s kip caching.
Apache has e-tags enabled by default in mos t vers ions . W e are going to
dis able them bec aus e they don' t really help that much and this way we' ll
reduc e overhead on the res pons e. To dis able the e-tags you will need to
include two directives wherever your s ite folder <Directory> group is . This
group c an be in your httpd. c onf file or ins ide your <VirtualH os t> definition.
Thes e are the two lines you need to add to dis able entity tags .
H eader uns et E T ag
FileE T ag N one

Use C ookie-Free Domains

When the brows er makes reques ts to the web s erver, it s ends cookie data on
the header. On s tatic files like images , s tyles heets , J avaS cript files and s wf
files , the c ookie data is not needed s o thes e files s hould be placed on a
s eparate cookie-free domain. This way we reduce the overhead on s tatic files .
The firs t s tep is to c reate a domain that points to the s ame s erver. You c an
us e a domain like www. s tatic-yours ite. com. Once your domain is ready you
can tes t it by opening it in the brows er and you s hould be able to view your
s ite.
The s ec ond s tep here is to create another virtual hos t on Apac he. W e are not
going to get into any details of how to do this , but you c an follow this
(http: //httpd. apac he. org/docs /2. 0/vhos ts /examples . HTML) or any tutorial
online. Make s ure you us e the <Directory> group while c reating your new
virtual hos t. The s erver name and s erver alias s hould be the domain name you
created in the firs t s tep and you s hould inc lude in the virtual hos t <Direc tory>
direc tive group the following lines that dis abled the cookies :

RequestHeader unset Cookie

Header unset Set-Cookie

The third and final s tep is to make Drupal point all s tatic files to your s eparate
domain. We do this by ins talling the C DN Integration module
(http: //drupal. c om/projec t/cdn) which is us ed to pull s tatic c ontent from
another domain or s ubdomain. Ins tall the module, go to the bas ic mode
s ettings in S ite C onfiguration > C DN Integration > B as ic mode. In this s c reen
input your s tatic domain to the one you jus t created in this s ection' s firs t s tep.
In our c as e, the value we input is http://os hyn-s tatic.com. S ave the form, go to
the tab called S ettings and click on the E nable radio button under S tatus .
S ave the form and flus h your s ite' s cache.
We have made all the adjus tments in the front-end, we will evaluate the res ults
later on after c ompleting all optimizations .

B ac k-end Optimization
There are many ways we c an improve the performanc e of Drupal without
touching the s erver yet. The native optimization features help a great deal
s inc e they are c ac hing s ys tems within the core Drupal code.

P age & B loc k C aching

B y enabling page caching Drupal does not build a page eac h time an
anonymous us er vis its , this will have a s ignific ant boos t.
The s ame way Drupal can c ac he pages , it can c ac he blocks . This way all
blocks wont have to be recons truc ted on each page load.
Login to your admin ac count, go to S ite C onfiguration > P erformance. In the
P age C ac hing fields et, enable C ac hing mode to Normal and als o enable P age
C ompres s ion. Finally, enable B lock cache too.
You might notic e there is another property we c an s et, Minimum C ache
Lifetime. This is bes t left alone in this cas e; it’ s us eful when your s ite gets a big
amount of traffic and content updates don' t need to be "live" and c an wait an
hour, two hours , or even a day.

B oos t
This is a very helpful module for s ites that have mos tly anonymous traffic. It
caches all s tatic pages . This way when anonymous us ers open a content
page, Drupal does n’ t have to pull data from the databas e to render the page,
it literally turns a Drupal page to a s tatic HT ML file. Download
(http: //drupal. org/project/boos t) and ins tall this module on your s ite, and we
need to configure it.
To configure B oos t properly and quickly, go to the admin/reports /s tatus page
in your s ite and you will s ee all the things that need to be done to make this
module work. Firs t we need to prevent web c rawlers from indexing the output
of the module in c ertain files . S o we add the following line at the end of the
robots . txt file, located in the root folder of your s ite:

Disallow: /boost_stats.php

Next we need to c reate the following nes ted folders in your root folder:
cache/perm/[yours ite.c om]
And give them writing acc es s to Apac he, run the "chmod" command from the
root folder.

chmod -R 777 cache

There is an additional s tep we' ll need to do but we can' t yet. W e' ll do it when
we tune Apache in the next s ec tion, s o remember that. For now if you get a
"file_get_contents . . " warning in the admin s ec tion, then jus t go to S ite S ettings
> P erformanc e > B oos t S ettings and at the bottom of the form, find the Ignore
.htac ces s warning c heckbox, s elec ted and s ave the form. We don’ t need to
change anything els e here now. We can move on to our las t s tep of B oos t
configuration, c ron.
S etting up cron is really eas y, we log in to the s erver us ing the admin ac count
(not root). And we edit c rontab with the following command:

sudo crontab -e

We then add the following new line:

0 * * * * wget -O - -q -t 1 http://yoursite.com/cron.php

What we are doing here is telling cron to exec ute a command every hour,
thats all we need in our c as e. The c ommand is to make an http reques t to the
cron. php file in our s ite. You will need of c ours e to replac e the yours ite. com
value for your real domain. For additional help on s etting up c ron, go to
http: //drupal. org/cron.
R emember, the las t s tep to make B oos t work is done in the Apache tuning
s ec tion.

Optimizing your s erver

S o far we have done a lot of tuning, we made all pos s ible optimizations in the
front-end s ide, we have tuned Drupal enabling all its default caching options
and we have ins talled the B oos t module. All thes e changes have been done to
Drupal, now let' s optimize our s erver c onfiguration.
 Tuning Apache
As you know, we have already done s ome tuning in Apac he, we have s etup
the expire headers , dis abled the entity tags and configured a c ookie-free
domain. T he only optimization left to do is to move all the rewriting rules from
your . htacc es s file to your Apac he configuration file. We do this s o we c an tell
Apache not to look for . htacc es s files on all folders and get a s mall
performanc e improvement, everything c ounts right? T o do this you can jus t
pas te the following c ode in your <Direc tory> directive within your hos t on top
of the entity tag direc tives placed before.

AllowOverride None
Order allow,deny
allow from all
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]

This code is the exis ting code in the . htacc es s file. The directive AllowOverride
None tells Apache not to look for the . htac ces s files . Now, here is when we
add the mis s ing piece from the B oos t module. Login as the admin in your s ite
and go to S ite configuration > P erformance > B oos t htacc es s rule generation.
C opy that c ode and pas te it under the rewrite rules you jus t added to your
<Directory> direc tive. S ave the file, res tart Apac he and tes t your s ite s o that
friendly urls are s till working. Als o, check the cac he/perm/[yours ite. com] folder
you c reated for B oos t before, if there are files there it means boos t is working
fine. If not, s omething is wrong, go back to make s ure all s teps were
completed, us e the doc umentation that B oos t provides in their projec t page
(http: //drupal. org/project/boos t).
This is all we need to do for Apache.

Tuning MyS QL
MyS QL is probably one of the mos t complic ated components to tune. T he
reas on for this is bec aus e the optimal configuration is different depending on
the s ite you have. In our cas e, our traffic is mos tly anonymous , and us ers do
more reads from the databas e than writes . To optimize our s ite we c an do
three things :
1. Hardware upgrade
2. Tune the mys ql s ettings
3. Optimize your queries
In our c as e, hardwa re upgrade is not an option as we are trying to keep this
performanc e with minimum expens es . T here are a few s ettings we c a n
c hange to inc reas e the performa nc e of M yS Q L for our s ite, s ince we have a
lot of reads , its good to have a good amount of query c ache s ize. G o to the
MyS QL s ettings file c alled my. cnf. It is us ually located in /etc/my. c nf or
/etc/mys ql/my. cnf. Y ou c an type the following command anywhere to find the
loc ation of yours :

locate my.cnf

E dit the file with s udo us ing any editor, find the query_cac he_s ize and change
it to 32M, it s hould look like this :

query_cache_size = 32M

This value s hould be c hanged depending on the traffic on your s ite, you c an
s ee if the value you input is the bes t by monitoring the query c ache, you do
this in the MyS Ql cons ole. L ogin as the root us er in the MyS QL cons ole and
type:

mysql>SHOW STATUS LIKE 'qcache%';

You c an monitor thes e values while tes ting your s ite, to s ee how MyS QL
res ponds .
The s econd c hange we need to make helps limit the s erver res ources us e in
the MyS QL proc es s . We unc omment and c hange the following line in the
my. c nf file:

max-connections=500

This s ets the maximum number of allowed connections , its default value is
100, while tes ting your s erver, if you find that MyS QL does not take a lot of
your memory up and C P U, you c an inc reas e this value to allow more
connections at the s ame time. B e careful though, if you allow too many
connections MyS QL may take all of your s erver res ourc es and eventually
cras h. We s et this value to 500 to s ee how it works .
You c an s ee the maximum number of connec tions your databas e has handled
us ing the following MyS QL command:

mysql>SHOW STATUS LIKE 'max_used_connections';

The third and final change we are going to make in the MyS QL s ettings is in
the c ac hes . T ables are s tored as files in MyS QL, this means that each table file
needs to be opened for read. MyS QL c an leave thes e files open s o that next
time it reads them it won’ t need to reopen them. MyS QL c an leave a c ertain
number of tables open, we c an s ee if with this value MyS QL has had the need
of reopening tables . G o to the MyS QL cons ole and type:

mysql>SHOW STATUS LIKE 'open%tables';

If the "opened_tables " value is 0, you don’ t need to change anything, if it’ s
more than 0 then you s hould c ons ider increas ing the table_c ache value in
my. c nf, that way MyS QL does n' t s pend muc h time opening table files .
There are many other c hanges you can make to optimize MyS QL even more.
In our cas e we wont make additional changes s ince our s ite won’ t benefit from
all of them. We need to cons ider that with the caching s ettings we have s et in
Drupal and with the B oos t module ins talled, our s ite won’ t need to make as
many databas e reads as before. T he only thing we need to make s ure now is
to c hec k if there are any s low queries running on our s ite. To do this
unc omment the following lines in your my. cnf file:

log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 5
log-queries-not-using-indexes

Make s ure you change the long_query_time to 5, the default is 2.

S ave the file, and res tart MyS QL s o all s ettings take effect:

sudo mysqld restart

While navigating through your s ite, you will need to monitor the mys ql-s low. log
file. To do this run:

tail -f /var/log/mysql/mysql-slow.log

You will then s ee what queries are running s low and you c an optimize them.
Optimizing MyS QL is probably the hardes t s inc e you have to us e trial and error
to get to the bes t s ettings for your s ite and bec aus e there are s o many
s ettings you c an change. T o c hange more advanc ed s ettings pleas e refer to
the following guide http: //www. ibm. com/developerworks /linux/library/l- tune-
lamp-3. HT ML

Tuning P HP
There are two ways to optimize P HP and both work great. One is to ins tall
AP C (Alternative P H P C ac he). This s ys tem c aches the opcode generated
when P H P is interpreted. The s econd way is to ins tall Memcache, this c aching
s ys tem s tores data objec ts in memory, us ually res ults from the databas e.
R eading from memory is much fas ter than reading from dis k s o it’ s a great
way of optimizing the s ite.

AP C
The following ins truc tions explain how to ins tall AP C on the Ubuntu s erver we
have s etup for our s ite. T o get AP C up and running, we need P E C L s o we c an
ins tall AP C from the lates t repos itories .
Ins tall all required libraries from aptitude firs t:
sudo aptitude install php-pear
sudo aptitude install php5-dev
sudo aptitude install apache2-dev

Now we ins tall AP C us ing P E C L:

sudo pecl install apc

Next you need to enable AP C on Apac he:

sudo echo "extension=apc.so" >

/etc/php5/apache2/conf.d/apc.ini

Then jus t res tart Apac he and that’ s it:

sudo /etc/init.d/apache2 restart

To make s ure AP C is working great we can us e the apc. php s c ript that comes
in the package. Download and untar the lates t built. At the moment of this
public ation AP C ' s lates t build is 3. 1. 3:

wget http://pecl.php.net/get/APC-3.1.3p1.tgz
tar xvzf APC-3.1.3p1.tgz

Now we will copy the apc. php file to our s ite folder:

cp APC-3.1.3p1/apc.php /var/www/.

After brows ing through the s ite for the firs t time after AP C is ins talled, the
opcode is being generated and kept on cache. If you s urf through the s ite
again various times the opcode will be already created and the s ite will be
fas ter. Here are the s tats generated by the apc. php s cript:
The green bar dis plays the hits on c ac he.

Memcache
The las t optimization we are going to implement is memc ache, it is a very
s imple c aching s ys tem that us es memory to s tore objec ts . As you may already
know, memory is fas ter to read than hard drive. A s ite will take a lot les s time
to read a databas e res ult cached in memory. To make the bes t us e of
memcache on Drupal, it’ s better to ins tall the memc ache module
(http: //drupal. org/project/memc ac he). Firs t lets ins tall the memc ache binaries
on Ubuntu. Doing this is as eas y as executing the apt and pecl commands :

sudo apt-get install memcached

sudo pecl install Memcache

Als o, we need to enable the memcache extens ion on php:

sudo echo "extension=memcache.so" >

/etc/php5/apache2/conf.d/memcache.ini

Now pleas e follow the ins tallation ins tructions in the memcache module page
provided before to make memcac he work with Drupal. Y ou can s tart from s tep
3.
Once you are done we c an now perform new tes ts to s ee how much the s ite' s
performanc e has improved.
 E valuating the performance after optimization

We have s uc ces s fully completed all the optimizations on our Drupal s ite.
S tarting with the front-end, then to the Drupal back-end and even s erver
tuning. There are more ways to optimize even more a Drupal s ite. On our
cas e, a s mall webs ite with mos tly s tatic content, we have done a lot. Lets
know s ee how helpful this was . Firs t we are going to evaluate the s ingle page
load res ults and then the load tes ting res ults .

S ingle P age Load R esults

G oing back to Y S low, you c an s ee that our new grade is A! The total s core we
got was 92. W e didn’ t get 100 bec aus e we are not us ing a c ontent delivery
network. Like we s aid before, us ing a C DN involves an inves tment, and we are
trying to optimize our s mall s ite without s pending.
The res ults are very good. E verything went well as planned. Next we are going
to look into the webpagetes t. org res ults . W e make the exact s ame tes t from
the different locations .
 Here are the res ults from the webpagetes t. org s ite:

2.5

2
Seconds

1.5

1
Initial Load
0.5
Total Load
Initial Load
0

Location
Jiangsu, China
Virginia, USA

Gloucester,UK

Average (seconds)
Wellington, New
Zealand
California, USA

Initial Load 1.457 0.938 1.168 1.433 1.555 1.3102

Total Load 1.793 1.177 1.778 1.753 2.759 1.852

Looking at thes e res ults , the s ingle page load tes t value demons trates how we
 have s uc c es s fully dec reas ed the average page load time globally. The average
initial load takes 1. 3 1 s ec onds and the total load time takes 1. 8 5 s ec onds .

Load Tes t R esults

The load tes ting is done in the s ame way we did before, s tarting with 10 R P S
until the average res pons e time is not ac c eptable. R emember we are us ing the
s tandard 8 s econds to determine when a page load time is not ac ceptable.

Average Load Time

10.000

8.000
Seconds

6.000

4.000

2.000
Average Load Time
0.000
10 20 Average Load Time
30 40
RPS RPS 50 60
RPS RPS 70 80
RPS RPS
RPS RPS

Requests per Second

10 RPS 20 RPS 30 RPS 40 RPS 50 RPS 60 RPS 70 RPS 80 RPS

Average Load Time 1.217 2.441 3.850 4.933 6.292 7.318 8.649 9.594

The total number of reques ts per s econd that our s erver can take after all the
optimizations is 60 R P S . W ith 70 R P S the average load time is above 8
s econds .
 C onclus ion
We have s uc ces s fully optimized our Drupal s ite, but how helpful were all the
changes we made? W e get the ans wer by looking at the numbers . B efore our
changes , loading our s ite took an average of 1 3. 71 s ec onds from different
parts of the world. After the optimization c hanges , the average load time is
1. 31 s ec onds . We have decreas ed the initial page load time by 9 0% . T he
s erver load could take up to 20 R P S before. Now the s erver c an take 60 R P S ,
whic h means that all the optimizations we did increas ed three times the
amount of load that this virtual s erver can take.
After reviewing the res ults , we can s ee that without adding new hardware, we
can s peed up our s ite and the s erver can proc es s more reques ts per s econd.
B efore expanding on infras truc ture, a s ite s hould be c ompletely optimized. In
s ome cas es , that may be enough to meet the traffic demand.

Have CMS Needs?

Call us at
1 (888) 483-1770 ext 100
or email newbusiness@oshyn.com
to discuss your current CMS
business needs and how
Oshyn can help you achieve them.

“The customized CMS allows us
to constantly deliver great
content that is increasing
registered members.”
Drupal S ucces s S tory
T he C hallenge
Mallika C hopra, the daughter of Deepak C hopra and S al Taylor K ydd a former
Yahoo! exec utive, wanted to launch Intent. com with the aim of it bec oming the
mos t trus ted wellnes s des tination for capturing and s haring people’ s pers onal,
s ocial, s piritual, and environmental intentions .
T he S olution
Armed with an outline of a preliminary vis ual des ign and required functionality,
Intent. com s elec ted Os hyn to des ign and build out the res t of the plan and
execute the launch of the webs ite.
In addition to the c ons umer fac ing webs ite, the bus ines s development team at
Intent als o needed a pre-launch demo of the webs ite to as s is t them in s igning
deals with c ontent s yndic ation partners , s pons ors , and advertis ers . Os hyn
rapidly built a beta vers ion of Intent. c om to give the bus ines s development
team the opportunity to s howc as e the webs ite’ s func tionality from any loc ation
while they purs ued revenue and content opportunities .
C ollaboration was at the heart of the Intent. com webs ite. T herefore, Os hyn
built a webs ite that offered vis itors with many ways to contribute, collaborate,
and c onnect: us er ac counts , s oc ial networking platform, blog, quizzes and
polls , news letters , invitation-only feature, content s yndic ation, podc as t, and
video. Intent. com needed to have the capabilities to handle many regis tered
us er bloggers and gues t bloggers , mos t of whom were not tec hnic ally s avvy.
Intent. com planned to aggregate c ontent from various online s ourc es , and to
s yndicate original c ontent to many other webs ites . Os hyn s elec ted the Drupal
open s ource framework for building a C ontent Management S ys tem (C MS )
that would allow non-technical editors to eas ily manage all content and
s yndication
T he R es ults
The cus tomized C MS allows us to c ons tantly deliver great content that is
increas ing regis tered members .
Os hyn delivered Intent. com, a highly engaging webs ite des igned for s oc ial
networking. S ince the launc h, Intent. com has rapidly expanded its
members hip bas e and has rec eived much public ity. Intent. com has continued
to s ign new content s yndic ation partners , s pons ors , and advertis ers .
Intent. com is well on its way to bec oming the mos t trus ted wellnes s
des tination.

T he T ec hnology
 Drupal C ontent Management S ys tem (C MS )
 P HP 5
 MyS QL 5
 Apache 2. 0
 R ed Hat E nterpris e 4 L inux
 R ic h content s yndic ation model through;
 R S S badges
 AddThis
 S end to a Friend

Now imagine what Os hyn can do for you!

 Additional Drupal R es ources from Os hyn

 Drupal Development at Oshyn

 Drupal Blog
 ICON 4x4 Drupal Case Study
 Drupal Multisite Options white paper
 Drupal Multilingual white paper
 Enterprise Drupal: Social Media, Mobile and Rich
Media
 Drupal Social Media
 About G erman Villacreces
During his 6 years in enterpris e tec hnology, G ermán Villacrec es has performed
work for clients in the E nterpris e C ontent Management, Digital Media,
Automotive, S oc ial Networking and Advertis ement indus tries . H is expertis e
ranges from ric h internet web tec hnologies with particular emphas is in c ontent
management s ys tem implementations . H e has managed s mall teams of
technology profes s ionals to deliver medium- s cale s olutions in today’ s
demanding timelines . G erman has a B achelor’ s Degree in C omputer S cienc e
from University of San Francisco of Quito.

About Os hyn
Os hyn, Inc. is an E nterpris e T echnology Agency that has earned a reputation
for delivering innovative bus ines s s olutions for the web, mobile devices and
enterpris e technology platforms . Headquartered in L os Angeles , Os hyn' s
growing c lient lis t includes B es t B uy/G eek S quad, C oc a-C ola, E lectronic
Arts , E ps on, G raduate P ros pec ts , Fordham Univers ity, J DS Uniphas e, Harbor
C apital, L exus , Mars , Miramax, National E duc ation As s ociation, Oliver W yman,
S apient, S cripps , S outhern C alifornia E dis on and Volks wagen. Os hyn, Inc. is
partnered with the s ome of the mos t res pec ted agencies and tec hnology
providers s uch as 72andS unny, As c entium, C ris pin P orter + B ogus ky, Ogilvy &
Mather, S aatc hi & S aatchi, S pringbox, T he G roop and T eam One. Os hyn, Inc.
partners and maintains c ertific ations with leading technology providers s uc h as
E P iS erver, Micros oft, J ahia, Micros oft, OpenT ext, Oracle and S itecore. For
more information pleas e vis it us at www. os hyn. com. Follow us on T witter
@Os hyn_Inc.