UnixGuys

Part 3: Tuning a 1&1 VPS to improve a vBulletin board.

HKP30 — Sun, 22 Feb 2009 03:35:19 +0000

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.

BookMarkMe

Part 2: Tuning a 1&1 VPS to improve a vBulletin board.

HKP30 — Sun, 22 Feb 2009 03:35:13 +0000

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.

BookMarkMe

Part 1: Tuning a 1&1 VPS to improve a vBulletin board.

HKP30 — Sun, 22 Feb 2009 03:35:07 +0000

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.

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

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.

BookMarkMe

Configuring CentOS to use NTP

HKP30 — Thu, 11 Sep 2008 16:57:01 +0000

There are a number of reasons you might want a server to use NTP not the least of which is a desire to synchronize the clocks on multiple systems so that times/dates in logs line up. I finally got around to configuring NTP on our H-Sphere server. The process is pretty simple on CentOS.

First Install the NTP Package on your server as root.

[root@cp ~]# yum install ntp

Loading “fastestmirror” plugin
Loading mirror speeds from cached hostfile
* base: mirror.steadfast.net
* updates: mirrors.liquidweb.com
* addons: pubmirrors.reflected.net
* extras: pubmirrors.reflected.net
Setting up Install Process
Parsing package install arguments
Resolving Dependencies
–> Running transaction check
—> Package ntp.i386 0:4.2.2p1-8.el5.centos.1 set to be updated
–> Finished Dependency Resolution

Dependencies Resolved

=================================================================
Package                 Arch       Version          Repository        Size
=================================================================
Installing:
ntp                     i386       4.2.2p1-8.el5.centos.1 base              1.3 M

Transaction Summary
=================================================================
Install      1 Package(s)
Update       0 Package(s)
Remove       0 Package(s)

Total download size: 1.3 M
Is this ok [y/N]: y
Downloading Packages:
(1/1): ntp-4.2.2p1-8.el5. 100% |=========================| 1.3 MB    00:19
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
Installing: ntp                          ######################### [1/1]

Installed: ntp.i386 0:4.2.2p1-8.el5.centos.1
Complete!

Next set it to start automatically on a reboot

[root@cp ~]# chkconfig ntpd on

Tell it which NTP server it should update it’s time from

[root@cp ~]# ntpdate pool.ntp.org
4 Aug 12:32:43 ntpdate[9540]: step time server 64.202.112.75 offset 1256.453048 sec

Verify that the Time & Date are correct

[root@cp ~]# date
Mon Aug 4 12:33:04 EDT 2008

Finally start the service

[root@cp ~]# service ntpd start
Starting ntpd: [ OK ]

Easy as could be. If you set all of your servers to update their time from the same pool server your time will be accurate within two seconds or better. If you update one server to the pool, and tell all the rest to update from your own NTP server time can be even more accurate. I don’t need that level of accuracy and tend to just use the pool.

BookMarkMe

CentOS 5.2 & Configuring MTU

HKP30 — Mon, 21 Jul 2008 16:04:03 +0000

We have one server in our office that performs very few functions. In fact its lone reason for being on the network is to allow one of our customers to GET and POST data into the lease management system the company I work for runs. The customer requested some kind of web server to manage the GET and POST procedures. We established a site to site VPN, secured access to and from the LAMP server between four hosts on their network (two development, one production, and one disaster recovery) and our LAMP server. (It’s named LAMP. It also happens to be a L.A.M.P. server)

All seemed to be working well. Until at some point the customer noticed that certain types of traffic just didn’t work to/from the server. As it turns out because of the IPSEC VPN, and encapsulation we needed to adjust the MTU on both ends of the link.

If you are ever using a CentOS 5.2 server, and you want to adjust the MTU to something other than the default with that change surviving reboots of the server you need to do the following.

vi /etc/sysconfig/network-scripts/ifcfg-(interface)

add a line that reads.

MTU = (some number less than 1500 here)

save and exit the file. Now if you would like to make that change take effect right away. You can either… /etc/init.d/network restart OR…. ifconfig (interface) mtu (some number < 1500)

Clear as Mud eh?

BookMarkMe