iSpot & EML project blog

After the site’s poor performance when it was mentioned on Springwatch I spent a large amount of last week trying to track down the reasons behind it and to rectify them. The problems seemed to stem from connecting to the database server. This in turn was the result of two things combined, the configuration of the database server and a few specific tables in the database being slow to return results.

The actions I’ve taken so far to resolve these issues on the database are:

• using a different configuration of the database server which is tailored to more powerful servers.
• setting up a memory limit for the database query cache to allow this cache to start to be used.
• examining the slow tables in the database and adding indexes where needed to improve their response times.
• upping the maximum connections that the database allows to it by a factor of 10.

On the website side of things I’ve done the following:

• implemented caching where possible using Drupal’s caching mechanisms.
• changed the way Drupal connects to the database server to make use of persistent connections in PHP.
• making sure PHP’s maximum connections to the db reflect those allowed.

With these measures in place the site seems to be responding quicker and I am very confident that the site is much more able to handle increased load, the question is how much?

The next steps are for me to set up profiling on the site so we can start to get an idea of any issues that have yet to be addressed and then in the coming months to arrange load testing to see just how much the site can handle. This will need to be scheduled in to make sure it’s carried out with the lowest impact on users and course students for all courses reliant on the web server.

This is more of a reminder to myself in case this slips my mind at some point in the future.

The BeautyTips module that I’m using for creating the help icon popup uses an external library called ExplorerCanvas to allow it to work in IE.

I’ve just found that IE 7, and probably the earlier ones too, have a limit on the number of CSS documents that can be imported into a document, this limit is 31. This then means that IE 7 can throw a javascript error if the javescript is trying to use createStyleSheet() which in my case happens on line 112 of excanvas.js. This will only be a problem in the development environment where CSS optimisation is disabled. The live site has this enabled and so there should never be a large number of CSS documents being importedand so no problem.

This is really just a note to myself, but I thought I’d put it on my blog in case anyone else is interested.

By running a local version of Symfony per project it allows different projects to run different versions of Symfony, which means not having to worry about upgrading already stable sites (like the MegaLab) when trying out the latest version of Symfony for a new project (like the Bio-Obs).

So to set up a local version of Symfony 1.1 using SubVersion:

1. create your project directory – C:\sites\my_project (this can be where ever you choose)
2. create a directory for the core Symfony files – C:\sites\my_project\symfony-1_1 (again you can name this what you like)
3. checkout the Symfony 1.1 files to this directory from http://svn.symfony-project.com/branches/1.1
4. now from the DOS prompt change to the project directory – >cd C:\sites\my_project
5. then to set up the initial project structure use the usual ‘init-project’ command but reference the symfony command from the core files – >c:\sites\my_project\symfony-1_1\data\bin\symfony init-project my_project
6. after that when you change to the project directory from the command prompt you can just use Symfony as normal – >symfony init-app frontend