Feature Proposal: Measure and report Script timing

Motivation

Give users and admins a way to track speed of foswiki.

Description and Documentation

http://fosiki.com/blog/2012/04/12/more-apache-conf-magic-this-time-for-foswiki/

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: SvenDowideit - 25 Apr 2012

Discussion

When we move to Plack, we can use CPAN:Plack::Middleware::Debug to do this, at least when developing.

(BTW, I am starting to look into Plack again - more updates coming soon...)

-- AndrewJones - 26 Apr 2012

Yay on Plack. Thanks, Andrew for pushing this forward.

Note, to measure performance it doesn't require to test a single topic only. It requires a well balanced mixture of different kinds of topics with regards to their complexity of TML they use. Also: performance on a site needs some parallelism to simulate more than one user clicking around on the site. We also need a way to measure non-view actions like save and such. The mixture of different kinds of scripts being executed in parallel can give quite different results than just testing only view clicks or only save actions. That's because a save action will normally invalidate cache entries to be repopulated as well as point out backend bottlenecks on various layers.

-- MichaelDaum - 26 Apr 2012

Plack may make this proposal redundant, but until it does, it'll be useful to have something to track.

Michael, yes and no, but what you're talking about is analyzing a particular performance metric related to overall user impression (and essentially is useful for sizing and upgrading the server after you've determined a necessary feature set). There are other useful analyses that are much simpler - including 'how much does skin / wikiapp impact on the wiki' that can be done - assuming that you can find a quiet time on your server.

To do any analysis, you need the individual datums. We have none.

This proposal is about providing an simple metric - that can be analyzed either as an individual (hopefully unloaded server) time to compare installed options, or as a part of a larger, more holistic user performance metric.

I've see people run time ./view Some.Topic evey minute form a monitoring app and use that to graph server responsiveness - ie, causing server load to measure server load - which really seems like a bad idea to me

-- SvenDowideit - 27 Apr 2012

True: measuring / reporting the rendering time of a single url has got its value. All I wanted to say is that measuring a site treated as a black box with tools scanning it from outside give much more insight when looking for real-world performance problems. There's a complete software category for tools that do this automated. Unfortunately the good ones are not for free ... as far as I know.

-- MichaelDaum - 27 Apr 2012

Commenting is disabled while not logged in