Drupal Performance Benchmark: MySQL vs. ParElastic Database Virtualization Engine

Transcription

1 Drupal Performance Benchmark: MySQL vs. ParElastic Database Virtualization Engine

2 Introduction Scaling Drupal websites to meet growing traffic demands can be a costly burden on your organization. Ideally you want your website traffic to grow and search queries to increase however this added strain on your servers means you will eventually need to scale your Drupal infrastructure. If your servers cannot handle the increased demands your users will experience performance degradations and slow load times. In most cases your users will quickly navigate somewhere other than your site! Traditionally, scaling Drupal to handle a large volume of content or a large number of authenticated users has involved complex, time-consuming, and costly database configurations. Thankfully, ParElastic has developed a solution to meet your Drupal scaling needs. The ParElastic Database Virtualization Engine greatly simplifies server and database optimization by: Scaling your database to grow and shrink in support of varying content and web traffic. Eliminating the need to configure Drupal to recognize multiple database servers. ParElastic commissioned Achieve to test the Database Virtualization Engine versus standard MySQL in a Drupal environment. The goal was to determine by how much the ParElastic solution helps Enterprise Drupal sites handle an ever-increasing volume of content and active users. This paper will explore the results of the tests performed by Achieve and the advantages of implementing the ParElastic Database Virtualization Engine for Drupal specific websites. Results at a Glance The tests performed by Achieve simulated the usage scenarios found in a high-traffic intranet or active social community site with a large percentage of authenticated traffic both reading and creating content. Through a rigorous set of performance tests Achieve was able to conclude that ParElastic made concrete improvements compared to the performance of a base MySQL Drupal implementation. ParElastic MySQL

3 Provided a consistent and stable request throughput across the full range of user loads tested Supported over 2x the number of concurrent authenticated site visitors Did so with an average response time that was less than half that of a Master/Slave MySQL configuration Provided an initial spike in throughput followed by a rapid drop-off in processing The site response time increased almost exponentially after a much lower threshold of concurrent users than with ParElastic. Goals/Purpose of Tests ParElastic commissioned this test to determine the extent that ParElastic can help large scale Drupal sites scale to handle an ever-increasing amount of content and active user base. Achieve is continually challenging the limits of Drupal performance, which is why we jumped at the opportunity to collaborate with ParElastic on these tests and we re honored to continue to support them as they grow and enhance the capabilities of their Database Virtualization Engine. As Drupal performance experts Achieve looks forward to a long-standing partnership with ParElastic and the opportunity to move Drupal forward. The target usage scenario simulated by these tests was that of a high traffic intranet and/or active social community site with a large percentage of authenticated traffic both reading and creating content. Drupal Environment and Configuration Achieve used Drupal Commons 7.x-3.2, as the base platform for these tests. Drupal Commons was selected because it provides an out of the box intranet/social community platform that also reflects the complexities of many large-scale Drupal sites. The Commons platform was initialized with 30 Organic Groups and then pre-populated with 100,000 nodes of content. Drupal Configuration Changes Achieve made the following minor configurations to the default Drupal Commons installation:

4 Account settings were changed to allow visitors to register without confirmation. Modified all views on the site to enable the use of a slave database. Built-in Drupal cron execution settings were changed to never run cron. Drupal DB logging was disabled. Added a custom feature that exposed 2 RSS feeds from a view to be used by the JMeter tests to select content to view. Drupal Anonymous page caching was enabled with an expiration time of 1 hour. For the MySQL tests, the module autoslave, was added and configured to route most SELECT queries to the Slave MySQL Server. Test Methodology Achieve performed the testing using a custom JMeter 2.9 script, which simulates a typical traffic pattern for a site. The scripts were uploaded and executed using the BlazeMeter testing service to generate the target traffic volumes. JMeter Test Details Achieve configured the JMeter tests to simulate 50% anonymous traffic and 50% authenticated traffic. The anonymous and authenticated traffic threads ran concurrently. The tests were also configured with a random delay between 0 and 2 seconds between all page requests. Finally, 2 RSS feeds were added to the Drupal site that provided lists of random content URLs. These feeds were used by the JMeter tests to randomly select content to view on the site. Anonymous Traffic: The anonymous traffic thread group performed the following actions: Viewed the site home page Viewed the Commons Group Listing page Viewed the Group Home page for 2 groups (randomly selected) Viewed the Group Content (node) page for 10 pages (randomly selected) Authenticated Traffic:

5 The authenticated traffic thread group performed the following actions: Viewed the site home page Viewed the site registration page Submitted the site registration form (creating a new user account) Logged out of the site Viewed the login page Submitted the login form with the generated account information Viewed the Commons authenticated user home page Viewed the Commons Groups Listing page Viewed the Group Home page for 2 groups (randomly selected) Viewed the Group Content (node) page for 10 pages (randomly selected) Submitted a comment or answer to 1 of the 10 pages viewed (randomly selected) Created 3 new types of nodes Post, Wiki, or Question in random groups. NOTE: Content generation for node/comment creation was performed by extracting random content from several publically available books that were downloaded from the Project Gutenberg website. Test Environments The hosting environment for this comparison was setup using multiple Amazon EC2 server instances. The web server configuration remained consistent between the MySQL and ParElastic tests with just the Drupal settings.php file being updated to point at each database platform. Web Servers 10x Amazon EC2 M3 Double Extra Large Instances with EBS file system. o 8 CPU Cores o 30 GB RAM o Ubuntu Bit NGINX Web Servers PHP 5.5

6 Database Servers (MySQL Tests) 2x Amazon EC2 M3 Double Extra Large Instances with EBS file system. o 8 CPU o 30 GB RAM o Ubuntu Bit MySQL Community 5.5 in Master/Slave Replication configuration. o Basic MySQL Tuning was performed using the tuning tool at Database Servers (ParElastic Environment Tests) The ParElastic (PE) environment requires a very distributed network configuration. Thus the environment utilizes a higher number of servers than you would see in a typical Drupal hosting environment. The ParElastic Database environment consists of the following Amazon Web Services (AWS) Server instances: 2 EC2 C1.xlarge Instance running as the primary PE servers. 6 EC2 M1.xlarge Instances handling the PE Persistent sites. 1 EC2 M1.medium Instances handling the PE catalog. Cost and Benefit Summary Although the ParElastic configuration was twice as expensive it was able to handle twice the amount of traffic in half the response time. The estimated hosting costs for the MySQL environment ran at $2 an hour and the cost for the ParElastic environment came in at $4.16 an hour. Some of the benefits of ParElastic s flexible database architecture over the basic MySQL Drupal implementation were: The ParElastic configuration was able to easily handle over twice as many active users while providing better overall responsiveness. Under that increased number of active users, the ParElastic configuration provided responses in half the time on average. Provided a consistent and stable request throughput across the full range of user loads tested.

7 Supported over 2x the number of concurrent authenticated site visitors. ParElastic was configured with inexpensive m1.xlarge instances in Amazon s cloud and therefore linear scalability would come at a lower incremental cost with ParElastic (native MySQL was hosted on much more expensive m3.2xlarge instance). Test Limitations/Exclusions Since the purpose of this test was to compare the performance impact of two different database configurations on a Drupal site, Achieve did not implement any of the common site performance enhancement technologies such as Varnish or Memcached. The only caching technologies used were the built-in opcode cache included with PHP 5.5. Additionally, only minimal tuning of the web and database servers was performed.

8 Test Results The ParElastic Drupal Commons site was far more responsive and handled a higher level of concurrent traffic compared with the Master/Slave configuration of MySQL. The following graph illustrates the difference in average page response times by both ParElastic and MySQL at varying levels of user load. NOTE: Lower is better. Figure : ParElastic vs. MySQL Average Page Response Time Conclusion The success of your business relies upon a host of factors. Your digital infrastructure should exist to complement your business and increase your level of success, not give you headaches or handcuff your growth. If your business depends on the performance of your site then you should not leave anything to chance. Implementing ParElastic to your Drupal environment makes business sense and will give you the confidence that your infrastructure can handle the spikes in traffic without any performance degradation. Embrace the traffic spikes knowing that your servers can handle the load. For Drupal sites with large amounts of content and high traffic volume ParElastic can provide a significant boost to the overall performance and scalability of and is a better alternative to a basic MySQL implementation. Your website should be helping your business grow but if your server infrastructure is not optimized to scale then it can hinder your future success. ParElastic lets you scale on demand with the power of multiple database servers acting as one. Give your enterprise the freedom to grow with a technology solution that is agile, lightweight and can scale as your business succeeds.

9 Appendix A: Detailed MySQL Results Summary The test MySQL environment was able to handle approximately 75 concurrent users before starting to show a significant impact on application responsiveness. Our tests peaked out around 200 concurrent users with a peak page request rate of 2000 page requests per minute. Concurrent Users vs. Average Page Response Time The following graph illustrates the relationship between concurrent users and overall average page response time of the Drupal Commons site. Figure : MySQL Concurrent Users vs. Average Page Response Time. Page Requests per Minute The following chart illustrates the average number of page requests made by JMeter over the lifetime of the test.

10 Figure : MySQL Page Requests per Minute Web Server CPU Utilization The following graph shows the typical Average CPU Load on each of the Webservers. The chart is almost identical on all 10 webservers so we re only showing a single representative chart. Figure : MySQL Typical Web Server CPU Load Average Database Server CPU Utilization The following graph shows the average CPU load on the Database Servers during the test.

11 Figure : MySQL Database Server CPU Utilization

12 Appendix B: Detailed ParElastic 1.3 Results Summary The test ParElastic (PE) environment was able to handle approximately 250 concurrent users before starting to show any significant impact on application responsiveness. Our tests peaked out at 300 concurrent users with a peak page request rate of 1500 page requests per minute. Concurrent Users vs. Average Page Response Time The following graph illustrates the relationship between concurrent users and overall average page response time of the Drupal Commons site. Figure : ParElastic Concurrent Users vs. Average Page Response Time. Page Requests per Minute The following chart illustrates the average number of page requests made by JMeter over the lifetime of the test.

13 Figure : ParElastic Page Requests per Minute Web Server CPU Utilization The following graph shows the typical Average CPU Load on each of the Webservers. The chart is almost identical on all 10 webservers so we re only showing a single representative chart. Figure : ParElastic Typical Web Server CPU Load Average Database Server CPU Utilization The following graph shows the average CPU load on the Database Servers during the test. This graph is representative of the load shown by all of the servers in the ParElastic DB cluster.

14 Figure : ParElastic Database Server CPU Utilization CONTACT PARELASTIC 125 CambridgePark Drive, Suite 400 Cambridge, MA x1013