[alg] responstijden van webapplicatie meten

[mjax]

Wij zijn bezig met de ontwikkeling van een grote webapplicatie. De applicatie reageert af en toe wat traag. Daarom is de behoefte gerezen om de responstijd meetbaar te maken. Met responstijd bedoel ik de tijd die verstrijkt tussen de muisklik (start request) en het compleet opgebouwd zijn van de pagina. Eventuele subrequests (plaatjes, iframe's etc.) laat ik buiten beschouwing.

Voor mij ziet het opvragen van een pagina binnen onze applicatie er als volgt uit:

1. click op een link (start request)
2. request komt binnen op webserver
3. webserver bouwt pagina op (PHP)
4. webserver stuurt pagina terug naar client
5. client ontvangt pagina
6. client rendert pagina
7. pagina is in zijn geheel gerenderd

In feite zou ik graag willen weten hoeveel tijd tussen elk van deze punten verstrijkt, maar ik begrijp dat dat niet mogelijk is, zeker niet aangezien niet alle punten sequentieel doorlopen worden. Tenslotte beginnen de meeste browsers al met renderen terwijl de data nog niet helemaal binnen is.

Op dit moment is alleen de parsetime (tijd tussen punt 3 en 4) meetbaar. Bestaat er een mogelijheid (met een tooltje, een aparte browser, een pluging voor FireFox o.i.d) om ook andere stappen in dit proces meetbaar te maken?

[faabman]

En wat als je nu in het begin van je HTML een javascript timer initieert, welke je aan het eind uitleest?

[ Voor 7% gewijzigd door faabman op 12-05-2005 09:05 ]

[Wolfboy]

Als je gewoon een javascriptje start dat de pagina aanroept (voor mijn part in een ander frame om het eenvoudig te houden) en direct een timer start dan moet het wel meetbaar zijn.
Bij het laatste object op de pagina gewoon in de onload aangeven dat de timer moet stoppen en een alert moet geven.

edit:
Spuit 11

[ Voor 5% gewijzigd door Wolfboy op 12-05-2005 09:07 ]

[Alarmnummer]

Misschien kun je eens kijken naar producten zoals:
http://jakarta.apache.org/jmeter/

[Ramon]

of Microsoft Web Application Stress Tool

[GrimaceODespair]

Vermoed je dat de client-side zo zwaar is dan? Anders kun je je beter eerst concentreren op de server-side performance. Bij grote webapplicaties lijkt me dat meestal de bottleneck.

[mjax]

GrimaceODespair schreef op donderdag 12 mei 2005 @ 09:25:
Vermoed je dat de client-side zo zwaar is dan? Anders kun je je beter eerst concentreren op de server-side performance. Bij grote webapplicaties lijkt me dat meestal de bottleneck.

Ik vermoed inderdaad dat de clientside, transfertijden etc. zwaar wegen in de responstijden. Op dit moment "voelen" pagina's aan als 3-4 seconden (complete render), terwijl de parsetijden rond de 0.1 seconde liggen. Vandaar dat ik inzicht in de andere onderdelen wil krijgen.

Iedereen alvast bedankt voor de tips, ik ga ermee aan de slag. Dat idee van een javascript timertje met een frameconstructie vind ik zo gek nog niet.

[Verwijderd]

Javascript is totaal niet bruikbaar voor het meten van responsetijden. Een pagina die je oproept op een server die zwaarbelast is zal net zo snel renderen als een pagina die je oproept op een server die onbelast is. Het moment echter waarop dat renderen kan gaan starten is veel langer op een zwaarbelaste server.

De enige manier om dit dus te meten is met software die voor jou loadtesting of stresstesting uitvoert. Loadtesting test de applicatie onder praktijk omstandigheden, en stresstesten trekt je applicatie plat zodat je kunt zien wat je er maximaal uit kan halen.

[mjax]

Verwijderd schreef op donderdag 12 mei 2005 @ 10:15:
Javascript is totaal niet bruikbaar voor het meten van responsetijden. Een pagina die je oproept op een server die zwaarbelast is zal net zo snel renderen als een pagina die je oproept op een server die onbelast is. Het moment echter waarop dat renderen kan gaan starten is veel langer op een zwaarbelaste server.

Ben ik niet helemaal met je eens. Ik kan een pagina bouwen die een nieuwe pagina opent (nieuw window, frame o.i.d). Ik kan dan een timer starten op het moment dat de request verstuurt wordt, dus nog voordat er data terugkomt van de server. En ik kan met onload of het afchecken van readyState controleren wanneer de pagina in zijn geheel gerenderd is. Op die manier kun je dus de totaal benodigde tijd voor het opvragen en opbouwen van een pagina meten.

[MrBarBarian]

http://grinder.sourceforge.net

Das precies wat je zoekt. Ik heb het gebruikt voor een stresstest van een webserver, maar hij geeft ook verschillende responsetijden weer.. Erg goede tool!

[mjax]

Voor geinteresseerden, ik heb het opgelost met een simpel HTML/JavaScript paginaatje. Het ziet er als volgt uit:

code:

<html>
<head>
    <script language="javascript">
        var startTijd = null;
        var bIsLoading = false;

        function checkStatus() {
            var sReadyState = document.getElementById('pagina').readyState;

            setReadyState(sReadyState);

            if(bIsLoading) {
                if(sReadyState == 'complete') {
                    var eindTijd = new Date();
                    bIsLoading = false;
                    setStatus((eindTijd-startTijd)/1000+' sec.');
                }
            } else {
                if(sReadyState != 'complete') {
                    startTijd = new Date();
                    bIsLoading = true;
                    setStatus('Loading...');
                }
            }
        }

        function setStatus(sStatus) {
            document.getElementById('statusText').innerHTML = sStatus;
        }

        function setReadyState(sReadyState) {
            document.getElementById('readyStateText').innerHTML = sReadyState;
        }
    </script>
</head>
<body>
    <div id="gui">
        <input type="text" id="url" size="40"><button onclick="document.getElementById('pagina').src = document.getElementById('url').value">Go</button>
        <div id="statusText"></div>
        <div id="readyStateText"></div>
    </div>
    <iframe id="pagina" src="" width="100%" height="100%" onreadystatechange="checkStatus()"></iframe>
</body>
</html>

Het is absoluut niet 100% nauwkeurig, maar voor mijn situatie voldoet het uitstekend. Je zou dit natuurlijk nog verder uit kunnen werken.

[ Voor 37% gewijzigd door mjax op 12-05-2005 12:14 ]

[ACM]

IBM Page Detailer is ook leuk voor dit soort dingen. Dat is overigens een 'soort proxy' voor internet explorer, firefox etc die behoorlijk gedetailleerd kan laten zien hoe lang alles duurde, inclusief het laden van plaatjes, javascripts, etc. Voor firefox moet je wel even de configuratie-file aanpassen.

[ Voor 82% gewijzigd door ACM op 12-05-2005 12:30 ]

[Verwijderd]

mjax schreef op donderdag 12 mei 2005 @ 11:18:
[...]


Ben ik niet helemaal met je eens. Ik kan een pagina bouwen die een nieuwe pagina opent (nieuw window, frame o.i.d). Ik kan dan een timer starten op het moment dat de request verstuurt wordt, dus nog voordat er data terugkomt van de server. En ik kan met onload of het afchecken van readyState controleren wanneer de pagina in zijn geheel gerenderd is. Op die manier kun je dus de totaal benodigde tijd voor het opvragen en opbouwen van een pagina meten.

Dat is totaal niet betrouwbaar. Ten eerste omdat readyState niet werkt op de manier die jij schetst, ten tweede omdat responsetime niets te maken moet hebben met de processing kracht van een client. Jij meet met variabelen die afhankelijk zijn van de client, en niet van de server. Als ik de pagina uitvoer op een P2 of een P4, dan scheelt dat nogal wat in snelheid. Dat de applicatie dan slecht performed op een P2 is totaal niet in relatie met een responsetijd. Responsetijden zijn iets anders dan page render tijden

[ Voor 10% gewijzigd door Verwijderd op 12-05-2005 12:58 ]

[mjax]

Verwijderd schreef op donderdag 12 mei 2005 @ 12:57:
[...]


Dat is totaal niet betrouwbaar. Ten eerste omdat readyState niet werkt op de manier die jij schetst, ten tweede omdat responsetime niets te maken moet hebben met de processing kracht van een client. Jij meet met variabelen die afhankelijk zijn van de client, en niet van de server. Als ik de pagina uitvoer op een P2 of een P4, dan scheelt dat nogal wat in snelheid. Dat de applicatie dan slecht performed op een P2 is totaal niet in relatie met een responsetijd. Responsetijden zijn iets anders dan page render tijden

Ik begrijp je helemaal, maar de tijd die de server nodig heeft voor het opbouwen van de pagina, hebben we allang inzichtelijk. Jij ziet het opbouwen van de pagina niet als onderdeel van de responstijd. Feit is dat een eindgebruiker er wel zo tegenaan kijkt. Hij telt van klik op de link tot compleet geladen pagina. En dat is nu juist de tijd die ik wilde meten. Ik begrijp dat die tijd afhangt van de processingkracht van de client (en nog veel meer factoren). Laten we geen discussie houden over de definitie van "responstijd", want daar is het me niet om te doen geweest.

[Verwijderd]

Wat wil je dan gaan meten? Wil je niet meten of er requests terugkomen met een "server to busy" melding bijvoorbeeld? Hoe wil je uberhaupt zoveel hits gaan simuleren met Javascript, 200 windows op een enkel werkstation? Dan zit je ook met processing power die je deelt.

Er zijn teveel factoren om op te noemen, die zelfs jouw doel de totale tijd dat het duurt voordat mevrouw of meneer de hele pagina ziet, onmogelijk maken om betrouwbaar of uberhaupt al uit te voeren

Wil je de performance van de pagina bij de client meten, zoals hoe snel een menu uitklapt, dan wordt het een ander verhaal, maar dan zit je in /14 al verkeerd.

[ACM]

mjax schreef op donderdag 12 mei 2005 @ 13:06:
Ik begrijp je helemaal, maar de tijd die de server nodig heeft voor het opbouwen van de pagina, hebben we allang inzichtelijk. Jij ziet het opbouwen van de pagina niet als onderdeel van de responstijd. Feit is dat een eindgebruiker er wel zo tegenaan kijkt. Hij telt van klik op de link tot compleet geladen pagina. En dat is nu juist de tijd die ik wilde meten. Ik begrijp dat die tijd afhangt van de processingkracht van de client (en nog veel meer factoren). Laten we geen discussie houden over de definitie van "responstijd", want daar is het me niet om te doen geweest.

Zoek naar IBM's Page Detailer, op de uiteindelijke parsing van de html na laat die precies zien waar je tijd in zit. Dus ook alle plaatjes enzo. Verder dan dat, dus inclusief parsing van html en javascript heb ik ze nog niet gevonden.

[mjax]

ACM schreef op donderdag 12 mei 2005 @ 12:27:
IBM Page Detailer is ook leuk voor dit soort dingen. Dat is overigens een 'soort proxy' voor internet explorer, firefox etc die behoorlijk gedetailleerd kan laten zien hoe lang alles duurde, inclusief het laden van plaatjes, javascripts, etc. Voor firefox moet je wel even de configuratie-file aanpassen.

Geweldig! Dit komt het meest in de buurt van wat ik zoek. Hier kan ik wel wat mee.