Here is a summary of advice: 1. Memory profiling. -Look at the size of the code in a module -Look at Robert Douglas's profiler module: http://cvs.drupal.org/ viewcvs/drupal/contributions/sandbox/robertdouglass/profiler/ -Look at Karoly's split patch: 2. MySQL -Try MySQL memory Cache -Implement MySQL replication topologies to support more postings 3. Caching -Get a better heuristic for cache_clear_all() function than ignoring 19 out of 20 calls. -Get results from Jeremy Andrews fuzzy logic caching patch -Get an experienced Drupal Admin to look at the traffic patterns. You might have a rogue crawler searching everything and not taking advantage of your caching. 4. PHP tools -Use the opcode cache: http://drupal.org/node/2603 -Test eaccelerator: http://eaccelerator.net/ 5. Drupal specific - Test node access with Organic Groups under a heavy load -Consider Gerhard's idea to base the invalidation of caching on whether the new version of a cached page is actually different from the cached page. Get block configuration to return the path patterns where a particular block appears and to introduce a cache hook into modules. Cheers, Kieran On Aug 18, 2005, at 5:07 PM, Kieran Lal wrote:
Hello, we, Trellon and CivicSpace Labs, are doing Drupal performance testing for a client. We will be sharing the results with the community. We identified three areas to focus on for performance testing.
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
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.
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.
We are looking at results from RPMs that have been turned for scalability and security as defined here: http://www.sourcelabs.com/ SourceLabsApacheMySQLPHPTestResults.pdf. This tells us that our limitations are processors for PHP support and RAM for MySQL support in the testing environment.
As always we need technical savvy people who can help with documentation or are willing to help produce diagrams to prove to potential users that Drupal can scale.
Your help and comments are appreciated.
Kieran