I did some experiments that can help us understand and improve Drupal's database interaction:
http://buytaert.net/drupal-database-interaction
From the looks, there is some stuff that can be optimised. :)
-- Dries Buytaert :: http://www.buytaert.net/
Taking up the challenge, I've made a start on looking at optimisation. For those interested in this subject please look at my first "report" at http://spiders-lair.com/node/23 (is there a better place for me to post articles like this?) I'd rather get feedback from those "in the know" before I start going down a complex road that may be just a waste of time. Also, on a more conventional note, I'm starting to look for SQL optimisations within "core". My first possibility is posted on this issue:- http://drupal.org/node/72828 Expect more :) I'd appreciate it if any "follow ups" to these were done either on the issue or in response to my article via this list as opposed to leaving comments (your are welcome to post comments though but I think a better place is needed for articles like this). best regards, --AjK (Andy) http://drupal.org/user/39030
These discussions are valuable and should not be scattered on blogs that may not be there in six months time. The best place for this is either here on the development list, where all the brains are, or on the Performance and Scalability forum http://drupal.org/forum/49 A few comments: - PCRE would be faster since the underlying code is in C and hence is native to the platform. PHP is interpreted and hence slower (as you found out). - A PECL solution is not universal, since many of Drupal's users are on shared hosting where they can't fiddle with PHP's setup or download plugins/libraries for it. You alluded to this, but this is more explicit. In order to assess real penalty for the PCREs, can you try a script that executes without that part (i.e. take out the part where there is a PCRE and a callback altogether) and see what percentage improvement there is.
These discussions are valuable and should not be scattered on blogs that may not be there in six months time.
The best place for this is either here on the development list, where all the brains are, or on the Performance and Scalability forum http://drupal.org/forum/49
OK, good point (I did ask where was a good place as I didn't really know where to post). But discussing it here on devel seems like the best place at the moment.
A few comments:
- PCRE would be faster since the underlying code is in C and hence is native to the platform. PHP is interpreted and hence slower (as you found out).
I've actually know along time ;) I've already written several PECLs to remove PHP bottlenecks for clients with extraordinarily busy sites (non Drupal stuff)
- A PECL solution is not universal, since many of Drupal's users are on shared hosting where they can't fiddle with PHP's setup or download plugins/libraries for it. You alluded to this, but this is more explicit.
Correct. I should have expressed this better. Realistically, if you fall into the 1% of sites that may need a boost of this type then I'd place money on them already being on an owned server (or two, DB/Web split) PECLs are just not on for shared hosts for obvious reasons.
In order to assess real penalty for the PCREs, can you try a script that executes without that part (i.e. take out the part where there is a PCRE and a callback altogether) and see what percentage improvement there is.
I'm not sure what you are asking here. If I take out both components then my benchmark script would look like this:- function db_query($query) { return $query; } All I currently do for time testing is the token replacement in the supplied query string and return that string. It's not run against a database. I'm just testing the Drupal code aspect and nothing more. I'd need more info on what you are asking here. best regards, --AjK
participants (2)
-
AjK -
Khalid B