The Conk

Day 2 of the Lullabot Advanced API Workshop concentrated on FormAPI stuff, security, and addition module hook API information.

The FormAPI section included a good overview of the form life cycle and shed a lot of light on what goes on behind the scenes. We also spent some time on multi-step form handling in Drupal 5.1.

Security focused mostly on what you need to do in your code to avoid XSS and SQL Injection attacks it also helped clear up when you don't need to sanitize your data.

Good stuff.

Here are some pictures from day 2.

Inside the Music Mansion - eaton and webchick making the magic happen.

The Music Mansion

Drupal 5.1 was released today. It fixes a highly critical remotely exploitable security issue.

Does The Conk seem to be a little faster today?  It is probably just your imagination, but it might also be due to some PHP and MySQL tuning that I did tonight.

Read about it in this blog post.

Since the Drupal installation was so simple, I never gave much though to any performance optimizations that could be done - other than the standard Drupal page caching and the new CSS aggregation options.  But tonight, after installing Drupal on a web hosting service that I have had for awhile and never did much with - and noticing the horrible performance (probably due to a slow network connecting the web server to the MySQL server), I decided to explore if there was anything that could be done to improve performance.

The first thing I looked at was a PHP accelerator.  After a quick search, I settled on eAccelerator. After installing it (using NetBSD's pkgsrc system - cd /usr/pkgsrc/www/php-eaccelerator && make install), I simply added the following to my php.ini file:

extension=eaccelerator.so
eaccelerator.shm_size="16"
eaccelerator.cache_dir="/tmp/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"

After restarting Apache, the number of Conk front pages that could be served per second doubled from 16.95 to 36.75 pages per second, as measured with the Apache 'ab' utility (32 concurrent users).  Pretty impressive for 5 minutes of work...

My next idea was to move the MySQL database off of the web server and onto a faster machine on my network.  This server is only a 933MHz Pentium III with 512MB of RAM, and I thought that Drupal's heavy use of the database might be limiting performance.  After moving the server, the speed increased to 46.25 pages per second.  Pretty good, although the improvement might not be enough to justify making this site dependent on two servers instead of just the one. 

Then I began to google for MySQL tuning tips.  There was a lot of good information out there, but I ended up just copying someone's my.cnf file, as shown below:

[mysqld]
skip-innodb
max_connections = 500
key_buffer = 16M
myisam_sort_buffer_size = 64M
join_buffer_size = 1M
read_buffer_size = 1M
sort_buffer_size = 2M
table_cache = 1024
thread_cache_size = 64
wait_timeout = 1800
connect_timeout = 10
max_allowed_packet = 16M
max_connect_errors = 10
query_cache_limit = 1M
query_cache_size = 32M
query_cache_type = 1

[myisamchk]
key_buffer = 64M
sort_buffer = 64M
read_buffer = 16M
write_buffer = 16M

After restarting the MySQL server, the performance was 45.27 pages per second - comparable to what I was seeing with the external, faster db server.

So without any hardware changes and almost no work, I was able to greatly improve the performance of this server, as you can see in this table. 

Edit: This above numbers were with 32 concurrent simulated users, which is probably a little unrealistic for this site.  Using 4 concurrent users, the eAccelerator + MySQL tuning on same server times were 54.30 pages per second and 73.67ms for time per request. 

Well, it was! See?!?

I've updated The Conk to the latest 5.0 version, 5.0 RC1. The most interesting new feature is the CSS Preprocessor. This merges all of the 15+ CSS files that a typical Drupal page load incurs into a single packed file. So not only is the overall transfer size reduced, but there is considerable less HTTP traffic and the result is significantly faster page load times.

I have updated the site to use the latest version of Drupal version 5.0, directly from the CVS HEAD.

The update process was fairly painless, except I didn't fully backup the database beforehand and the first attempt failed, leaving both Drupal 4.7.4 and 5.0 unusable.  Fortunately I had a nightly backup to restore from, and the second attempt went much better.  The only other issue was that my selected theme wasn't available in 5.0, so when I loaded up the new site, it looked completely messed up - no menus or other blocks.  Other than freaking me out for a few moments, that was easily fixed.

Most of the (few) modules I was using in 4.7 are either already on the Drupal Modules page or were already updated in CVS

So all in all, it is nice to be at 5.0.  The new administration menu system is much nicer than in 4.7, otherwise, I haven't noticed a huge difference so far.