Sleep Is For The Weak

We each operate on our own internal cycle.  There are parts of the day when you are simply more efficient than others.  For some people they find in the morning right after they wake up is their most productive time.  Others drag in the morning but really step into their stride in the late afternoon.

Knowing our internal cycles can really assist in our ability to schedule things throughout our day and get things done.  If I know that from 3pm until 5pm I am very productive I  should schedule my long term project time to coincide with with those times.  I can schedule the easier, less demanding tasks during my known downtimes.  If you are working with a co-worker who is productive in the first part of the day, and you don’t get into your groove until the afternoon you should work together to help one another.  You can block the morning as time to cover any interruptions that come into the office during the morning allowing your co-worker to focus on projects when he is most able to produce.  After lunch have your co-worker take any incoming distractions allowing you to focus on projects.

Thanks to: China Guccio for the image

The tuning step taken to improve the performance of our vBulletin site hosted at 1&1 on a VPS was tuning.  I simply adjusted the following cache and buffer sizes to match the list below.

• key_buffer=64M
• table_cache=256
• sort_buffer=4M
• read_buffer_size=1M

This is up from an 8M Key_buffer, 128 table_cache, 2M sort_buffer, and 512k read_buffer_size.  The command issued to make these changes looks similar to this.

mysqld_safe -O key_buffer=64M -O table_cache=256 -O sort_buffer=4M -O read_buffer_size=1M -u admin -p &

I don’t have any concrete benchmarks saved that show the performance gained by making this change, however using the page load timer in YSlow I have noticed that the time it takes for the “New Posts” search button to render page 1 has dropped from a rough average of  3.5 seconds down to an average of 2.5 seconds.  Any page that doesn’t have a lot of images hosted off site feels much faster now while browsing around.

If you have any questions about the tuning I’ve done please feel free to comment.  I will be sure to respond.  If you would like help tuning your vBulletin board I might be available to help with that as well.  The tuning techniques I’ve outlined in these three posts don’t just affect vBulletin users.  WordPress, Drupal, Joomla, and any other PHP, and MySQL based site will benefit from them.

With three fairly easy tuning techniques our vBulletin site is dramatically faster.  Next steps if deemed necessary will include adjusting table indexes in MySQL, and adjusting queries in vBulletin itself to make use of the indexes.  Be sure to check back for updates.

Thanks to: rmcgervey for the image

In part 2 of tuning a 1&1 VPS to improve vBulletin I installed an Op-Code Cache utility. Because PHP is an interpreted language using simply mod_php requires the code to be read, interpreted, and compiled on the fly each time a page loads. This doesn’t take very long on modern computers. However the more traffic your site gets obviously the more even milliseconds add up.

I looked at several Op-Code Cache utilities, and after some discussion with another tech decided not to use eAccelerator but rather APC. In part because of the simplicity of installation, and because it’s going to be included as a core part of PHP 6. I would like to thank @floris for this post on installing APC on CentOS

Below are benchmarks run using Apache Bench: ingo # ab -c 100 -t 5000 website.com/forums

APC disabled Performance:

Concurrency Level: 100
Time taken for tests: 53.368813 seconds
Complete requests: 50000
Failed requests: 0
Write errors: 0
Non-2xx responses: 50000
Total transferred: 28500000 bytes
HTML transferred: 15900000 bytes
Requests per second: 936.88 [#/sec] (mean)
Time per request: 106.738 [ms] (mean)
Time per request: 1.067 [ms] (mean, across all concurrent requests)
Transfer rate: 521.50 [Kbytes/sec] received

APC Enabled Performance:

Concurrency Level: 100
Time taken for tests: 33.140479 seconds
Complete requests: 50000
Failed requests: 0
Write errors: 0
Non-2xx responses: 50000
Total transferred: 28500000 bytes
HTML transferred: 15900000 bytes
Requests per second: 1508.73 [#/sec] (mean)
Time per request: 66.281 [ms] (mean)
Time per request: 0.663 [ms] (mean, across all concurrent requests)
Transfer rate: 839.82 [Kbytes/sec] received

As you can see our requests per second went up by 61% which is a pretty big deal. Also our mean time per request dropped. All in all for a fairly simple installation this was a worth while improvement.

In Part 3, we’ll discuss some extremely minor MySQL tuning I did which made quite possibly the biggest difference of them all as far as performance.

Thanks to: i_am_sam_lee for the image

A friend of mine runs a moderate sized vBulletin web forum. By moderate sized I mean in 12 months of being online he has 2,851 members, 18,257 threads, 206,904 posts, and an average number of online users that floats between 50 in the middle of the night, and 200 during peak hours, transmitting a daily average of 7gb of data.

About six months ago another forum member and I helped move the site off of “A Small Orange” shared hosting and on to a 1&1 Virtual Private Server. The performance boost was immediately apparent. Of course like any web forum we grew from just over 1000 members to 2000 members in 4 months, two months later another 800 members. Performance is still better than it was on ASO, but it was starting to suffer.

I fired up YSlow and determined that there were a fair number of efficiencies that could be gained by tuning some settings in Apache. Specifically by using mod_deflate & expires headers. The settings I added to /etc/httpd/conf/httpd.conf are as follows.

#Mod_Deflate Rules
# Netscape 4.x or IE 5.5/6.0
BrowserMatch ^Mozilla/4 no-gzip
# IE 5.5 and IE 6.0 have bugs! Ignore them until IE 7.0+
BrowserMatch \bMSIE\s7 !no-gzip
# IE 6.0 after SP2 has no gzip bugs!
BrowserMatch \bMSIE.*SV !no-gzip
# Sometimes Opera pretends to be IE with “Mozila/4.0″
BrowserMatch \bOpera !no-gzip

AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/atom_xml
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-httpd-fastphp
AddOutputFilterByType DEFLATE application/x-httpd-eruby
AddOutputFilterByType DEFLATE text/html
Header append Vary User-Agent

These settings alone lowered the daily average from 7gb down to 3gb! Mod_Deflate uses gzip to compress data by filter type. Older browsers aren’t able to read gzipped data. The first few rules at the top actually tell apache not to use gzip if the browser matches.

Next we turn on Header Expires. These add a header for all jpg, jpeg, gif, js, css, and png files that say the content expires and should be refreshed in April of 2010. This will hopefully tell browsers like IE, Firefox, and Safari to cache the files in their local store. Things like logos, navigation images, etc. don’t change often. Downloading them every time a page loads is wasteful.

<FilesMatch “(jpg|jpeg|gif|js|css|png)”>

Header set Expires “Thu, 15 Apr 2010 20:00:00 GMT”

</FilesMatch>

These are just two of the steps I’ve taken to improve performance of this vBulletin site. I will detail some of the additional changes in upcoming posts. If you have any questions feel free to comment. If you have suggestions on how I could improve these settings even further I’d love to hear from you as well.

Thanks to: Leff for the image