Link to GHOP: http://code.google.com/p/google-highly-open-participation-drupal/issues/...
The Text:
For GHOP Drupal-Issue 4 I did a profiling of D6. Because the Computer I used for profiling is *very* slow I maybe spot to problems other people don't see/doesn't exist for others. Because this Computer runs XP with 512MB RAM, especially SQL-Queries are slow, so if you're looking into the raw data, don't be surprised.
1. Analysis of a fresh installed D6-HEAD start page after installing (runned cron 1time manually, please note that it IS NOT saved into db)
Overall stats:
It tooks about 2s to build the complete page (yes, the computer is slow :P)
2400ms (98%) went into index.php and functions called by it
the rest went into sess_write and sess_close, nothing to mention here
The complete drupal_bootstrap-Call took 1500ms aka ~60%. It called 9 times _drupal_bootstrap. Analysis of the calls will follow. Most of the rest time is spent into the theme-function, 941ms aka ~40%, analysis will follow.
Analysis of drupal_bootstrap:
Here is 1 call to _drupal_bootstrap mentionabel:
the one which calls drupal_bootstrap_full:
Here is the function _drupal_bootstrap_full to mention, here you can focus on, it's consuming 18% time to execute it's own code and 36% execution time to execute it's code+calls to other funcs. The most part of the additionally 18% goes to the modules_load_all aka drupal_load calls. Here you could try to find a timeoptimized version for, but the code is rather short, not too much you're able to optimize :(
Analysis of theme:
The theme-function including it's calls need 1000ms aka ~40% of the page generation time. As time-consuming functions I propose _init_theme, it needs 230ms for it's own code, maybe here you can step in. Additionally, have look at template_preprocess_page, it consumes with all related calls 550ms, nut it's calling a *huge* amount of functions, it will be hard to find there much code to optimize, without ripping out Features in the template engine (this is a best guess depending on the callstack:P)
Additional advice:
you should imho think of a query-cache, but I talked in IRC with killes and he disliked the idea, and maybe there are reasons for not putting one into D6 till now. You also need *25* calls to the query-function (for me mysqli_query), this are just too much for building one page. OK, sure i'v tested all without caching, but anyway this are too much calls
2. Submitting a new Story-Form
Creating a story consumes 4700ms time
Here we have a complete different places where the time goes.
I talked already about _drupal_bootstraps, now we have more time spent here, 1400ms. But don't worry, i'd guess that you'll not see so much of it on a webhost-server, the vHDD in this computer is *that* slow, it spends 500ms in mysqli_query for the session, 500 in drupal_bootstrap_full (see above) + the rest and you're at 1400m theme needs 1200ms now, but nothing really new, look at 1
The rest of the time, ~1900ms goes into menu_execute_active_handler+calls. Tracking down this time I noticed that the most of it isn't PHP but (for me) slow SQL-Queries
3. Adminindex
I'll just post the additional infos.
it needs 11000ms to be built, 1600ms goes into drupal_bootstrap, 1600 into theme, and the rest (~8000ms) into menu_execute_active_handler, aka
system_requirements and update_requirements: to my understanding, it needs just calling after you've checked for new releases or you've installed/updated a module, not every time you watch the admin panel. For the status, just cache the data if you change them and display the cached data. This would reduce the IO alot. And for the requirements: just check them if they don't meet your requirements. For the time, here we've 6200ms
Other tasks aren't that bad, so i didn't found anything more shocking (like the unexplainable system_requirements :P)
For Questions contact me in #drupal or #drupal-ghop, nick Corni or drop a mail(cDOTr1ATgmxDOTde)
The Profiler Data:
I used WinCacheGrind to analyse them
The Admin Index:
http://www.file-upload.net/download-534419/adminindex.html
The Create-Story:
http://www.file-upload.net/download-534421/profilecreatestory.html
The Watch-1st-page
http://www.file-upload.net/download-534425/profiledatapageview.html
These files are there saved for 1 Year, if someone wants to host them in another location, just do so :)
I Hope you'll be looking into the admin page, that's a huge mess :)
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | profiledata.tar_.gz | 108.66 KB | CorniI |
| #5 | profiling.tar_.gz | 190.12 KB | CorniI |
| #4 | profiling.tar_.gz | 190.12 KB | CorniI |
Comments
Comment #1
kbahey commentedYou should try to compare with and without an accelerator (e.g. APC), since both are common configurations, and behave very differently.
Also, you should try to test on a machine where you do not run the browser or anything else, to exclude any effect that may have (CPU time, writing and accessing the browser cache, ...etc.).
Comment #2
webchicknot a patch, per se, but denoting that this still needs some work on it.
Comment #3
Crell commentedI am unable to access the linked files. I get what looks like a 404 page in German.
You should be able to attach them to this issue. If not, let me know and I can host them for you on my own server. (I'm the owner/mentor for this task. Crell in IRC or drop me a note using my contact page.)
Also remember that we need a copy of the raw data from XDebug, too. Thanks!
Comment #4
CorniI commentedhere are data from above as tar.gz ;)
191kb
Comment #5
CorniI commentedok here are the data from xdebug as .tar.gz :)
i'm waiting for feedback ;)
Comment #6
webchickMarking back for review.
Comment #7
CorniI commentedHi,
and a additional question: what do you expect me to do till you mark the issue #4 as closed? I've given you some hints, discovered an hm interesting bug :p and now I want to proceed with the next issue ;)
ups, changing the patrch status wasn't what i wanted, sorry :(
Comment #8
CorniI commentedComment #9
Crell commentedCornil and I discussed this in IRC last night. Highlights of my feedback:
- The writeup needs better formatting so that it's easier to follow. Header tags would help a great deal. Bulleted lists to summarize findings would be good, too.
- The tests are better run on a more modern computer, which should reflect "real world" servers better. (Modern Linux kernel IO manager, modern hard drive, etc.)
- The theme system is flagged as a slow component. What part? A more fine-grained analysis would be useful to figure out if there is any particular part of the theme system to target or if it's just the deep function call stack or what.
- When I loaded the xdebug profile logs into KCacheGrind, I wasn't able to locate the slow drupal_load() data. However, that's a known slow part of the system. Am I just misreading KCacheGrind, or is there a problem with the profile files? (Could be either, I suppose... :-) )
Comment #10
CorniI commentedFor GHOP Drupal-Issue 4 I did a profiling of D6.
The Comp Specs are:
Core2Duo E6320 (overclocked, both Cores 2,24Ghz)
4GB Mem
HDD - don't know :P should be 72000rpm, 8MB Cache or so
Gentoo Linux, Kernel 2.6.21-tuxonice-gentoo-r6 running X
1. Analysis of a fresh installed D6-HEAD (12.09.07) start page after installing (runned cron 1 time manually, please note that the standard page IS NOT saved into db)
Overall stats:
It tooks about 12ms to build the complete page (jep, now it's a much faster Computer :p)
The complete drupal_bootstrap-call took 9,3ms aka ~70%. It called 9 times _drupal_bootstrap. Analysis of the calls will follow. Most of the rest time is spent into the theme-function, 2,9ms (23%), analysis will follow. menu_executive is smart, so don't worry about it (at least here :D)
Analysis of drupal_bootstrap:
Here is the function _drupal_bootstrap_full to mention, here you can focus on, it's consuming ~50% of the execution time(6ms) to execute it's code+calls to other funcs. More then 50% of it's time goes to the modules_load_all aka drupal_load calls. Here you could try to find a timeoptimized version for, but the code is rather short, not too much you're able to optimize. The Calls itself looks smart anyway, but having each call, and imagine having a high amount of modules, it will matter.
Analysis of theme:
The theme-function including it's the other ~30% of the page generation time. It have a *big* Callstack, and while I clicked through it, I just saw the time goes down with each layer, but I am not able to say THERE it goes. sorry guys. Only recommendation: Think of a ~100lines template engine :p It can have loops and ifs and it should be smart (didn't do a profiling on it)
2. Submitting a new Story-Form
Creating a story consumes 15ms time
Here is nothing really new, differing from the old Computer, all is fine, except from the points talked above, we need ~50% for the bootstrap thing, ~30% for the theme, and ~25% for the menu_executive_active_handler. Tracking down some time loosed in theme(), I came across theme_render_template, it needs 1,3ms without having a call stack, so look there if you want to remove some crappy PHP logic ;)
The other's doesn't seems to be that wasting, but they have a deep call stack you could try to lower
3. Adminindex
I'll just post the additional infos, the rest is like 1.
it needs 61(!)ms to be built, 8,8ms goes into drupal_bootstrap, 3,6ms into theme and 48ms!!!(80% of page generation time) into menu_executive_handler. Now, you sure asks. Why are we loosing that much time for building the admin index? it's 6x slower then the other one's! We start with menu_executive_handler itself. It needs 5,8ms for itself (without calls), his is imho too long. The most other time is spemt into a bug (to my understanding) of update.status-module, 38ms of the total page generation time goes into the function system_status. You don't need to compute your huge array for all modules ecvery time the admin visits the admin index, uh? Just cache the results of the last check (on cron and after adding a new module) and display these on the admin index. It will safe you at least 33ms. Is this an argument? :P I'll file a bug because of this to update_status :)
All other Calls of admin index seems to be ok, no other problems found
For Questions contact me in #drupal or #drupal-ghop, nick Corni or drop a mail(cDOTr1ATgmxDOTde)
Comment #11
Crell commentedHi Cornil. Much nicer. Two small comments:
- In section 1, you say that drupal_bootstrap() takes 60% of the page time. However, you then say that the theme system takes the other 50%. 60% + 50% is more than 100%, which does not make sense. :-) It also leaves no time for anything else that the page does. Please clarify.
- I don't think the exclamation at the end ("As I see, you didn't fix that bug...") is necessary. If you think it's important to highlight that issue, try to make it clearer in the actual description so we know exactly what wasted time you're talking about.
At this point, what we'd like you to do is the following:
1) Address the above two issues, and post your final version (including the attachment) straight to the performance group over on groups.drupal.org: http://groups.drupal.org/coding-standards-and-performance-optimization
2) Post back in this issue with a link to it so that we can close this issue and mark it completed. (Yay!)
3) File a bug against the update.module in Core (http://drupal.org/node/add/project-issue/drupal) about the third point you mention, regarding the admin page. It's possible a fix for that one can sneak into Drupal 6 if it comes to the attention of the update.module maintainers fast enough.
Thanks!
Comment #12
CorniI commentedOK, I just edited the post above, new profile-datas are attached!
3) you can find the issue here: http://drupal.org/node/200028
1) I'll do so in one minute :)
2) http://groups.drupal.org/node/7628
Comment #13
Crell commentedRock on, thanks! Marking this fixed.
Please also paste a copy of your report to the Google issue tracker for this issue. Apparently Google is picky about that, too. :-(
Comment #14
CorniI commenteddid it :) Please mark it now as closed :)
Comment #15
(not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.