Deprecated - Performance and scalability

As I get to them, I'm remembering site-killing things it took me hours or days to find, and placing them here where you can find them :)

http://drupal.org/node/22035 explains how Drupal 4.6 does something seriously wonky with paths, and provides enough information for you to patch it manually.

The issue no longer exists in 4.7. And you're unlikely to run into it unless you have a lot of nodes with aliases.

Here are the results of some benchmark tests that I have been running to compare the performance of a shared server with a dedicated one. Perhaps they will be useful to somebody that is trying to decide what hardware they need to host a new site:

All tests were done with Drupal 4.6.5, PHP4 and MySQL using "siege" (see http://www.joedog.org/siege) to establish a certain "base loading level" and the apache benchmark tool "ab" to generate timing statistics.

The exact commands used were like this:

siege -c 32 -i -t 11m -d 5 -f url_list.txt

This simulated 32 concurrent users all requesting random pages from a list of URLs, with a 5 second delay after each page (to simulate the user reading the page). This was set to run for 11 minutes. After about 30 seconds I fired off the "ab" command in a second terminal:

ab -c 1 -t 600 http://server/page.htm

This would request the same page for 10 minutes & collect timing statistics.

Tests were repeated for varying lengths of time and for different numbers of simulated users. I was only really interested in the maximum practical number of users, so I'll only show those results:

On the shared host (supplied by oneandone.co.uk), with cacheing enabled, the maximum practical number of users was about 16. This gave an average page load time of 3.71 seconds, with 95% of pages loading in 5.07 seconds or less. With 32 simulated users the average load time was 8.51 seconds, with 25% of pages taking over 10.2 seconds, which was clearly too much. With cacheing disabled, to simulate "logged-in" users, performance dropped badly after only 4 users! (Note: this was done over a 1Mbit ADSL connection. With 32 simulated users still only 1/2 the available bandwidth was being used, so that shouldn't have been a limiting factor.)

We all know that flexinode is a nice module, providing a lot of site admin flexibility with no need for programming.

Two objections to flexinode are :

1. It will eventually be replaced by CCK (content module?) in 4.8 or later (what is the current estimate on this anyways?)

2. Because it has to use multi-way joins, it can be resource expensive on a busy site. This is why sites like BuyBlue and ProjectOpus did not use flexinode.

With Roadsend compiler you can create a binary version of your PHP code and apparently gain significant performance benefits. I'd be really interested in hearing whether anyone has tried this with Drupal, and what the benefits or disadvantages of such an approach would be over a PHP cache.

First off I'm obliged to offer a pre-emptive apology for the 'considered harmful' part of the title.

MySQL's reputation for being a 'toy' database, an opinion held by lots of database snobs, might be something which relates to its default storage engine, not to the server as a whole.

I'd like to introduce forum searchers to this thread from the Development mailing list on Drupal caching, MySQL's MyISAM storage engine, and sites which change a lot (like, for example, ones with busy forums):

If using the archive core module, a spider can really slow down a drupal site, by recursively following the "previous month" links on the archive calendar.

I saw that recently (a few Gigs of extra bandwidth during 48h, 90%cpu...), and it's very annoying. That's why I posted the following bug report,
Archive "back" links dangerous for spiders and robots.