EVALUATING PERFORMANCE OF DRUPAL

EVALUATING PERFORMANCE OF DRUPAL

VIETNAM NATIONAL UNIVERSITY OF HANOI

STUDENT SCIENTIFIC RESEARCH CONTEST

2012

PROJECT:

EVALUATING PERFORMANCE OF DRUPAL

Hanoi, 2012

2 Main content

In this project, I focus on evaluating performance of the latest Drupal 7 release

at the time of this research (version 7.12 published on February 2nd, 2012) by:

- Compare its performance with the latest release of Joomla at the time of this research (version 2.5.1 published on February 2nd, 2012) – another top open source content management system

- Compare its performance between default configuration and optimized configuration

For each evaluation, a summary report will be given based on the result of testing

3 Research result

- An overview of performance testing for web applications

- An overview of architecture of Drupal content management framework

- An experimental on Drupal performance with the following parts:

o A comparison between Drupal and Joomla performance

o A comparison between Drupal 7.12 default configuration and optimized configuration performance

Table of contents

I INTRODUCTION 5

II PERFORMANCE TESTING FOR WEB APPLICATIONS 7

1 Overview 7

2 Types of performance testing 7

3 Core activities of performance testing 8

III OVERVIEW OF DRUPAL 9

1 What is Drupal 9

2 Technology stack 9

3 Drupal work flow 9

IV PERFORMANCE EVALUATION 11

1 Evaluating default Drupal 7.12 performance, a comparison with Joomla 11

1.1 Identify test environment 11

1.2 Plan and design tests 13

1.3 Execute tests 14

1.4 Analyze test results, report 16

2 Evaluating cache and page compression in Drupal 7.12 performance 17

2.1 Identify test environment 17

2.2 Plan and design tests 18

2.3 Execute tests 19

2.4 Analyze test results, report 20

3 Evaluating front-end bandwidth optimization in Drupal 7.12 performance 22

3.1 Back-end and front-end performance 22

3.2 Make fewer HTTP requests 22

3.3 Identify test environment 23

3.4 Plan and design tests 24

3.5 Execute tests 24

3.6 Analyze test results, report 25

V CONCLUSION 27

VI REFERENCES 28

Table of figure

Figure 1 – Drupal’s technology stack 9

Figure 2 – Drupal’s architecture view 10

Figure 3 – Blank theme website built with Drupal 7.12 11

Figure 4 – Default theme website built with Drupal 7.12 12

Figure 5 – Default theme website built with Joomla 2.5.1 12

Figure 6 – Apache jMeter – HTTP request configuration 14

Figure 7 – Apache jMeter – Thread group configuration 14

Figure 8 – Result for testing Drupal default theme with 10 RPS 15

Figure 9 – Result for testing Drupal default theme with 120 RPS – errors appear 15

Figure 10 – Result of testing average response time with different RPS 16

Figure 11 – Enable cache and Gzip compression in Drupal website 18

Figure 12 – Apache Benchmark result for testing Drupal site non-cached page 19

Figure 13 – Result for testing requests per second 20

Figure 14 – Result for testing bandwidth usage 21

Figure 15 – End user response time of a web page 22

Figure 16 – Enable CSS and JavaScript aggregation in Drupal 23

Figure 17 – Result testing default Drupal site with YSlow – Statistics view 24

Figure 18 – Result testing optimized Drupal site with YSlow – Statistics view 25

List of table Table 1 – Comparison in file’s weight – Drupal default and optimized site 25

Table 2 – Comparison in number of requests – Drupal default and optimized site 26

Table 3 – Comparison in loading time – Drupal default and optimized site 26

I INTRODUCTION

Nowadays, web sites become an essential part in every aspect of human life from economy, education, culture to entertainment We can do a lot of things thank to the presence of the internet applications that we have on our computer systems The importance of web application developments lie in the fact that without their innovations, internet usage and internet interaction would not have been what it is today Therefore, building high quality websites should be considered Of which high speed generating and loading page or website performance is a key factor Why is it? It

is only for a single reason:

Users care about performance!

Web site’s visitors will not be waste their time waiting for page loads themselves, but they will browse elsewhere when they are forced to wait too long Fast web sites are rewarded, slow web sites are punished Scalable and high performance web sites get more visitors; have happier visitors and their visitors return more often

If the revenue of a company is generated through web site, they will want to make sure that their website performance is as good as possible, because it will reduce the time required to access information, increase the number of satisfied visitors and maximize their revenue as well

Some statistics:

 Amazon: 100 ms of extra load time caused a 1% drop in sales [1]

 Yahoo!: 400 ms of extra load time caused a 5-9% drop in full page traffic (meaning that they leave before the page has finished generating and loading) [1]

 Google: 500 ms of extra load time caused 20% fewer searches [1]

 Google: trimming page size by 30% resulted in 30% more map requests [2]

Hence, it is clear that even the smallest delay can have disastrous and website performance is a big problem to care about However, there is a question can be risen up: How to evaluate performance of a website accurately In some cases, the

performance tests overestimated the performance and scalability of the web sites –

leading to embarrassing and costly crashes when the web sites were deployed In other

cases, they underestimated the capacity and scalability – leading to unnecessary

spending on hardware and infrastructure

The purpose of this research is studying on:

 Key concept of performance testing including load testing, stress testing, and other types of performance related testing

 An approach for evaluating web sites including all core activities of performance testing: identifying objectives, designing tests, executing tests, analyzing results, and reporting

 Applying the above approach to execute an experimental on performance

of Drupal – the most popular content management framework nowadays

- to discover its speed, capacity and scalability

Now, why is this important to Drupal – because this research is about evaluating performance of Drupal in particular? No, because the Drupal experience get better: evaluating exactly performance of a Drupal website, we can:

 Decide whether using Drupal as our website framework or using other content management framework instead, such as Joomla or so on

 In case of using Drupal, know how many users our website can serve without crashing, how much money we should invest on hardware and infrastructure for web server

 Measure the current speed, capacity and scalability of Drupal site and base on these measurements to improve its performance, both in front-end and back-end

More generally, a better performance Drupal would affect many:

 Drupal is increasingly being used for big, high-traffic web sites, thus a better Drupal performance, a faster Drupal site would affect a lot of people

 Drupal is still growing in popularity (according to its usage statistics, which only include web sites with the Update Status module enabled, there are over 670,000 web sites as of March 4th, 2012 [3]) and would therefore affect ever more people

 Drupal is international, thanks to its internationalization and localization support, and thanks to that it is used for sites with very geographically dispersed both in developed and developing countries A faster performance Drupal would make a big difference there as well

II PERFORMANCE TESTING FOR WEB APPLICATIONS

The main task of any testing activity is to collect information in order to help stakeholders make right decisions related to the overall quality of the application being tested Performance testing additionally focus on helping to identify bottlenecks in a system, tuning a system, establishing a baseline for future testing, and determining compliance with performance goals and requirements In addition, the results from performance testing and analysis can help to estimate the hardware configuration required to support the application when the productions “go live”

1 Overview

Performance testing is a type of testing intended to determine or validate the speed, scalability, and/or stability characteristics of the system or application under a given workload Performance is concerned with achieving response times, throughput, and resource-utilization levels that meet the performance objectives for the project or product Performance testing is commonly conducted to accomplish the following:

 Assess production readiness

 Evaluate against performance criterion

 Compare performance characteristics of multiple systems or system configurations

 Find the source of performance problems

 Support system tuning

 Find throughput levels

2 Types of performance testing

The following are the most common types of performance testing for Web applications

Load testing: This type of testing is usually used to understand the behavior of

the system under a specific expected load This load can be the expected concurrent number of users performing a specific number of transactions within the set duration This test will give out the response times and point towards any bottlenecks in the application software

Stress testing: Stress testing is normally used to understand the upper limits of

capacity within the system This kind of test is done to determine the system's robustness in terms of extreme load and helps administrators to determine if the

system will perform sufficiently if the current load goes well above the expected

maximum

Endurance testing: This type of testing is usually done to determine if the

system can sustain the continuous expected load During endurance tests, memory utilization is monitored to detect potential leaks and to ensure that the throughput and/or response times after some long period are as good as or better than at the

beginning of the test

Spike testing: Spike testing is done by suddenly increasing a very large amount

of users or loads and observing the behavior of the system The goal is to determine whether performance will suffer, the system will fail, or it will be able to handle dramatic changes in load

Configuration testing: This type of testing is created to determine the effects of

configuration changes to the system's components on the system's performance and behavior A common example would be experimenting system’s performance with

different methods of tuning and optimization

3 Core activities of performance testing

There are many approaches used for performance testing In this research, a method with following activities is applied:

Activity 1: Identify test environment Identify the test environment as well as

the tools and resources available for testing The test environment includes hardware, software, and network configurations Having a clear and thorough understanding of the test environment at the beginning enables more efficient test design and planning and helps identify testing challenges early in the project

Activity 2: Plan and design tests Define test data, determine variability and

how to simulate that variability, identify key scenarios Combine this information into one or more strategy to be implemented, executed, and analyzed

Activity 3: Execute the Test Run and monitor tests Validate the tests, test

data, and results collection Execute validated tests for analysis while monitoring the test and the test environment

Activity 4: Analyze Results, Report, and Retest Review, compare and analyze

the data Writing report base on result and re-execute test as needed If all of the desired information has been collected, the test for that particular scenario on that particular configuration has been finished

III OVERVIEW OF DRUPAL

1 What is Drupal

Drupal is a free and open source web content management system (CMS) and content management framework (CMF) It is used to build web sites ranging from personal blogs to corporate, political, and government sites including whitehouse.gov and data.gov.uk Drupal ships with basic core functionality, and additional functionality is gained by enabling built-in or third-party modules Drupal is designed

to be customized, but customization is done by overriding the core or by adding modules, not by modifying the code in the core Drupal’s design also successfully separates content management from content presentation

2 Technology stack

Drupal’s design goals include both being able to run well on inexpensive web hosting and being able to scale up to massive distributed sites The former goal means using the most popular technology The operating system is at such a low level in the stack that Drupal does not care much about it Drupal runs successfully on any

operating system that supports PHP Drupal’s technology stack is illustrated in the following figure:

Figure 1 – Drupal’s technology stack

3 Drupal work flow

The Drupal’s core is responsible for providing the basic functionality that will

be used to support other parts of the system The core includes code that allows the

Drupal system to bootstrap when it receives a request, a library of common functions

frequently used with Drupal, and modules that provide basic functionality

Drupal handles requests from a user through a series of steps For example, the Drupal core first bootstraps the application, defines critical variables and frequently used functions Next, it loads critical libraries, themes, modules and so on Finally, it returns this output to the user's browser At predefined moments in this step-by-step process, Drupal executes hooks In short, it means that Drupal examines some or all of the currently enabled modules, looking for functions that follow specific, predefined patterns

Hooks allow modules to “hook into” Drupal’s core Suppose user logs in, Drupal fires hook_user_login It means that any function named according to the

convention module name plus hook name will be called For example,

comment_user_login() in the comment module, locale_user_login() in the locale module, node_user_login() in the node module, and any other similarly named functions will be called

Figure 2 – Drupal’s architecture view

IV PERFORMANCE EVALUATION

1 Evaluating default Drupal 7.12 performance, a comparison with Joomla

In this section, I built four small web sites with the following features:

 Two web sites built with blank theme, one using Drupal 7.12 and one using Joomla 2.5.1

 Two web sites built with default theme and enabled the same functionalities, one using Drupal 7.12 and one using Joomla 2.5.1 The evaluation will focus on the results of testing the response time and amount

of requests per second (RPS) that the server can hold before server crashing The results from the evaluations will be compared to get a conclusion of whether Drupal or Joomla have a better speed, scalability and/or stability Now, why choosing Joomla for comparison Because Drupal and Joomla are currently considered the top two open source content management systems (CMS) and an exactly comparison between two latest versions of them will have a big influence on CMS’s users and developers

1.1.1 The test sites

For two blank theme web sites, there isn’t anything on the page except a word

“Home” The screenshot of blank theme web site built with Drupal 7.12 is as following And the one built with Joomla 2.5.1 is similar to it

Figure 3 – Blank theme website built with Drupal 7.12

For two default theme web sites, some features are enabled and put in the same place to make them look alike such as login block, search block, main menu and so on The images below show how both Drupal and Joomla page was configured:

Figure 4 – Default theme website built with Drupal 7.12

Figure 5 – Default theme website built with Joomla 2.5.1

1.1.2 The virtual server

In this research, the virtual server configuration is kept the same for all tests The virtual server used for hosting these web sites has the following specifications:

- Hardware configuration:

o Intel core 2 Duo @ 2.13GHz running Windows 7 Ultimate 32-bit

o 15GB free disk space, 2GB RAM

- Software configuration: The web server XAMP stack versions are:

o Apache 2.2.17

o PHP 5.3.5

o MySQL 5.0.51a

- Network configuration: LAN connection with a speed of 100Mbps

1.1.3 The testing tool

A testing tool is needed to measure the response time and the amount of traffic that server can take before user’s requests are queued, failed or the server crashes Apache jMeter [4] is a great tool to execute test with different request per second (RPS) values each time while monitoring the server’s health The RPS value will be increased until the server cannot take any requests which mean the Apache Server stop working

To prepare for tests, a computer has been used to send HTTP requests to the web server by using Apache jMeter Figure 7 shows how a HTTP request was configured:

- Server Name or IP is the IP address of virtual server: 192.168.1.100

- Timeouts connection is set to 50 seconds

- Method call is GET with the option KeepAlive enabled

- Path defines the path to the website This variable is changed depend on which

website is being tested

Next step is to define number of virtual users calling HTTP requests per second which is called a thread group in Apache jMeter Figure 8 illustrates how a thread group was defined:

- Number of Threads (users) is the number of virtual users This number is

increased each time testing by 10

- Ramp-Up Period tells jMeter how long to take and run full number of threads

(requests) chosen This field is set to 1 second

- Loop Count tells jMeter how many times each thread will execute the test This

field is set to infinite loop

Figure 6 – Apache jMeter – HTTP request configuration

Figure 7 – Apache jMeter – Thread group configuration

After finishing configurations, all web sites are tested with different RPS Figure 9 shows the graph result for testing Drupal default with 10 requests per second: