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