Posted by kbahey on August 25, 2008 at 10:15pm
| Project: | Devel |
| Version: | 6.x-1.x-dev |
| Component: | performance |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
It would be nice if we are able to export the CSV data from the reports, so they can be analyzed in spreadsheets, generate charts and such ...
Comments
#1
Moving to devel queue, since the module is now part of that.
#2
Hmmm,
Perhaps Views integration would be a useful path to go down.
If the performance module exposed its data to views, then perhaps administrator could generate their own custom reports [filter by time range etc].
There is a CSV export component in the Views Bonus Pack, but that module isn't ported to D6 yet.
#237196: Drupal 6 version of Views Bonus Pack?
Alan
#3
No. This is more dependencies, and hence more bloat.
I was thinking of something more minimalistic.
Something like how profile csv does it http://drupal.org/project/profile_csv
#4
I would like to see this as well. I may have a patch up soon. I think that the Drupal for Firebug module has some code that I can base my technique off of.
#5
Here's a patch that exports the data as a tab-delimited file. It's made against the 6.x-1.16 version. I couldn't use the CSV format because the queries have commas in them.
I've started using it to analyze the data from my 6.x site in MS Access & am coming up with fascinating conclusions. Apparently, drupal_get_path() queries are around 41% of the page request for me.
#6
I just tested my patch against 6.x-1.8 and it succeeds, though there's an offset.
#7
Has anyone had a chance to look at this? I think it would be a very useful feature.
#8
Patch still applies with offset.
I like the idea in general, but the way it is implemented, it appends to a file in real time (for every page view). This can hurt performance and tax the file system/disk.
Would it be better to just allow exporting of the existing data in CSV format? We can have a MENU_LOCAL_TASK for the report pages that output a CSV, and it will appear as a tab.
This allows sites to log in APC and then export without much performance penalty.
Also, why a Tab as a delimiter? A Comma is better so ti is CSV?
#9
@kbahey:
Thanks for the review. I am appending to the file in real-time since I don't have APC (I have EAccelerator), so query logging had to be through the regular functionality of the devel module, rather than through the version that uses APC. Also, I am only using this on my test site, for debugging purposes, so it doesn't matter that the performance is degraded. Perhaps our use cases are different enough that I should have created a new issue rather than posting to yours.
I am using a tab as a delimiter simply because I was having problems with CSV since queries contained commas in them. If there's a way around that problem, that would be great. I'm probably missing something obvious. The tab-delimited format imported correctly into Excel, so it worked for my purposes.
Should we set this to "needs work"? I am probably not going to work further on this patch, since the circumstance that required it has passed for me now, but I think that your suggestions make a lot of sense.
#10
#11
Patch still applies with offset to 6.x-1.20. Haven't changed it to address kbahey's comments yet.
#12
Anything newer on this? Is it something that would be applied to the main module? Just curious, as I just had the same thought come to mind for spitting out reports. Are the reports not available in the SQL tables somewhere, anyways, so that technically any of us could go in and query what we wanted anyway, then export? Just a thought... and maybe gives someone an idea to make it even better? I doubt it.
Anyway, I plan on at least trying out this module w/patch to see what I can see in the reports when exported.
Thanks for all the efforts on this!
#13
@kjv1611: the patch from #5 is still the newest available. Feel free to re-roll addressing kbahey's concerns if you have time.
I think the most important of them is to make the log a MENU_LOCAL_TASK on admin/settings/devel, so that the CSV export can be done as needed, while the logging occurs via APC or Memcache. (I have APC now, so I can see the benefit.) Real-time logging might good though too, for any users who don't have the benefit of opcode caching.
I am still not sure about making the file CSV rather than tab-delimited. I think this would require some escaping of the DB queries, since they contain commas. kbahey, feel free to correct me if I am wrong.
#14
Component was wrong.
#15
The Performance submodule has been removed from Devel for lack of resources to maintain it properly.
We hope it will come back in its original project, http://drupal.org/project/performance / Performance Logging and Monitoring, which is currently marked "Abandoned." If you're interested in maintaining this important project then see Dealing with abandoned projects.
Unfortunately, the issues queue of Performance has been closed and I cannot reassign this issue, so I just have to close it.