Benchmarking Drupal

WORK REMOTE FROM ANYWHERE IN US!!
3+ months
MUST HAVE experience working on high-profile projects for big brands/clients

QUALIFICATIONS
- A demonstrated ability to implement end-to-end custom Drupal sites
- Comfortable with custom module development
- Familiar with Drupal 6, particularly the updated views module
- Source control experience, particularly Subversion
- Facile with various methods of multi-site configuration
- Experience with the Services module as it pertains to Flash communication (AMFPHP)

This is a wiki to plan a module to allow admins to add indexes to their site schema - this can be done easily in Drupal 6 and beyond using http://api.drupal.org/api/function/hook_schema_alter/6 - this discussion came from http://drupal.org/node/231453, where it was realized that CCK does not really have the usage context to be able to do this effectively, and also there are tables beyond CCK getting used in new ways by views and other modules that also need alternate indexes.

This is easy and quick, nothing fancy, no voting - just post your session idea (title) and your name/contact info and show up to present that day! We have sessions open from 10am-2pm each day (Saturday and Sunday) and each session should plan for 45 minutes each.

http://groups.drupal.org/node/12528 (edit wiki page)

If you can't see or edit the wiki page, be sure to join our group which may be required for editing the wiki page.

I'm assuming it's too late, but if not here's an easy performance win for D6:

http://drupal.org/node/215080

<

blockquote>The type column of the {system} table is currently a varchar(255) field. Yet in 99% of all Drupal installations it stores either the text 'module' or the text 'theme' and nothing else. This is already a strong case for making it an int column and defining constants for module and theme. Then, on every page, there is this query:
SELECT filename FROM system WHERE name = 'user' AND type = 'module';

I'm assuming it's too late, but if not here's an easy performance win for D6:

http://drupal.org/node/215080

<

blockquote>The type column of the {system} table is currently a varchar(255) field. Yet in 99% of all Drupal installations it stores either the text 'module' or the text 'theme' and nothing else. This is already a strong case for making it an int column and defining constants for module and theme. Then, on every page, there is this query:
SELECT filename FROM system WHERE name = 'user' AND type = 'module';

OpenCraft hosted a 3.5 hour seminar that I presented on Drupal performance tuning and optimization. You can find the slides from the presentation there, which can be useful to some of you.

OpenCraft hosted a 3.5 hour seminar that I presented on Drupal performance tuning and optimization. You can find the slides from the presentation there, which can be useful to some of you.

I create a 5.2 and 6.x patch for measuring how much memory a module takes, and also how much the whole Drupal page load takes.

The results are published here: Measuring memory consumption by Drupal bootstrap and modules.

Short version: in Drupal 6, modules are better off than in 5.2, but the bootstrap is a tad larger.

If anyone is interested in replicating the results with more realistic install profiles, please do so and publish your results/findings/recommendations.

I create a 5.2 and 6.x patch for measuring how much memory a module takes, and also how much the whole Drupal page load takes.

The results are published here: Measuring memory consumption by Drupal bootstrap and modules.

Short version: in Drupal 6, modules are better off than in 5.2, but the bootstrap is a tad larger.

If anyone is interested in replicating the results with more realistic install profiles, please do so and publish your results/findings/recommendations.

I've released an in-development version of PressFlow Transaction for developers interested in convenient encapsulation of SQL transactions. The key features are intelligent use of scope for COMMITs and ROLLBACKs as well as safe, intelligent nesting of transactions to get exception-like semantics.

Usage details are on the project page. Requires PHP 5.

(I posted this to the High-Performance group because encapsulating updates in transactions can dramatically improve performance.)

I've released an in-development version of PressFlow Transaction for developers interested in convenient encapsulation of SQL transactions. The key features are intelligent use of scope for COMMITs and ROLLBACKs as well as safe, intelligent nesting of transactions to get exception-like semantics.

Usage details are on the project page. Requires PHP 5.

(I posted this to the High-Performance group because encapsulating updates in transactions can dramatically improve performance.)

Hello all,
Sorry for cross-posting; but I think people working on different aspects of Drupal may have interest in this idea.

I've submitted a SoC 2007 Drupal proposal on automating the whole process of creating a complete Drupal site with a LAMP stack in a self-contained virtual machine image. A formatted PDF version is here:
http://www.abeharry.info/SoC2007_DrupalAST_FullProposal.pdf
Here is the abstract:

The Drupal automated staging toolkit is a proposed set of code libraries, file schemas and parsers, and code generators, for

Hello all,
Sorry for cross-posting; but I think people working on different aspects of Drupal may have interest in this idea.

I've submitted a SoC 2007 Drupal proposal on automating the whole process of creating a complete Drupal site with a LAMP stack in a self-contained virtual machine image. A formatted PDF version is here:
http://www.abeharry.info/SoC2007_DrupalAST_FullProposal.pdf
Here is the abstract:

The Drupal automated staging toolkit is a proposed set of code libraries, file schemas and parsers, and code generators, for

I've just released two modules for developers and maintainers of performance-intensive sites. The first module provides a new, self-tuning, preemptive cache API for modules. It's called PressFlow Preempt. The second module (named PressFlow Preempt Panels) builds on the first by seamlessly offering cached versions of Panels.

I've just released two modules for developers and maintainers of performance-intensive sites. The first module provides a new, self-tuning, preemptive cache API for modules. It's called PressFlow Preempt. The second module (named PressFlow Preempt Panels) builds on the first by seamlessly offering cached versions of Panels.

Hi there, I have some interest in building a Drupal becnhmarking suite that can be used for testing the impact of newly proposed patches on our beloved content managemanet framework.

Hi there, I have some interest in building a Drupal becnhmarking suite that can be used for testing the impact of newly proposed patches on our beloved content managemanet framework.

One thing I would be really interested in seeing is a benchmark suite run on the current drupal.org installation, and then again once it's upgraded to 5.0. Is this something that could be done or is being planned? It would be an underestimate of performance gains to the extent that certain performance patches are applied directly to d.o when fixed in core.

Performance upgrades from the CHANGELOG include:

One thing I would be really interested in seeing is a benchmark suite run on the current drupal.org installation, and then again once it's upgraded to 5.0. Is this something that could be done or is being planned? It would be an underestimate of performance gains to the extent that certain performance patches are applied directly to d.o when fixed in core.

Performance upgrades from the CHANGELOG include:

Inspired by Dries posting on the powersavings one can get by having a system run on low CPU usage:

Say we would make a test with 1k nodes in Drupal and Joomla? and run JMeter with the same parameters on it against both. Both would be optimzed for caching.

It would be nice to make some MRTG/RRD stats on it with using the MIBS of Watts used and CPU's cycles burned. Then we can show that Drupal will burn less cycles and is in fact environmental friendlier then Joomla?.

Inspired by Dries posting on the powersavings one can get by having a system run on low CPU usage:

Say we would make a test with 1k nodes in Drupal and Joomla? and run JMeter with the same parameters on it against both. Both would be optimzed for caching.

It would be nice to make some MRTG/RRD stats on it with using the MIBS of Watts used and CPU's cycles burned. Then we can show that Drupal will burn less cycles and is in fact environmental friendlier then Joomla?.

I made an attempt at starting some documentation around benchmarking code:

http://drupal.org/node/79237

Reviews/Additions would be appreciated. :)

I made an attempt at starting some documentation around benchmarking code:

http://drupal.org/node/79237

Reviews/Additions would be appreciated. :)

I've posted on standard benchmarking information before (with no responses...) in the performance and scalability forum which is a pretty good source of information in general.

I've posted on standard benchmarking information before (with no responses...) in the performance and scalability forum which is a pretty good source of information in general.