Is this possible? Would make for much more accurate data on sites with page cache enabled for anonymous users.

Comments

malc0mn’s picture

malc0mn commented

That would indeed be a good idea. Would have to check if it is possible. All data is logged in a shutdown function and I'm not sure if the user object is still accessible at that point of the script execution. If it is, then it is definitely possible and would be a great addition!

mstrelan’s picture

mstrelan commented

Not at a computer at the moment, but I know devel module checks a global in its register shutdown function so i guess if Drupal is unsetting the uid you should be able to record your own uid variable earlier and have it available at shutdown.

mstrelan’s picture

mstrelan commented

Also performance_shutdown() already calls performance_log_details() which checks the uid, so this is definitely possible.

malc0mn’s picture

malc0mn commented
Assigned: Unassigned » malc0mn

I'm a bit confused now, as I was working on Drush integration yesterday... It already shows anonymous vs logged in users in the detail page. This data has always been recorded (phew ;-) )

You do propose something like this:

  • General summary (anon + authenticated)
  • Anonymous summary
  • Authenticated summary

right?

mstrelan’s picture

mstrelan commented

Yep, not interested in the detail page, just the summary reports as per the issue title ;)

malc0mn’s picture

malc0mn commented

TODO: Whether the user is anonymous or not is always recorded but is simply not stored with the summary data. The table needs to be expanded with an 'anon' field so that the primary key will become path + anon.

For memcache, apc and zend we would have to generate different keys. Now based on path, afterwards based on path + anon. This will double the memory used!

If it'll be built, there has to be a setting for this: 'separate anonymous users in summary logging' with a warning that it will consume twice the amount of storage.
Maybe even better for summary logging, a list of options:

  • separate anonymous users in summary logging
  • do not log users with role ...
  • only log anonymous users