• Apache web server tuning
• Place images and big files to a different host
• Use lightweight WP Themes
• Modify and tidy selected WP Themes
• Use WP Super Cache
• Reduce plugin use and remove bad ones.

After the hardware refresh and Database tuning, it is now time to look into the applications. For this site, WordPress and Apache HTTPD are the main components for the presentation layer. WordPress is the Content Management System written in PHP. Apache HTTPD is the web server. Both programs are Open Source and widely supported by their respective communities. Both programs also offer flexible configurations, enabling many optimization opportunities.

Compiling Options for Apache HTTPD

With Apache HTTPD, compiling the program from the source code is the most recommended way to start. This provides a way to remove any unnecessary modules that are included. To do this, use the configure script to exclude non-essential built-in modules such as IMAP or user directory support:

./configure –prefix=/usr/apps/apache2 \
–disable-imap \
–disable-userdir

It is also recommended to compile the modules using shared libraries, instead of statically linked, to reduce the memory usage during runtime. Add this option in the configure script:

–enable-so

Any additional modules can now use the “=shared” suffix to enable shared library.

Enable Caching on the Client Side

With Apache HTTPD version 2.0, or above, the use mod_headers module and ETAGS are recommended. Etags headers enable caching of static files, such as images or Flash, on the client’s browser side. The main advantage is to reduce the web server’s work to upload the files. Consequently, it also reduces network bandwidth utilization. This is an Apache HTTPD extension module. Run the configure script with the following:

–enable-headers=shared

Edit the httpd.conf file in Apache to include:

ExpiresActive On
ExpiresByType image/jpg “access plus 7 days”
ExpiresByType application/x-shockwave-flash “access plus 1 weeks”
ExpiresByType application/x-javascript “access plus 30 days”
FileETag none

Etags headers are especially useful for repeat and frequent visitors. They are supported in most modern browsers.

Outsourcing Images

To reduce bandwidth consumption on the main blog site, consider the option to move images to a different server, such as Flickr, or a separate web hosting company. One can expand this further to include Flash or client side Javascript files, if they are used often. If this is not an option, then the ETags caching procedure above is the best way to speed up pages with a lot of images to download.

WordPress Tuning

WordPress has an awesome set of free themes to choose from. It is best to pick a simple theme and build on it. Once a lightweight theme has been selected, review the included PHP codes and strip out the unnecessary DB lookups to form a file path. For example,

<link rel=”stylesheet” href=”<?php bloginfo(‘stylesheet_url’); ?>” type=”text/css” media=”screen” />

Can be changed to:

<link rel=”stylesheet” href=”/opt/apache2/htdocs/wp-content/themes/myTheme/style.css” type=”text/css” media=”screen” />

Use an Open Source tool called tidy, to correct and compress style sheets into smaller file size. Note: backup the original CSS file, in case there is a need to modify the style sheet.

Remove any unnecessary nice-to-have features in the PHP codes, such as rotating headers or different background images on pages.

Evaluate WordPress Plugins

Rendering a dynamic page for a blog site takes up system resource. The job of caching plugins, such as WP Super Cache, is to convert a dynamic page into a static page, bypassing the need to execute PHP codes and perform DB lookups. The installation is not entirely straight forward, but the result is amazing and is worth the effort. For further explanation of the plugin, visit Donncha’s WP Super Cache page.

Not all plugins are created equal. There are plenty of similar plugins available for the same job. Pick the ones that are small in size and operates in a simple way. The ones to avoid are plugins that rely too much on another site’s access to pick up client-side javascript codes, icons, etc. An example is the ShareThis plugin that calls it’s home site all the time. This plugin is being used on every page, including the home page, so it just adds to the pages loading time. The alternative is Joost De Valk’s Sociable or Valent’s Social Bookmarking Reloaded plugin, which is much smaller and simpler to use.

Finally, deactivate and remove all unused plugins.

Further readings: Web Site Optimization – 13 Simple Steps, Web Site Optimization – Fast Downloads, Web Optimization Options.

This article was posted on Rudy Amid's Blog:

Web Site Tuning – Web Server and WordPress

Related posts:

1. Web Site Tuning – The Database
2. Upgraded to WordPress 2.8.4
3. Web Site Tuning – Let’s Start from The Bottom

• Adjust MySQL’s system variables.
• Use tuning-primer.sh script.

The most active application of this blog requires the use a database system to store data such as this content, comments, tags, or links. The database of choice here is MySQL. By default, it comes with a default set of system variables, designed for common and light-weight use. However, tuning can be performed to make it even more compact and efficient.

Below are the settings in my.cnf file for this low traffic and light weight site:

• sort_buffer_size = 64K
  Default is 2M, reduced to 64K because I’ll hardly do big complex sorting.
• read_buffer_size = 256K
  Default is 128K. WordPress does a lot of sequential scans, and giving it more space is helpful.
• net_buffer_length = 2K
  Default is 16K. Apache/PHP client does a lot of quick lookups. The expectation is the client will not need that much socket buffer to begin with. The buffer will dynamically enlarge, as needed, to 1M (default for max_allowed_packet).
• thread_stack = 64K
  Default is 192K. Connection from this site may only be 1 or 2 clients. Other external clients are not allowed. A large value, such as the default, is not necessary. The only sure way to know the limit is to run MySQL benchmark suite.

There is a MySQL Performance Tuning Primer script that can be used to provide more tweaking recommendations. The database must be active for more than 48 hours before using this script. The following changes are based on the script’s recommendations:

• long_query_time = 5
  Default is 10 seconds. When SQL queries usually go fast, it’s advisable to reduce the threshold. This is used in conjunction with –log-slow-queries option to figure out any queries that is out of the ordinary.
• max_connections = 10
  Default is 100. When there’s no external clients and the database only have a handful of local connections from the Apache/PHP, reducing this to a more reasonable number will conserve file descriptors and possibly memory usage.
• key_buffer_size = 128K
  Default is 128K. As an experiment, set at 16K, the key cache miss ratio was 1:8 and key buffer was at 50% fill ratio. Getting the right number will help reduce SQL command execution time. Setting it to default produces miss rate of 1:212 and 100% fill ratio. That seems like the correct setting for this site. There is a post on InformIT that mentions how to determine the proper key_buffer_size setting.
• query_cache_type = 1
  query_cache_limit = 256K
  query_cache_size = 3M
  Defaults are 1, 1M, and 0, respectively. With frequent querying, it will help to ensure most common queries are cached and ready to run. The number to watch is the Fragmentation size. The more fragmentation, the database will have worse performance. With this setting, fragmentation is currently at 4%. There is a more in-depth review of MySQL’s Query Cache (old but still relevant).
• max_heap_table_size = 96M
  tmp_table_size = 192M
  Defaults are 16M and 32M. This is for the efficiency of doing table lookups in memory. When there is not enough space allocated in memory, the temp tables will be created on disk. Lookups on disk is slow. If there is enough RAM on the server, it is better to move those temp tables to memory. The tuning-primer will show how many temp tables being used and a percentage of what’s on disk. If the machine is a dedicated server, increase until all of temp tables are not created on disk. Using this setting, this site has 68% temp tables created on disk. It is possible to allocate more memory but this machine is not a dedicated database server. Some memory is needed for other applications.

Database tuning is a tricky job. Professional Database Administrators spend a lot of time tweaking and tuning the settings to get their databases perform optimally. Since there are so many variables, it is almost an educated guess and plenty of experimentation to get it right. With the proper tools, one must not be afraid to take a risk and try out all of the combination.

Further readings: MySQL tips and tricks list, InnoDB Performance Tuning Tip, and Getting Maximum Performance from MySQL.

This article was posted on Rudy Amid's Blog:

Web Site Tuning – The Database

Related posts:

1. Web Site Tuning – Let’s Start from The Bottom
2. Web Site Tuning – Web Server and WordPress
3. Web Site Performance

• Upgrade the PC hardware.
• Add more hard disks.
• Update to the latest OS.

This web site seems rather straight forward from a reader’s point of view. It’s actually a pretty complex system underneath it. It’s made up of many different components. It starts from the hardware, operating system, database, all the way to networking equipment. As the first part of my series of web site tuning, I’m going to start examining the “bottom” layer and move all the way up to the web application.

For starters, I have to choose the right hardware to run a server. Since I’ll be running a database and web application, I don’t want to pick too small of CPU with little memory. I am not running a Windows based machine, so my choice for hardware is more flexible. Most Linux/Unix based Operating Systems out there don’t require much in terms of hardware. I was previously running Fedora Core Linux on a 650Mhz CPU machine with 320Mb of memory. I expect the same hardware to be good enough for Ubuntu Linux. Of course, giving it more CPU and more memory will only help speed up the application’s performance. So, upgrading the hardware is always a good first step to improve web site performance.

Also very important is the choice of hard disk to use in the PC. The web applications (and OS) constantly retrieve from and write to files on the hard disk. If the disk access is slow, it will impact the performance of the software. I started with a 5400 RPM 40Gig Maxtor hard drive using ATA66 IDE interface. Linux is generally a compact OS (unlike Windows) and server-based applications are generally small in size. I managed to survive with the old disk for quite some time.

When there’s a lot of disk activity (aka Disk I/O), such as swapping, database access, or log writing, it is a very good idea to get a second (or third) physical hard disks to separate the data, swap, and OS files. Sysadmins sometime call this practice “putting them on a separate spindle“. With the invention of faster and smarter RAID controllers, this may not be necessary anymore. But for old school, true-and-proven results, having multiple disks will only help improve performance of a web site.

As for this site, I’ve upgraded to a 2.4Ghz CPU with 1 Gigabyte memory. I’ve also recently upgraded to 7200RPM Seagate disk drive using SATA100 interface. Plus I’ve upgraded to the latest Fedora Core Linux. The server’s hardware works so well, I can even start using it as a desktop, a backup machine to browse the internet.

This article was posted on Rudy Amid's Blog:

Web Site Tuning – Let’s Start from The Bottom

Related posts:

1. Web Site Tuning – The Database
2. Web Site Tuning – Web Server and WordPress
3. Trying Out Fedora Core 10

Using the tools available at my disposable, I’m going to scrutinize my web site. I’ll start with a free Full Page Test tool from Pingdom. Testing my site with it reveals the main blog page loads rather slowly: averaging 6-7 seconds. I’ve noticed the pieces affecting the load times are ShareThis button plugin, graphics, and CSS files.

To confirm, I’m going to use a commercial software from Keynote Systems to provide the numbers from sites all over the world:

• From Toronto (Bell Canada), the average response time is 5-6 seconds.
• Singapore (SingTel), averaging 13-14 seconds.
• London (British Telecom), averaging 7-8 seconds.

There are possible caveats to these simple performance snapshots:

• Time of the Day
  Network traffic varies at different times of day. North America can be very active during work day, saturating the bandwidth on the network backbones to my site’s downstream ISPs such as AT&T.
• Local Bandwidth
  I share my server connection with my outgoing DSL broadband connection. Whenever I use it to browse from home, network response time is going to degrade.
• Load Testing
  The numbers above are averages from loading the page 5 times. In a real performance test, it has to be scripted to hit various pages (not just one), ramp up with multiple users (depending on requirements), and run continuously over a period of 30-60 minutes. However, since I run a light-traffic site, load testing is not necessary.

In summary, it looks like my blog’s main page is not loading very well. Without changing my server’s network bandwidth, obviously some things on this page have to be changed or eliminated. There are things I can do to optimize this page, which I’ll cover in the next few weeks. It’s going to be an interesting challenge.

How slow is my page loading in your browser?

This article was posted on Rudy Amid's Blog:

Web Site Performance

Related posts:

1. Web Site Tuning – Web Server and WordPress
2. Web Site Tuning – Let’s Start from The Bottom
3. Web Site Tuning – The Database