On Wednesday 01 August 2007, Dries Buytaert wrote:
Hello world,
I provided a list of what I believe are the top-6 most important performance patches for Drupal 6 and drupal.org (which will run on Drupal 6). If you know people that want to help, please point them to http://drupal.org/node/163216#comment-257631 or wherever the latest version of that list continues to live on.
The slowest queries on drupal.org are the ones for (1) the tracker page, (2) the forum blocks, (3) the forum topics' next/previous links and (4) the search module. Since we disabled most of those features, drupal.org is again more usable. Of course, we want to re-enable all of those feature as soon as possible.
To make that happen, we need help from developers and database experts. To provide some focus, I compiled a list of the 6 most important performance patches that you can help with. I truly hope to get some of these into Drupal 6, and to backport them to Drupal 5 so we can use them on drupal.org until we upgrade drupal.org to Drupal 6.
Important note: these patches are still allowed to change the APIs in Drupal 6, and are about the _only_ patches that can break our APIs before Drupal 6 beta 1 is released. This policy will hopefully help us focus -- these issues is where all of our Drupal core action should be.
So here is the list:
1. http://drupal.org/node/147160 - Database replication: database replication will help us distribute the load among multiple database server. This will help us with (1), (2), (3), (4) and more. Without this patch, we can't even take advantage of the extra hardware that we're installing. Needless to say, this patch is critical. Some extra background information and thoughts are available at http://buytaert.net/scaling-with-mysql-replication.
Dries, to clarify here: There's two different approaches currently listed in that issue: A) db_query_slave() syntax B) array-with-parameter syntax. A is currently running on s.d.o, while B is closer to what I am hoping to use for Drupal 7[1]. In the issue you mentioned that you were concerned about the array handling in B. Do you mean the API or internal $args shuffling? I want to make sure I'm working on the correct problem. I see 3 options on the replication API front: 1) Use A in Drupal 5.3 and Drupal 6, and switch to B as part of the overhaul in Drupal 7. 2) Clean up whatever the remaining objections are to B and use that now so there's less API change later. 3) Use A now and drop B completely, keeping A come Drupal 7. (Not good for D7's API, IMO.) I want to make sure we're on the same page as to the approach so that there's no wasted effort. Which are we doing? :-) [1] http://www.garfieldtech.com/blog/drupal-7-database-plans -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson