Benchmarken van snelheid website?

[bartvb]

Er zijn legio programma's om een webserver te benchmarken, dat is dan ook niet waarnaar ik op zoek ben. Wat ik nu al een paar jaar zoek is een applicatie die inzichtelijk maakt waar de gebruiker op zit te wachten als deze een pagina opent op mijn site. Hoe lang is het wachten op een verbinding? Hoe lang duurt het voor de HTML binnen komt? Hoe lang duurt het voor de HTMl binnen is? Hoe lang duurt het binnenhalen van alle plaatjes? Moet de gebruiker een paar seconde wachten op een scriptje van Google AdSense? Duurt het 2 seconde voor de javascript op de pagina eindelijk klaar is?

Ik heb gisteren voor de zoveelste keer in de afgelopen jaren weer eens zitten zoeken en veel verder dan dit:
http://galeb.etf.bg.ac.yu/~ks040161d/firefox/extensions/esb/

ben ik niet gekomen. Die extension laat iig zien hoeveel plaatjes er gedownload zijn en hoeveel tijd er zit tussen het aanklikken van een link en het helemaal geladen zijn van die pagina. Ik heb de extensie een beetje aangepast zodat je ook het aantal milliseconde ziet en dat geeft iig al een indicatie of het veranderen (of verwijderen) van wat javascript een verbetering geeft of niet en of je heel lang zit te wachten op een paar externe plaatjes.

Nu zou het nog veel leuker zijn als er iets was dat een lijstje zou geven met b.v:

0.00 connect
0.01 connection established
0.05 start receiving content [URL]
0.08 end receiving content [URL] (transfer time: 0.03)
0.08 start javascript [URL]
0.09 close connection
0.11 end javascript [URL]
0.11 done

en dan ook nog het binnenhalen van externe scripts, css en plaatjes. Ik heb echt een hekel aan sites waar je een paar seconde (of zelfs meer dan een seconde) moet wachten op een pagina. De frontpage van tweakers.net is hier ook een voorbeeld van (maar nog niet heel extreem), het duurt even voor de browser alle javascript op die pagina verwerkt heeft. Dat wil ik dus erg graag voorkomen op mijn sites en in mijn applicaties maar daarvoor is het wel handig om inzichtelijk te kunnen maken waar de page load tijd allemaal heen gaat.

Heeft iemand suggesties? Ik kan me echt bijna niet voorstellen dat iets als dit nog niet bestaat.

[the_stickie]

de snelheid van client-side scripting is natuurlijk afhankelijk van de computer van je bezoeker
Imho is het enige dat echt van belang is, de snelheid van de webserver en de totale grootte van je pagina. Die kan je beiden eenvoudig controleren.
Bij dynamische pagin's moet je ook j querys wat erzoregen en je database op een snelle server hebben, maar ook dat is eenvouidg te benchen...

[Victor]

Probeer IBM Page Detailer eens, laat precies zien waar jij om vraagt.

[Ramon]

Of Web Application Stress Tool van Microsoft, kan je heel erg veel clients mee simuleren en dan zien hoe de pagina-laad-snelheid eronder lijdt.

[eamelink]

The_Stickie schreef op zaterdag 11 maart 2006 @ 14:00:
Imho is het enige dat echt van belang is, de snelheid van de webserver en de totale grootte van je pagina. Die kan je beiden eenvoudig controleren.

De roundtriptime naar de server is ook erg belangrijk hoor. Als je server ergens ver weg staat en je hebt een roundtriptime van 800ms, dan kan het meteen traag worden.

Belangrijk is dan ook nog hoeveel roundtrips er nodig zijn voordat uberhaupt alles binnen kán zijn.

Als je een pagina hebt met een externe stylesheet, waar plaatjes in zitten, dan zit je dus al minstens 3x 800ms te wachten voordat de pagina binnen is. Terwijl een beetje grotere pagina gewoon meteen achterelkaar doorgepompt zou kunnen worden. Het voordeel is weer wel dat bij latere requests de stylesheet en plaatjes gecached zijn.

[bartvb]

Onderschat javascript niet Ik heb mijn site een keer omgebouwd naar een GoT achtige constructie waarbij er weinig HTMl over werd gestuurd en vooral een hoop javascript. Dingen als:

display_topic(12345, 'Dit is de titel', 'Poster', 234, 1142084669);

waarna een stukje javascript op de pagina dat omzette naar een table row met de titel, link naar het topic, wie het gepost heeft, etc. De layout hoeft dan dus maar 1x verstuurd te worden en de JS doet al het repeterende werk. Mijn pagina's werden wat kleiner (maar niet schokkend door gzip) maar werden wel een stuk langzamer. Heb toen wat zitten benchmarken met wat timers in de javascript zelf en het verschil was echt zeer fors. Heb dit uiteindelijk dus maar niet doorgevoerd.

Maar dat IBM Page Detailer is erg grappig. Moet er wel even m'n Windows machine voor aanzwengelen helaas. Maar enorm bedankt voor de suggestie, is bijna precies wat ik zoek
Eigenlijk zou iemand dit om moeten zetten naar een Firefox Extension...

http://www.it-hq.org/modu...om_id=147&com_rootid=147&

Die tool van Microsoft is puur om je server zelf te testen, dat zit echter wel goed in dit geval en daar zijn ook redelijk wat tools voor te krijgen. Het gaat me meer om het totaalplaatje en vooral om de gebruikerservaring. WAST is vooral bedoeld om te kijken of je server meer dan x honderd of duizend users aan kan, dat is dus precies de andere kant van het verhaal.

Ik ga m'n vriendin eens van de windows bak af schoppen

[ Voor 36% gewijzigd door bartvb op 11-03-2006 14:46 ]

[crisp]

bartvb schreef op zaterdag 11 maart 2006 @ 14:40:
Onderschat javascript niet Ik heb mijn site een keer omgebouwd naar een GoT achtige constructie waarbij er weinig HTMl over werd gestuurd en vooral een hoop javascript. Dingen als:

display_topic(12345, 'Dit is de titel', 'Poster', 234, 1142084669);

waarna een stukje javascript op de pagina dat omzette naar een table row met de titel, link naar het topic, wie het gepost heeft, etc.[...]

Zo deden wij dat vroeger op de frontpage ook (en ook het forum in het Topix-tijdperk deed dat). Tegenwoordig met gzip compressie is het verschil in bandbreedte verwaarloosbaar. Tel daarbij op de nadelen die het met zich meebrengt (afhankelijkheid van javascript, niet indexeerbaar, slecht onderhoudbaar, rendersnelheid sterk afhankelijk van de client) en je snapt waarom we daar grootendeels (enkel de pricewatch wordt nog op deze manier samengesteld) vanafgestapt zijn

Overigens komt een groot deel van de rendertijd van de Tnet frontpage op conto van de banners; adverteerders kijken blijkbaar tegenwoordig niet meer op een paar kilobytes meer of minder...

[chem]

Toevallig zijn we gister ook met dit verhaal aan de slag gegaan nadat ook bij ons een website achterlijk traag werd door google analytics. We hebben op dit moment een aantal mogelijkheden op tafel liggen om het geheel sneller te krijgen en hebben het ook gebenchmarked.
[list=1]
• we hebben een x-aantal servers achter een LB; deze is nu zonder keep-alive; hier valt een req/sec winst van 400 naar 600 te halen, oftewel een flinke snelheidswinst om een veelvoud aan resources op te vragen bij de gebruiker (bij 1 lokale server, getest met web stress tool van MS)
• het aantal requests per pagina naar beneden halen door bestanden samen te voegen. Zo hebben we een request_multiple.php die meerdere JS en CSS files in 1 klap kan doorsturen; deze kan veel minder req/sec aan maar is bij 10 bestanden via 1 request toch sneller.
• afbeeldingen samenvoegen in een tilemap -> 1 request, 1 file, 1 header
• JS optimalisaties; hier staat nog wel wat open bij ons. Eenmalige detecties / DOM lookups / snellere for-loops (crisp heeft er 1 bedacht die sneller blijkt) moeten allemaal wel mogelijk zijn.
• meerdere hostnames; keep-alive is volgens de RFC beperkt tot 2 sockets per hostname; door meerdere hostnames (www, www2, www3) te gebruiken (evt. naar 1 server uiteindelijk) kan de gebruiker meer simultaan opvragen. Dit benchmarken moet ik nog doen, maar er zijn artikelen die uitwijzen dat dit idd sneller is
• Nette html, css en js; ik neem aan dat een document dat makkelijker te parsen is ook sneller te parsen is. Hiervoor heb ik geen tools gevonden; ook niet voor het verschil tussen tables/css layout etc.

Wie weet er meer?

[crisp]

Nette html, css en js; ik neem aan dat een document dat makkelijker te parsen is ook sneller te parsen is. Hiervoor heb ik geen tools gevonden; ook niet voor het verschil tussen tables/css layout etc.

Elementen die impliciet zijn maar optioneel toch expliciet in je markup zetten versnelt het parsen. Denk hierbij aan html en body elementen (die zal je ws wel hebben) maar ook aan tbody bijvoorbeeld. Ook elementen met optionele sluittags toch expliciet afsluiten vergemakkelijkt het renderen.
Fixed table-layouts met eventueel afmetingen al in een colgroup scheelt ook al.

Verder: geen resources inladen van 3rd parties (maar dat is helaas niet altijd mogelijk)

[bartvb]

Dit balletje is ook bij mij weer gaan rollen door problemen met Google Analytics afgelopen week...

Tja, ligt er nogal aan wat je sneller wilt krijgen. Een hoop van de dingen die je (chem) noemt zijn eigenlijk alleen boeiend voor de eerste pageload en die mag wat mij betreft best (iets) langer duren. Daarna wordt 95% van de objecten op een pagina gecached, iig als je het goed doet. Dingen als request_multiple e.d. zou ik dus niet doen (hoe doe je dat trouwens?), lijkt me dat dat de potentiele problemen (incompatibiliteit, lastig debuggen) niet waard is. Zeker niet omdat dingen als .js en .css prima gecached kunnen worden.

De frontpage bestaat trouwens (na caching) uit 1 html file, 1 js ding (ads) van tweakers.net en dan een stuk of 6 requests naar webads. De rest van de tijd zit volgensmij voornamelijk in de toch behoorlijk complexe setup van de pagina. Handigste manier om daar wat aan te doen is zo'n pagina lokaal opslaan, verwijzingen naar extern spul (webads) verwijderen en de toolbar installeren die ik noemde. Deze laat zien hoe lang je browser (of ja, firefox in dit geval) nodig heeft om de boel weer te geven. Laad de pagina een paar keer, reken het gemiddelde uit en verander dan het e.e.a. aan de pagina of verwijder wat blokken 1 voor 1 om de relatieve performance hit uit te rekenen. Venkman doe trouwens wel aan profiling voor javascript, weet niet in hoeverre deze iets kan melden over parse tijden van de HTML en het opbouwen en verbouwen van de DOM

[chem]

js en css kan wel gecached worden (idem voor tilemaps als losse afbeeldingen), maar als je een revalidate tijd hebt die vrij laag staat dan zijn het mogelijk toch talloze 304-headers die uitgewisseld worden; en dat verminderen levert toch een tijdwinst op.
Daarbij is een eerste impressie vaak toch erg belangrijk.

Owh, en dat soort tools gebruik je dus alleen bij deployed websites; niet in test of develop omgeving

offtopic:
de request_multiple is in essentie vreselijk simpel; een komma-seperated lijst van js-files die je wil hebben plakt-ie met een newline ertussen aan elkaar en serveert hij naar buiten; daar komt dan weer de nodige caching, 304-headers etc. bij kijken (en bij css files @import statements), maar dat spreekt voor zich

Het profilen van JS enzo zie ik nog wel zitten, daar komt het nog wel een keer van; we gebruiken nu erg veel dezelfde technieken, dus optimalisaties hoeven niet per se veel tijd te kosten.

Wat we met de google analytics nog overwogen is om de .js file door js te laten "includen", zodat de gebruiker er geen last van heeft. Of beter gezegd, pas als de pagina toch al klaar was.

edit:
Die toolbar rekent trouwens geen achtergrondafbeeldingen mee etc.

[ Voor 4% gewijzigd door chem op 11-03-2006 16:07 ]

[JaQ]

Ik heb in het verleden jmeter hier ook eens voor gebruikt. Geef fancy GUI, geen ladingen mumbo-jumbo, maar concrete cijfers waar je wat mee kan (naar mijn, in dit geval zeer bescheiden, mening)

[chem]

Die heb ik ook wel eens gebruikt maar een eerste test kost best veel tijd; en het blijft netwerk-meten. Leuk, maar vooral geschikt om je applicatie in het geheel te stress-testen op load en responstijden; niet op de ervaring voor gebruikers.

[bartvb]

Tja,revalidatie tijd gewoon hoog zetten Die 304's zijn idd zwaar irritant. Als iemand trouwens een manier weet om te voorkomen dat alles weer opnieuw ververst wordt met een F5 dan houd ik me aanbevolen (moet zeggen dat ik daar nog niet echt diep ingedoken ben).

Het aan elkaar plakken van files om te voorkomen dat je bij de eerste pageview een paar hits minder hebt levert IMO meer problemen op dan het waard is. Die 50 extra milliseconde bij de eerste pageview gaan het verschil niet maken wat eerste indruk betreft, al helemaal niet als de site verder ook gewoon snel is. Het grote probleem zijn scripts die een halve seconde bezig zijn met het ombouwen van je DOM of externe scripts die van servers af komen die 3 seconde nodig hebben om een keer antwoord te geven. Je pagina of applicatie ingewikkelder (en dus foutgevoeliger) maken voor 1 malig een marginaal snellere pageload zou niet mijn voorkeur genieten

jmeter heb ik in een grijs verleden ook wel eens mee gespeeld maar dat is idd vooral voor het testen van je server (wat chem ook al zei ).

Die extensie voor Firefox neemt volgensmij alles mee? Alles tussen het starten van de pageload en 'Done'.

[Blaise]

Niet gedetailleerd, maar wel leuk om even mee te spelen, is een webbased tooltje van websiteoptimization.com.

[Spider.007]

bartvb schreef op zaterdag 11 maart 2006 @ 18:25:
Tja,revalidatie tijd gewoon hoog zetten Die 304's zijn idd zwaar irritant. Als iemand trouwens een manier weet om te voorkomen dat alles weer opnieuw ververst wordt met een F5 dan houd ik me aanbevolen (moet zeggen dat ik daar nog niet echt diep ingedoken ben).

Waarom vind je 304's irritant? Verder> of een F5 alles reload is afhankelijk van meerdere zaken. Initieel is het al van belang wat je browser voor headers verstuurd (een shift-reload geeft bijvoorbeeld een pragma-no-cache mee). Verder is het een kwestie van goede LastModified meesturen, letten of je MustRevalidate doet en uiteraard je Expiry goedzetten. Dit is allemaal een kwestie van tunen; en goed opletten wat je eigenlijk wilt.

Handige link: http://www.ircache.net/cgi-bin/cacheability.py

Blaise schreef op zaterdag 11 maart 2006 @ 19:28:
Niet gedetailleerd, maar wel leuk om even mee te spelen, is een webbased tooltje van websiteoptimization.com.

Let op; dat ding gaat niet goed om met base-hrefs

[ Voor 17% gewijzigd door Spider.007 op 13-03-2006 11:09 ]

[chem]

bartvb schreef op zaterdag 11 maart 2006 @ 15:45:
Venkman doe trouwens wel aan profiling voor javascript, weet niet in hoeverre deze iets kan melden over parse tijden van de HTML en het opbouwen en verbouwen van de DOM

Net met venkman een beetje gespeeld, maar ik krijg wel wat vreemde resultaten. Functies die eenmalig worden aangeroepen en vv 3-5x in de profile-output staan

Wel een aantal verbeteringen snel kunnen vinden, dus geen verspilde tijd

[bartvb]

304s zijn irritant omdat het schijnbaar nogal moeilijk is voor browsers om ook echt te vertrouwen op Expiry headers e.d. Het overgrote deel van het verkeer op m'n static server bestaat uit antwoord geven op 304's (nee, dat plaatjes is ECHT niet veranderd). Iig de laatste keer dat ik er naar keek. Al een tijdje niets meer mee gedaan.

Die www.ircache.net is idd handig Thanks! Als iemand een fatsoenlijk overzicht weet van de beschikbare headers, wat ze horen te doen en wat de browsers er daadwerkelijk mee doen dan houd ik me aanbevolen. Heb me de vorige keer gruwelijk zitten ergeren aan de gare of soms zelfs ronduit foute implementatie van dat caching spul in een aantal browsers

[Superdeboer]

bartvb schreef op maandag 13 maart 2006 @ 13:13:
Die www.ircache.net is idd handig Thanks! Als iemand een fatsoenlijk overzicht weet van de beschikbare headers, wat ze horen te doen en wat de browsers er daadwerkelijk mee doen dan houd ik me aanbevolen. Heb me de vorige keer gruwelijk zitten ergeren aan de gare of soms zelfs ronduit foute implementatie van dat caching spul in een aantal browsers

offtopic:
Hoewel dat misschien offtopic is hier, hang ik dan ook aan de lippen van degene die met een goede oplossing komt. Ik heb zelf ooit eens zitten testen met de implementatie van Anne van Kesteren om PHP-pagina's een 304 terug te kunnen laten geven. Dat werkt op zich goed... alleen bij mijn test kon de gebruiker een pref instellen voor een stylesheet. Die css-keuze werd dan uit de db getrokken en in de html HEAD geplaatst. Een last-modified header op basis van laatste post-datum werkt dan niet meer natuurlijk, aangezien er een wijziging in de HTML optreedt ná die laatste post, door de user zelf. Voor dat doeleinde paste ik dan de Etag aan (een component van die string was dus de css die de user als pref had), maar dat werkte helaas voor geen meter in Internet Explorer (in werkte het Firefox precies zoals ik verwachtte overigens) en dus was het eigenlijk alsnog onbruikbaar jammer genoeg.
Een complete hufterproof implementatie van een cachingsysteem voor PHP-pagina's dat in de belangrijkste browsers goed werkt, zou me ontzettend fijn lijken.

[chem]

http://www.naarvoren.nl/artikel/performance/ heeft toevallig ook een artikel gepubliceerd.