Add timing information to statistics page

looks ok ... note that there are some unrelated (i think) variable_set() changes in the patch.

It's great to have this level of logging granularity.

I am concerned that all the logging would add over head when having multiple crawlers crawling the site during testing. Would it be possible to support batching the log entries and submitting them to the database as batch query at set increments instead of for every page.

For example I routinely run several wget crawls for different roles when testing an upgrade. If I ran 5 crawlers and each of 10, 000+ pages were being crawled then I am concerned the performance would be impacted.

I understand this isn't the intent of this patch but non intrusive logging is important in generating accurate performance measurements.

Thank-you for your consideration.

Kieran

in the pdf, i think you are swapping 'total' and 'average' column headers

I like the idea. a lot. But from the pdf it is not clear that timer deals with the generation tilme o a page.

* Are we not boing too geeky here (again)? devel.module does farily granual timing already. Is Joe User really waiting for timers on how long it took to make a page. I think not.
* If we really want this in core, it should at least be made very clear that this is the time it took to make a page. I presented the screenshot to a client, as a small test. And just like i thought, his reaction was " Wow, this is handy, I can now see how long a user spent at a certain page. This will tell me what posts are actually read, and which are only opened in a browser only to be closed right away". I almost made the same mistake, but the geek in me told me to look at the code and see that it is page generation times. Joe user will not ever look at the code.
* What is the penalty. accesslog already is a heavy load table. Do we really want aditional data in that table.
* We have access hooks (called after page is loaded) to do aditional statistics magic. IT is not userd by anything else then the stats in core. Why cant this go into an advanced stats module?

I love the idea very much, and think this will prove extremely useful. What about making an option that enables/disables these columns? The only reason I suggest this is because they are inherently confusing without using a lot of verbage. "Average time" needs to be something like "Average time for Drupal engine to generate this page", and "Total time" needs to be something like "Total time to generate". Or, it could be fully explained at the configurable that turns the display on and off...?

"I could easily compile a list of the users/IPs that eat most resources."

Yes, do it! :) That would be very useful.

"Would it be possible to support batching the log entries and submitting them to the database as batch query at set increments instead of for every page."

Where would the data be stored until it was committed to the table?

It would be possible to do something similar to what the banner module does, writing to multiple cache files. But this isn't friendly for distributed web servers.

Do writes to the accesslog slow down measurably when the acceslog table grows? If so, then there could be an accesslog_cache table to which data is first written, and which is flushed to the main accesslog every n minutes, or every time it reaches a certain size, etc. This would only be useful if writing to a very large table is measurably slower than writing to a very small table.

Useful info for sure.

I am with Jeremy that this needs to be parameterized.

Also, are these figures real? Does the average time to generate the forum page is 30 seconds? I find this hard to swallow.

Now I realize that the Total and Average columns are using different units. Thats not ideal, but understandable in this case. I can't think of a better solution.