Skip to content

Posts tagged ‘performance’

1
Mar

My New 2010 Audi A4 S-Line Has Arrived

After many months of waiting my new 2010 Audi A4 S-Line has finally arrived and I am LOVING IT! I never believed that I would like this as much, if not more than my beloved ‘09 A5 that I sold a few months back in order to get 4 doors (more room, just in case). The lines on this car are amazing as are the S-Line wheels and other styling cues. I stayed with Audi Drive Select even with the high price tag, it is an amazing option to have. My only concern with the new A4 is the 2.0T engine and the lack of HP it produces. I must say that after two days I’m fairly impressed overall with the stock 2.0T engine and tip-tronic transmission. The reason why I am not so concerned is because turbocharged engines such as this can easily be tuned to truly unleash their potential, and I have a few options in mind for turning this A4 into something much more powerful. Here are some “modifications” I plan to do over the next few months:

  • ECU Flash either from Stasis or APR
  • Quad-Tip Exhaust w/ S4 Rear Valance
  • High Flow Cat
  • High Flow Intercooler Pipe
  • High Performance Front Mount Intercooler

Once these upgrades are done I will likely de-badge my A4 (which I really dislike) due to the fact that those labels just won’t do the car justice. I can’t wait to get started! See below for a quick snap I took the day I got the car, more pictures to come soon!

11
Feb

Optimizing Your Wordpress Site

My colleague wrote an excellent article the other week on making your web sites load faster by leveraging the Rackspace Cloud Files & CDN platform to serve all static content on your site. I want to take this a step further for those of you who leverage the Wordpress platform which is one of the most popular open-source web applications in existence.

In the Wordpress community there are countless plugins that can be used for optimization, so how do you know which ones to use? Well I’m about to tell you and save you many hours or days of searching and experimenting.

The first plugin I want to mention is already one of the most popular – Wordpress Super Cache. This tool generates static HTML files from your dynamic pages produced by WP. Once the HTML version of the page is generated your hosting platform will serve this in place of the dynamic PHP pages which causes increased server load and longer page load times. The vast majority of your visitors will be served static content by default but WP Super Cache knows to switch back to the standard PHP pages for users who are leaving comments (or have left a comment), users that are logged in, and users who are reading a password protected blog post.

What does this do for you exactly? There are two significant benefits:

  1. Reduced server resource utilization: Having your web server serve static content instead of dynamic content decreases CPU and memory utilization significantly and result in smaller hardware/resource requirements or allow your current hardware to handle many more concurrent connections to your site(s). On platforms such as Cloud Sites from the Rackspace Cloud this will have a large impact on your compute cycle usage.
  2. Decreased page load times: Decreasing page load times makes for a better end-user experience on your web site and is shown to reduce bounce and improve overall stickiness on your pages.

Installation

  1. Download WP Super Cache here
  2. Upload to your Wordpress /wp-content/plugins/ directory
  3. Modify the /wp-content/wp-cache-config.php file: Uncomment “$use_flock = true;” (if using Rackspace Cloud Sites)
  4. Login to your Wordpress admin console and navigate to ‘Plugins’
  5. Activate the WP Super Cache plugin
  6. Before turning on WP Super Cache you MUST enable permalinks (Settings –> Permalinks)
  7. Navigate to Settings –> WP Super Cache
  8. Set WP Super Cache status to ‘On’
  9. Make sure that “Super Cache Compression” is set to “Disabled”
  10. Leave all other options default unless you know specifically how this will affect your site
  11. Click ‘Update Status’
  12. Scroll down and copy the updated mod_rewrite rules
  13. Paste these new rules into the .htaccess file within your Wordpress root directory
  14. Depending on how your permissions are set there is a button you can click which may be able to do this automatically for you
  15. Done!
  16. To verify that WP Super Cache is working properly visit your site directly (you may need to logout depending on your settings. Pull up a page/post and use your web browsers ‘View Source’ feature. Scroll to the bottom of the page and you should be something like this:
<!-- Dynamic page generated in 0.380 seconds. -->
<!-- Cached page generated by WP-Super-Cache on 2010-02-16 17:36:22 -->
<!-- super cache -->

You are all set and now your Wordpress site can handle much more traffic and operate much more efficiently.

The next plugin I want to talk about also has a big impact on site performance and can further reduce server load. CDN Tools (developed by Paul Kehrer) is a plugin that allows you to load your sites javascript and media files to an external CDN platform such as Cloud Files from the Rackspace Cloud. Even if you don’t have or want to use the Cloud Files storage and CDN platform you can load your larger JS libraries (prototype and jquery) for free from Google’s servers.

If you are not familiar with platforms such as Cloud Files, what this allows for is global distribution of your static media files (images, video, documents, etc) over a Content Delivery Network or CDN. Cloud Files offers seamless integration with Limelight Network’s CDN platform that is the second largest in the world allowing your static data to be distributed across 50+ nodes around the globe. When a user from a specific geographic location requests one of the files you have cached on Limelight’s CDN, they are served this data from the closest possible data center to them, vastly reducing network latency which is critical for a global audience. Serving data from a single US data center may work great for a mainly North American audience, but when it comes to sending large files across the ocean, that is a different story entirely.

Some might ask why you would want to pay an additional cost to use a platform such as Cloud Files and this really just depends on your needs. If you have a small family blog it may not be necessary, but if you are running a popular site with a lot of static media typically the reduction in CPU/memory from your server or platform having to load this static content anyways more than makes up for the low CDN cost of $0.22/GB and the benefit of a much better end-user experience.

Installation

Installing CDN Tools is incredibility simple and only requires a few clicks after uploading.

  1. Download CDN Tools here
  2. Upload to your Wordpress /wp-content/plugins/ directory
  3. Login to your Wordpress admin console and navigate to ‘Plugins’
  4. Activate the CDN Tools plugin
  5. Navigate to Settings –> CDN Tools
  6. Enable ‘Use Google AJAX CDN’
  7. If you have a Cloud Files account choose Cloud Files from the ‘Primary CDN’ drop down menu
  8. Enter your Rackspace Cloud control panel username and account API key (located in the control panel at ‘Your Account à API Access’
  9. Save Changes
  10. Click ‘Load Files’ (this side loads all your static data to Cloud Files and moving forward it will do it automatically)
  11. Done!

Note: The developer for CDN Tools has carefully crafted this plugin allowing you to easily disable. If you ever need to turn off CDN Tools it will automatically update your file paths without you having to do anything manually. This is a big plus!

1
Feb

Optimizing Your Drupal Site

Drupal is a widely used open-source CMS platform that is becoming increasingly popular by the day. I have personally used Drupal on/off since v4 and have seen it mature over the years into my preferred content management system. Here at the Rackspace Cloud we speak to hundreds if not thousands of new customers and prospects every month that either want to migrate their existing Drupal sites into the Cloud or start fresh with Drupal.

Improving performance is always a concern with any site and after working with countless Drupal installs I have identified a few tools and options that can very quickly make a very noticeable difference in your sites performance. These tweaks are not specific to the Rackspace Cloud platforms and should be considered by any Drupal site admin on any hosting solution. They will not only improve the performance of your site but also reduce back-end resource utilization such as CPU and memory or lower compute cycles on Cloud Sites for example. This is achieved through various levels of static page caching and a highly optimized database. Let’s take a look at the options.

Before we look at any third party modules lets examine what Drupal has built-in that can help. Navigate to Administer –> Site Configuration –> Performance. This section allows users to enable/disable specific caching functions included in Drupal CORE. Here are my recommendations for a typical Drupal site:

  • Caching Mode: Normal
  • Page Compression: Enabled
  • Block Cache: Enabled
  • Optimize CSS Files: Enabled (use in production only, not during theme development or customization)
  • Optimize JavaScript Files: Enabled (use in production only, not during theme development or customization)

Next I highly recommend setting up a cron job to run the Drupal cron.php file regularly, I typically run it once per day but it depends on your site (heavy traffic sites might want to run it more often). While this may not have a direct performance impact it is good general practice as executing this script performs many maintenance tasks including cleaning up old log files and checking for updates. Setting up a cron job is pretty simple and some hosting platforms such as Cloud Sites can make this a point/click configuration. Reference this page for more information on how Drupal uses cron and setup instructions.

Now, lets take a look at two third party modules that I have used for sometime that can have a dramatic impact on your site:

Boost

Boost provides static page caching for Drupal, similar to how WP Super Cache works for Wordpress. This module works extremely well if your site received mostly anonymous traffic. The developers make this module a breeze to set up and configure and I’ve tested it across many platforms including a dedicated Linux server, Rackspace Cloud Sites & Cloud Servers and even a few shared hosting platforms. Boost also includes partial support for Nginx, Lighthttpd and even IIS 7 (Apache is fully supported). Let’s walk-through the set up:

*Note, Boost requires cron and clean-URLs to be enabled FIRST*

  1. Download Boost here: http://drupal.org/project/boost
  2. Extract and upload to your Drupal /modules folder
  3. Navigate to Administer –> Site Building –> Modules
  4. Enable Boost
  5. Navigate to Administer –> Site Configuration –> Performance
  6. Notice the new options for ‘Boost’ on the top navigation menu, click Boost Settings
  7. Review and adjust any settings necessary (I generally stick to the defaults)
  8. Click ‘Boost htaccess rules generation’ in the top nav menu
  9. Copy the automatically generated htaccess rules and paste them in your htaccess file, see below:

# RewriteBase /

INSERT BOOST CODE HERE

#Rewrite URLs of the form ‘x’ to the form ‘index.php?q=x’

Boost should now be up and running. Be sure to check your Administer –> Reports –> Status Report page for any errors.

DB Maintenance

The DB Maintenance module optimizes administrator selected tables in your Drupal sites database during the regular cron.php executions. Keeping your database optimized is one of the easiest ways to ensure a smoothly operating site on any platform and is essential if you want to scale your site effectively for high traffic. Installation is fairly quick and easy:

  1. Download DB Maintenance here: http://drupal.org/node/41588
  2. Extract and upload to your Drupal /modules folder
  3. Navigate to Administer –> Site Building –> Modules
  4. Enable DB Maintenance
  5. Navigate to Administer –> Site Configuration –> DB Maintenance
  6. Select tables in the Drupal database that you wish to optimize during the regular cron execution and enable logging if you prefer
  7. Save and thats it!

It is suggested to keep your selections to tables where there is a lot of data movement such as accesslog, cache, sessions, and watchdog. You can always make a separate and more infrequent cron as part of your regular server management if you want/need to optimize your node tables.

CDN Integration

The final tip I’ll leave you with is one of the most important and that is serving your static content from a CDN platform. There are many options and one of the easiest and most cost effective to leverage is Cloud Files from the Rackspace Cloud, which has built in CDN integration from Limelight Networks. Off-loading your static content such as images, video, audio, documents, etc to a global content distribution network not only decreases even more load on your hosting platform but it makes site load times significantly faster by serving this content as close as geographically possible to your site visitors (local or close to local data centers).

Uploading content to Cloud Files and enabling CDN distribution takes only a few seconds and is the preferred method for embedding static content, especially large video and audio files. Currently there are a few Drupal modules in development that support Cloud Files and other storage/CDN platforms on varying degrees but none that I’m comfortable mentioning just yet. Once these mature it will only make using these platforms even easier.

Deploying these tips and modules should have a significant impact on your sites performance. There are countless other ways to further optimize your site in addition to this so don’t hesitate to explore other options as well. I hope this is helpful to new Drupal users and even seasoned noders alike.

If you found this article helpful or have anything to add please leave a comment below, I’d love the feedback!

P.S. Looks like I’m going to miss DrupalCon this year for the first time in a few years, I’ll be enjoying my Honeymoon instead. Too bad they moved it to late April. I’ll look forward to 2011!

23
Dec

Cloud / VPS Apache Performance Comparison

DISCLAIMER: I am a Rackspace employee. These tests were not sanctioned by the Rackspace Cloud and were preformed on my own time independently. If you have any questions about the testing methodology don’t hesitate to ask.

—–

UPDATE #1: I received several comments about the testing methodology used in these benchmarks so I wanted to explain further. Each server instance at the Rackspace Cloud, Linode and Amazon are running the exact same Linux distribution (Debian 5.0 Lenny), kernel, architecture (x86_64) and version of Apache (2.2.9 w/ worker MPM).

UPDATE #2: After much concern was raised I went ahead and reran the benchmarks on the small instances after tuning a few settings on the Linode server.

echo 99999 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max

Also, instead of running the tests from a consistent remote location I ran them on the local machines this way I could guarantee that network latency wouldn’t impact the test results in any way.

—–

In the past few weeks there has been a lot of talk about the differences between various Cloud and VPS providers (see my post), mainly revolving around performance. I decided to take some time last week to run some very straight forward and real world tests to gauge performance among the most popular providers: The Rackspace Cloud, Amazon EC2 and Linode.

For the benchmark I decided to use ApacheBench and Siege as *most* users on these platforms are serving some type of web content via Apache. Even if different web server software is used, it is unlikely that the results and trends would differ. As part of a series of posts, I will be running the same benchmarks against static content and dynamic content. This way we can be sure to look fairly at all aspects of each particular platform.

As mentioned, I decided to use ApacheBench and Siege as the testing platforms so I performed a default install of Apache 2.2 with the Worker MPM on each server instance. The server OS platform is Debian 5.0 Lenny on all servers.

These benchmarks are very easy to duplicate, so if you would like to test the results simply replicate the total connections or time and concurrency settings mentioned below.

I did not tweak any of the Apache settings on any of the server instances. I used the default settings of:

<IfModule mpm_worker_module>
StartServers                             2
MaxClients                              150
MinSpareThreads                  25
MaxSpareThreads                 75
ThreadsPerChild                    25
MaxRequestsPerChild          0
</IfModule>

I ran the same tests against each platform and since I was only hitting the default HTML page generated by the Apache install I decided to raise the concurrency limit up to something significant to generate some real load. Each benchmark was run three times over three different days and I took the best result from each set of tests.

ApacheBench: 100,000 Total Connections / 100 Concurrent Connections
Siege: 10 Minutes Under Siege / 50 Concurrent Connections

Let’s get to the results!

Small Size Instances

ApacheBench Results

Rackspace 256MB Cloud Server Linode 360MB Media Temple DV 512
Concurrency Level 100 100 100
Requests [#/sec] (average) 10,706.64 4,554.43 N/A
Time Per Request [ms] (mean) 9.340 21.957 N/A
Transfer Rate [Kbytes/sec] Received 3336.14 1,414.39 N/A

Siege Results

Rackspace 256MB Cloud Server Linode 360MB Media Temple DV 512
Transactions 1,587,997 1,165,412 N/A
Availability 100.00% 100.00% N/A
Response Time 0.04 secs 0.05 secs N/A
Transaction Rate 2,647.68 trans/sec 1,942.90   trans/sec N/A
Successful Transactions 1,587,997 1,165,412 N/A
Failed Transactions 0 0 N/A
Longest Transaction 0.42 0.61 N/A
Shortest Transaction 0.00 0.00 N/A

Review

The Rackspace Cloud Server instance, with only 256 MB of RAM, performed well under the stress as did the Linode 360 server, but there is still a significant difference in the overall performance. This could be due to host server utilization, but according to the Linode control panel the host machine my instance was running on is “low”.

In the Siege results we get some similar insights. The 256 MB Rackspace Cloud Server processed significantly more transactions than the Linode server. Importantly, the transaction rate was also much higher.

There is always a lot of discussion around the Linode 360 server instance being a better value than the 256 MB Rackspace Cloud Server, but the tests show otherwise. In my opinion this is most likely due to Rackspace Cloud’s lower utilization of host hardware and a more robust network.

Large Size Instances

Now lets take a look at the larger instances. I wanted to work Amazon’s EC2 platform into these performance tests and their large instance is most comparable to the Cloud Server and Linode instances of the 8GB variety.

ApacheBench Results

Rackspace 8192MB Cloud Server Linode 8640MB Amazon EC2 Large
Concurrency Level 100 100 100
Requests [#/sec] (average) 10,729.61 9,109.91 6,782.93
Time Per Request [ms] (average) 9.320 10.977 14.743
Transfer Rate [Kbytes/sec] Received 3,363.62 2,829.17 2,113.04

Siege Results

Rackspace 8192MB Cloud Server Linode 8640MB Amazon EC2 Large
Transactions 1,564,152 1,636,652 891,956
Availability 100.00% 100.00% 100.00%
Response Time 0.04 secs 0.04 secs 0.07   secs
Transaction Rate 2,606.79 trans/sec 2,727.34   trans/sec 1,485.80   trans/sec
Successful Transactions 1,564,152 1,636,652 891,956
Failed Transactions 0 0 0
Longest Transaction 0.49 0.22 0.65
Shortest Transaction 0.00 0.00 0.00

Review

As we saw with the smaller instances in the ApacheBench test, the Cloud Server with fewer resources is outpacing both the Linode server and the Large EC2 instance. But in the Siege benchmark we see the Linode instance take the crown for total transaction rate. I would note the larger memory allocation on the Linode server instance might have something to do with these results so be sure to compare price for your particular application.

Amazon’s Large EC2 instance was the slowest of the bunch during the ApacheBench testing but did complete all of the transactions thrown at it during the Siege benchmark.

Final Thoughts

The tests show some significant performance benefits when running on the Rackspace Cloud Servers platform on the low end and similar performance to larger Linode and Amazon instances on the high end even though the comparable Cloud Server had much less memory and therefore lower cost. In my opinion, I believe lower hardware utilization and better host server hardware contribute to these results.

Apache settings can definitely be tweaked to increase performance on any of these platforms; this was just a baseline test using the defaults provided. The next round of tests will focus on serving a dynamic web applications.

If you have any thoughts, questions or comments about the benchmarks performed here please leave a comment below. I’d love to hear from you!

« Older Entries