[drupal-devel] Drupal performance testing

[Gerhard Killesreiter]

On Thu, 18 Aug 2005, Kieran Lal wrote:

> 1) First we would like to reduce the memory requirements of running
> Drupal so that we can run more Apache processes.
> -Please advise if there are particular configurations of Drupal that
> you recommend to reduce memory usage.
> -Are there particular contributed modules that we should avoid
> because of memory issues.  We are looking at flexinode, event,
> location, and event finder, as well as organic groups.
> We are looking at Robert Douglas and Mike Gifford work on memory
> profiling:  http://cvs.drupal.org/viewcvs/drupal/contributions/
> sandbox/robertdouglass/profiler/, and http://lists.drupal.org/
> archives/drupal-devel/2005-08/msg00314.html
> http://lists.drupal.org/archives/drupal-devel/2005-08/msg00347.html
> http://lists.drupal.org/archives/drupal-devel/2005-08/msg00344.html

All enabled modules are loaded for registered users, therefore the less
big modules you have the better your memory use pattern.
The ultimate memory use pattern is probably attainable through Karoly's
split patch. Or no modules. ;)

> 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.

That patch is in core and has not really proven it is usefull for
drupal.org, but it apparently is for other setups (kerneltrap).

> -We would welcome other suggestions.

I had suggested to base the invalidation of caching on whether the
new version of a cached page is actually different from the cached page.
The problem is that now the cache is invalidated each time somebody
posts a comment or a new node. This posting does however not
neccessarily make the node/nnn page of another node look any different
unless there is a block that lists new posts or new comments.

A change that would be needed for such an improved caching system is the
block configuration to return the path patterns where a particular block
appears and to introduce a cache hook into modules because modules know
best if the content or views of content they provide changes by a
particular new post and can then invalidate the cached pages or not.

Unfortunately Dries has rejected this proposal as "won't work" without
giving detailed reasons.

Since I don't run high performance sites, I do not have a personal itch
to scratch and didn't develop the approach to a patch.

> 3)MySQL specific optimizations-

Moshe's suggestion about MySQL cache looked very interesting.
Unfortunately the cache probably will increase MySQL's memory usage even
more.

Cheers,
	Gerhard