[drupal-devel] Drupal performance testing

[Moshe Weitzman]

you definately want to test with and node_access module like organic 
groups if you intend to use one in production. the presence of this sort 
of module adds some complexity to some key queries.

any large php site that dreams of being 'google fast' has to use an 
opcode cache application. see http://drupal.org/node/2603. this is the 
biggest bang for the buck improvement you can make. on the downside, it 
is rumored to segfault under certain conditions and i saw that a bit 
myself when uploading files into drupal.

> 2) We would like implement a better caching strategy.  We are aware  of 
> several implementations.  Once the site becomes an active  community of 
> posters caching become less useful.
> -We are planning on using Jeremy Andrews caching patch for testing.
> -We would welcome other suggestions.
>

I don't think there is a caching patch in the queue. just test with HEAD 
Drupal and you have our best effort. the traffic pattern matters a lot 
here. lots of registered users yields a far heavier load than lots of 
anon users (this is the slashdot scenario).

Drupal's highest performing cache setting is called 'Loose'. Any high 
traffic site will want this, so i see no reason to test otherwise. At 
one time, we thought that there must be a bug in its implementation 
because drupal.org was not experiencing a good cache hit ratio. In the 
end, I think we saw that some misbehaved crawlers and hosts were 
slamming the site and requesting many obscure pages not in the cache. 
One of them was AskJeeves! Lots of discussion starting with this post: 
http://lists.drupal.org/archives/infrastructure/2005-05/msg00123.html 
and conturing into the next month ... This sort of optimization really 
requires drupal knowledge and not just 'optimization experience.'

> 3)MySQL specific optimizations-  John Paul Ashenfelter is a very  
> experienced performance tuner and is heading up the scalability project.
> -We are interesed in MySQL cache optimizations.
> -In particular MySQL replication topologies as well as using the  Memory 
> table type for some of the problematic data.
> -If you have experience tuning large or high performance sites with  
> MySQL we would appreciate your insight.

i recently enabled the mysql cache on some of my sites and saw a big 
boost. i encourage folks to read an intro at 
http://dev.mysql.com/tech-resources/articles/mysql-query-cache.html. 
once you've enabled this, i think the DB becomes a minor performance 
concern. Of course that depends a lot on what modules you use and how 
much data you have (thousands of terms, thousands of users, etc.)