What I’m Running

Here’s a rundown of what sites I’m running and the software used.

• beplacid.net – Apache 2, Django (Python framework), MySQL (one instance)
• blog.beplacid.net – PHP 5, MySQL, WordPress
• readingcamra.org.uk – Apache Tomcat 6, Java 5, MySQL
• readingbeerfestival.org.uk – As above

Wget – the Swiss army knife of HTTP command line tools

Wget’s one of those tools you really take for granted. It’s versatile, reliable, simple and most importantly – it does its job very well. One of its nicest features is the –mirror option. This allows you to…mirror a given website. I initially thought of running multiple instances of wget at the same time. I started small at first: one instance running to mirror the entire site. I ran the following in a shell:

alex@prometheus:/tmp$ wget –mirror beplacid.net/

It’s simple: mirror beplacid.net. Watching the processes and CPU usage on the server, it became apparent that  this wasn’t going to do much. The CPU usage didn’t exceed 5% on its first core. I had to rethink. Then ab sprung to mind.

ab – Apache benchmarking tool

This is another useful tool. It’s simple to use and allows you to quickly and easily hit a given hostname with HTTP requests, all tailored to your specific needs. To do all this, however, you need to be running as root. A noble security measure.

I wanted to generate some traffic that would put the server under some strain, so I started with 50 requests and 5 at a time:

prometheus:/root$ ab -n 50 -c 5 beplacid.net/

Now things started to get fun. This peaked CPU usage to 94% on one core, the others were between 60 and 80. I was starting to see some real stats. I doubled things – 100 with 10 per request:

 prometheus:/root$ ab -n 100 -c 10 beplacid.net/

This was a little more representative of a heavy amount of traffic. Perhaps akin to slashdot or a reddit. Put simply, that’s 100 requests with 10 each sent each time. Still nothing major, so I went all out:

Concurrency Level:      10
Complete requests: 1000
Total transferred:      4856792 bytes
HTML transferred:       4687792 bytes
Requests per second:    4.99 [#/sec] (mean)
Time per request:       2002.453 [ms] (mean)
Time per request:       200.245 [ms] (mean, across all concurrent requests)
Transfer rate:          23.69 [Kbytes/sec] received

To summarise, the server took 1000 requests with an average of 5 per second, each returning just over 2 seconds. Not bad, considering what I’m running.

I’m pleased with my setup. It can take a punch and it’s still running. My next task is to hit both beplacid.net and the blog, with perhaps some traffic mirroring readingbeerfestival.org.uk too.

Migration

To move from my old host, a VPS solution running on UML, requried moving two sites – beplacid.com (now beplacid.net) and forallthewrongreasons.co.uk.

Both sites were using Apache 1.3, PHP4, Python 2.4 and MySQL 5. As well as those applications, beplacid.com was using WordPress and Mediawiki which were installed manually. My first requirement was to have these packages administered by apt, and not by myself; manual installation and administration of webapps can be an added pain. Especially if you’re not hot on the security vulnerabilities.

MySQL Data Migration

This was relatively simple, as I had daily exports of all databases. It was simply a matter of ‘apt-get install mysql-server’ on the new host, then ‘mysql -u root -p -h localhost < extract.sql’ and I had my databases back up and running on the host. There were some application-specific changes needed, namely the hostname settings etc, but these were all configurable within the individual applications.

Apache 1.3 to Apache 2

I had been running Apache 1.3 for over a year. It has served me well, and i’d never think twice when considering what HTTP server to use. That said, I thought it’d be a good time to bring myself into modern times by upgrading to Apache 2.

I was originally reluctant to do so at first because of the (assumed) differences in configuration. Thankfully this was not the case, and once i’d had my DNS servers setup (thanks to Slicehost and their excellent bespoke account management software, I can do this all myself), I had the main domain and sub-domains setup.

Another reason for upgrading to Apache 2 was the need for a bandwidth control module. Mod_Cband allows you to control the remote speeds, maximum bandwidth usage per period, and many many more. I needed this to control the usage of downloads from el.beplacid.net, which is the brunt of my bandwidth usage.

All in all, a rather painless experience.

Upgraded VPS – Slicehost.com

Slicehost was recommend by a friend, Alex Smith. My previous VPS solution was a UML based Linux server running Debian. Though the host itself was adequate, I had recently suffered downtime due to what I can only guess, were issues with the 2.6 series kernels and UML. Not only that, the servers offered by Slicehost are not only running on better hardware, but have much better prices.

The first thing that struck me about slicehost was the basic but well written website. It’s informative from the start, so it’s not hard to start liking them. I was further enticed to buy when I read the hardware specs:

• 2 AMD Opteron (?) 64Bit dual-core processors
• 1GB of RAM
• 40GB of hard disk space

As an addendum, the specs of my VPS beat the machine i’m currently writing on. Not much perhaps, but slightly ironic…

Another point to mention is the community aspect of slicehost. They provide a blog, wiki (mainly for customers to use when debugging issues with their slices), and their IRC channel #slicehost on irc.freenode.net. It’s great to talk to other ‘slicers’ when you’re bored and more importantly to get quick answers when you need to (and indeed provide assistance to others).

My only gripes are not being able to pay via PayPal (I don’t use credit cards) and there being no option for unlimited bandwidth – something which I liked about my previous host.

So, here we are. A new server and potentially new things to serve. Overall a very pleasing migration and a very satisfied customer. Cheers Slicehost!

On a previous post (title The Perils of MySQL), I stated how frustrated I was with MySQL at the time. My problems seem to have disappeared for the time being, with only one case of MySQL falling over since I previously posted about it (sod’s law!). One of the first steps to debugging the issue was to enable logging in the /etc/mysql/my.cnf file by uncommenting (removing the hash at the start of the line) the following line:

#log		= /var/log/mysql/mysql.log

However, once I had done that I was not getting any issues whatsoever; coupled with a recent update to MySQL 5.0.32-3 from Debian and I don’t seem to have the issues anymore – which suggests it might be fixed by proxy, as it were. I’m not entirely convinced however.

During my initial investigations (at the time of my original post), I received an email from Sheeri of sheeri.com and technocation.org who suggesting a possible solution to my problem, you can read that email here (aspects of this email have been removed for privacy reasons). Essentially, her suggested fix is to check the data files located under /var/lib/mysql/ (or the path specified by innodb_data_home_dir in /etc/mysql/my.cnf) that begin with ibdata and check that their owner has read/write/execute (octal 7) permissions for those data files.

Although the solution didn’t work to me, i’d like to thank Sheeri for taking the time to respond to my blog, and I have decided to post it here for others that may find it useful!

On an unrelated matter, does anyone know what happened to Debian Etch being released in March?…