[drupal-devel] Drupal performance testing

[Kieran Lal]

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