[drupal-devel] Drupal performance testing
kieran at civicspacelabs.org
Tue Aug 30 23:23:29 UTC 2005
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/
-Look at Karoly's split patch:
-Try MySQL memory Cache
-Implement MySQL replication topologies to support more postings
-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.
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/
> 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
> -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.
More information about the drupal-devel