Measuring Single User Performance

[DrQ]

This topic comes up from time to time, especially for those performance engineers looking to normalize data for the purpose of applying the USL model. I would tend to just interpolate it in R or MMA, but it might be useful to hear what others think of this blog post.

http://practicalperformanceanalyst.com/site/content/single-user-performance-analysis-using-open-source-tools

"My [blog author] Role as a Practical Performance Analyst...

The Practical Performance Analyst (as in the name) i should admit is the brain child of Dr. Neil Gunther (www.perfdynamics.com/Bio/njg.html) who has put in a lot of effort into creating a truly amazing book on Performance Analysis. I see myself as a practicing Practical Performance Analyst who deals with Performance & Capacity Management challenges on a daily basis."

http://practicalperformanceanalyst.com/site/content/about-us

[Greg Hunt]

The tools the blog post talks about are primarily useful for auditing page design (which has performance implications, particularly when it touches third party systems) but I'd usually rather not be collecting actual performance data one page at a time.  

Your reference to USL:  the elapsed times in the examples in that blog entry are ensembles of multiple interacting systems, including the browser's rendering processes.  Basing any kind of capacity or scaling analysis on the net result of the fetching and rendering across multiple transactions and systems is probably not meaningful.  Picking out the core system transactions can be done more easily with other tools.  

If you have a stack of third party stuff on your page, all you can do is optimise its presence and then get on with optimising the transactions that you do control (checking of course that the thing you are optimising does in the grand scheme of things matter - if your advertising blocks loading/rendering for 5 seconds and your own page delivery is under 0.5 then optimising it is probably not a huge priority).

I used to have an IE plugin that would log that kind of stuff at a session level so I could analyse it after the session.  It made the data collection a lot easier and I could also use the logs to audit HTML standards compliance. But for intranet systems its usually unnecessary, their overlap with other systems is not often that big a deal so getting the page design right to optimise the performance and then focussing on the core request is the key thing.    

For a system, and for pages with any level of complexity, particularly a transaction processing one, even at the single user level, you need to handle lots of pages with multiple combinations of post and get parameters and that gets tedious quickly when the tester has to stop after each one to look at the data.

If you really want to start analysis early in the development cycle, looking at administrative by-products like web server logs with elapsed times configured in is easier and allows a degree of analysis and targeting. There is often a lot of data laying about that can be looked at opportunistically without adding load to the developer's activities.  The art there is reducing the tolerances on the logged performance as development progresses, at the beginning the tolerances need to be huge ("this is consistently over 10 seconds, whats with that?") and get tighter as development progresses ("this transaction is twice our response time target, have you looked at it?") leading to a more interventionist approach with tolerances for a single user workload that are tighter than the actual system performance targets ("everything that logs above X milliseconds needs to be reviewed, everything above Y seconds needs effort allocated to fix it").  The early pressure on the developers tends to make the later phases smaller and less traumatic for everyone.

It is mildly ironic that the page they use as an example has so many structural performance problems reported by Chrome's page auditing, and the reference to the page being a portal composed of applets does make me wonder about the author's actual technical level.  

--
You received this message because you are subscribed to the Google Groups "Guerrilla Capacity Planning" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guerrilla-capacity-...@googlegroups.com.
To post to this group, send email to guerrilla-cap...@googlegroups.com.
Visit this group at http://groups.google.com/group/guerrilla-capacity-planning?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.