Log performance test results
Jax - May 7, 2009 - 05:46
| Project: | Project Issue File Review |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Amazon |
| Status: | closed |
Jump to:
Description
Khalid has a solid history of doing analysis and reporting performance
issues for Drupal. We currently do not keep records of the performance
tests. We need to come up with a way to keep a history of performance tests.
#1
Here is some analysis from Jimmy: http://blog.boombatower.com/automated-testing-system-statistics
#2
Keep in mind our standard slaves take 20-30 min, but #16 pulls the average down with 4 minutes so it runs a lot more.
#3
fyi, netaustin is working on this on his economist.com 'community' time.
#4
suppose we should store cvs checkout between tests and download only a cvs or rsync deltas
What branch I can use to make it?
#5
pifr_status() called too often
http://drupalbin.com/10239
#6
#4: not sure if this is what your refering to...but it must flush the entire D7 checkout and extract from CVS to ensure that any changes made by patch and code when it ran didn't leave any left overs. (either way the setup section of tests takes 5-10 seconds). We need to focus on tests themselves.
#5: depends on what client is doing. not sure we can say code is called too much just by the fact that it is called a lot.
Conclusion: What are we looking for in this issue? Some sort of performance data or what? Things like that should probably be developed with SimpleTest and then PIFR can display them since it purely acts as a wrapper to automate the process.
#7
I don't think performance matters for simpletest. But for PIFR clients that need to be tuned to run tests faster by system administrators they need to see what tests are taking so long and try to learn why.
Could we add something to PIFR that enables test performance logging in the PIFR client? That could be either to watchdog, or start stop times in the PIFR table that records when tests are run.
#8
When the suite starts (already does), or when each individual testMethod is invoked (seems excessive)?
#9
Can we do it for test class? I assume that's a happy medium.
We might need to think about the impact of concurrent testing for multi-processor machines.
#10
about #5 - @boombatower suppose this is a good place for static cache
#11
pifr_status() is 1.x code??
#12
So where does this leave us?
I'm going to mark this as closed, please re-open if we have something we want added. I am thinking the new review.log feature should provide the right facility.