The real way to improve server performance

If you want to improve server performance, the best way is to move as much of the processing off it and onto the client machine. All those visitors of yours are running souped up AMD and Intel CPUs with their big screens and fat harddrives. No wonder your small little hosting plan can’t keep up. Here are some very good ideas from a Slashdot comment I read this morning.

  • Databases can get pretty slow with complicated queries, so upload your database to the client when they load the page and then your database queries are distributed.
  • PHP isn’t very fast, and neither are Perl or Python, so you don’t want to be running them on the server either. Write an interpreter for the language of your choice in Javascript and move your business logic to the client. This will also interface better with the client side database copy.
  • SSL is a performance killer, don’t use it. If you need to send something securely just prefix it with a predetermined number of random letters and numbers, no one will think to look beyond them.
  • Writing to databases can be pretty bad too. Try discarding all your changes, your users might not notice the difference, but they will appreciate the performance gain.

Check out the original post for a few more invaluable nuggets. If you follow all these tips you’ll be well on your way to becoming a respected and l33t hacker.

And now the big news. I’m really excited about this. The next version of WordPressMU will have a special Javascript client-side db (JCSDB) library built in. JCSDB will enable distributed and parallel access to your WPMU db without the danger of harming your servers. The best thing about it? If your site is dugg or slashdotted then your visitor’s machines will handle the load transparently. Instead of using slow and ungainly TCP/IP the library will use super-quick UDP to communicate. It really is the best way of sending data over the Internet.

I expect Matt will roll out JCSDB on WordPress.com just as soon as a few of the final bugs are ironed out. It might be a bit of headache for Barry and Demitrious to administer, but at least we can get rid of at least half our servers and use them to power a massive game of Counter Strike at the next WordCamp.

Update on May 31st! You all thought this was a joke didn’t you? Well, Google Gears has just been released and “is an open source browser extension that enables web applications to provide offline functionality”.

  • Store and serve application resources locally.
  • Store data locally in a fully-searchable relational database
  • Run asynchronous Javascript to improve application responsiveness.

It’s still in beta but Google Reader already supports it by allowing you to download up to 2000 items to read offline. This could be useful when I’m flying to SF next July!

Cannot load mysql extension. Please check your PHP configuration.

A friend recently had a problem configuring a new server. He installed PHP, Apache, MySQL and phpMyAdmin but when he launched it he got the following error:

phpMyAdmin – Error
Cannot load mysql extension. Please check your PHP configuration.

If you’ve installed all of the above more than once you’ll know what is more than likely wrong. The MySQL PHP module isn’t loaded. First of all, you must find your php.ini. It could be anywhere but if you create a small php file with the phpinfo(); command it will tell you where it is. Common places include /etc/apache/, /etc/php4/apache2/php.ini, /etc/php5/apache2/php.ini or even /usr/local/lib/php.ini

Edit your server’s php.ini and look for the following line. Remove the ‘;’ from the start of the line and restart Apache. Things should work fine now!

;extension=mysql.so

should become

extension=mysql.so

Killing off PHP

Do you know why Apache processes get stuck and stop responding when serving pages on a WordPress site?

I’ve seen this happen here and on my previous host on a regular basis. I don’t know what happens. It can’t be a PHP script gone into an infinite loop because the normal Apache timeout should kill it. It’s not MySQL as a quick inspection of the process list usually shows it’s empty.

It could be plugins, some of them haven’t been written to the high standards that is expected in WordPress core. It could be some strange interaction between plugins and core code and memory limits and PHP extensions.

Whatever causes it, this will fix it. It’s brutal, it’s crude, but it’ll stop the load average going up on your box and it will ensure that every Apache child process is listening and responding. Add this to the crontab of your nobody or www-data user. Pick whichever user runs the webserver because you want to limit the damage in case something bad happens and the command malfunctions!
*/10 * * * * ps auxw|grep apache2| awk '$10 !~ /0:00/ {print $2":"$10}'|awk -F ':' '$2 !~ 0 {print $1}'|xargs kill -9 2> /dev/null
What this does is it uses the ps, grep, and awk tools to find processes that are using anything more than the minimum CPU time. It is very crude, but it works.

If you use Litespeed, then replace “apache2” with “lsphp”. I have found that this is very necessary as those processes get stuck quite often, especially in low memory situations.

Gzip Compression or No?

mod_gzip, zlib.output_compression or whatever way you compress your web pages is a great way of reducing your network traffic costs but comes at the cost of increased CPU usage. Despite what you might think, it can be more expensive to send data over the network, especially to slow clients than compress it first of all and send a smaller burst.

Unfortunately this little server may not be up to the task of gzipping content at an acceptable rate to make it worthwhile. I’ll leave it run for another few hours and check the stats tomorrow.

Stopping the spam after moving house

A few weeks ago I moved this blog to this new location but left a 301 redirect on all URLs on the old site. That has worked great to direct traffic here but unfortunately it has also redirected all the spam attempts on my old site to here too. Thankfully they’re not much of an issue because the POST information is lost but it’s annoying seeing them appear in the logs.

Thanks to the wonders of mod_rewrite it’s possible to stop those guys before they hit any PHP script. My blog was originally at http://blogs.linux.ie/xeer/ and of course, the new site is http://ocaoimh.ie/. There are two way of stopping those requests:

  • On the new server, add the following lines to the .htaccess of the virtual host:

RewriteCond %{HTTP_REFERER} ^http://blogs\.linux\.ie/ [NC]
RewriteRule ^wp-comments-post.php – [F]

  • Or, on the old server add this to the .htaccess there:

RewriteRule ^xeer/wp-comments-post.php – [F]

The latter rule is the preferred method and I haven’t seen any request come through since I added it in!

If you’re interested, here are the simple rules I use to redirect every url of my old blog to this site:

RewriteRule ^xeer/images/(.*) http://ocaoimh.ie/xeer/images/$1 [R=301,L]
RewriteRule ^xeer/(.*) http://ocaoimh.ie/$1 [R=301,L]

Adapt to suit your own environment.

Debian Sarge, PHP4 and Apache2.. why do you persecute me?

Oh FFS! Has anyone had a problem with Apache2 and PHP4 on Debian Sarge/Testing? I have a stock install of it with nothing unusual AFAICT but Firefox keeps trying to download and save php files instead of processing them. All the config files seem to be correctly set up. Files in mods-enabled/ are fine.
Why am I upset? I added the wp-newblog.php to WPMU SVN tonight, imported a chunk of code from install.php so it’s a one-step process, but I can’t test this thing to see if it works! It’s here as a WPMU snapshot but it won’t work out of the box. It needs an entry in .htaccess first, and bug fixing.

I’m off to relax, it’s been a long day.. zzzz

Much Later… I finally got it working again. I tried dpkg-reconfigure phpmyadmin but it didn’t update the config file with this error:

Not replacing deleted config file /etc/apache2/conf.d/phpmyadmin.conf

Following the clues from here I did the following:

apt-get remove –purge libapache2-mod-php4
apt-get remove –purge apache2
apt-get install libapache2-mod-php4 phpmyadmin

PHPMyAdmin now works fine, and hopefully wpmu will too!