Performance van een webapplicatie

[TeeDee]

Een reeds bestaande webapplicatie performed onder IE6 zeer slecht. Laadtijden per pagina van ~10 seconden zijn normaal. Let wel, die ~10 seconden zijn alleen onder IE6. (Fx, IE7 laden acceptabel (~3 sec.). En om alvast de IE6 boeroepers voor te zijn: het zijn o.a. franse gebruikers in afgelegen gebieden op oude machines: upgraden is voor hun geen optie op dit moment. We zitten dus in een heftig welles, nietes traject met één van onze opdrachtgevers.

Ik heb de nobele taak gekregen om te inventariseren waar we mogelijk op een snelle en gemakkelijke manier performance winsten kunnen behalen.

De gebruikelijke methodes zijn in ieder geval het lijstje van YSlow. Daar zitten een aantal zaken in welke niet op vrij gemakkelijke manier in de bestaande applicatie te verwerken zijn. Het gaat hier om een asp.net webapplicatie met 3rd party controls (DevExpress) dus even zomaar de images, styles en javascripts aan passen is geen gemakkelijke opgave. We zijn reeds bezig om de applicatie conform standaarden te bouwen (uiteraard ook met de benodigde semantiek in het achterhoofd). Alleen de klant heeft nu een probleem, en dit probleem moet nu opgelost worden.

Omdat de steekwoorden snel en simpel zijn heb ik een aantal kleine aanpassingen 'bedacht', waarbij ik graag de mening van een groter publiek zou willen hebben. Dit, en om mijn bevindingen te staven alvorens ik het e.e.a. ga implementeren.

Cookies
Uit onderzoek blijkt dat een cookie van deze applicatie exact 4096 bytes is. Volgens MSDN kan een cookie in IE5.5 (mogelijk ook 6???) maximaal 4096 bytes bevatten. Nu weet ik niet helemaal hoe het mechanisme werkt, maar wordt er een soort FiFo systeem gebruikt waarbij de cookie constant opnieuw aangemaakt wordt, gevuld tot de max. bytes en daardoor er voor zorgt dat het laden traag is/gaat?

Het volledig negeren van cookies gaat vanwege het karakter van de applicatie niet, maar het limiteren van de cookie info kan een snelheidswinst opleveren?

Javascripting
Zoveel mogelijk javascript scripts voorzien van het "defer" attribuut? Dit is natuurlijk vrij gemakkelijk te testen, alleen de webapplicatie draait op het lokale netwerk van de klant. Ook in Frankrijk dus. Onze test- en acceptatieomgevingen performen perfect onder IE6 i.e. geen verschil met Fx en IE7.

Meta tag

HTML:

meta http-equiv="Page-Exit" content="blendTrans(Duration=0.0)" />

Het lijkt misschien vrij nutteloos, alleen de interface lijkt responsief. Dat is natuurlijk ook vrij belangrijk. (Alles om de klant tevreden te krijgen).

Afbeeldingen
Er staat helemaal onderaan een afbeelding.aspx. Dit is een dummy afbeelding om de sessie niet te laten verlopen. Deze wordt om de n-minuten met een Javascript Interval ververst. De afbeelding lijkt traag te laden (volgens YSlow). Na onderzoek wordt dit geserveerd als text/html. Zou het schelen om daar een image/<contenttype> op terug te laten geven?

Server settings
De netwerk topologie van de klant is mij niet bekend, maar kan bij een brak netwerk in combinatie met Reverse DNS lookups een dusdanige performance drop geven? Tevens is de webserver zo geconfigureerd dat de Web- en Scriptresources alsmede de .Aspx en static files in IIS gecached worden. Http Compression is ook ingeschakeld.

Client Settings
Het kan zijn dat een <vendor> Antivirus pakket performance drops kan geven. Ervan uitgaande dat er helemaal geen Antivirus pakket draait kunnen we dat alvast uitsluiten.

De reden dat veel vragen een open karakter hebben is dat we het hier in diverse omgevingen het probleem niet kunnen traceren en/of reproduceren. Een Virtual PC Image (XP, IE6 en 128 Mb RAM) draait prima. Om ongeveer een strekking van de klacht te geven:

Het draait k.u.t., doe er wat aan

[Cloud]

TeeDee schreef op woensdag 04 juni 2008 @ 12:08:
Afbeeldingen
Er staat helemaal onderaan een afbeelding.aspx. Dit is een dummy afbeelding om de sessie niet te laten verlopen. Deze wordt om de n-minuten met een Javascript Interval ververst. De afbeelding lijkt traag te laden (volgens YSlow). Na onderzoek wordt dit geserveerd als text/html. Zou het schelen om daar een image/<contenttype> op terug te laten geven?

Waarom zou je op die manier de sessie niet laten verlopen? Kun je niet gewoon de Session-timeout veel hoger zetten in IIS en je ASP.NET applicatie? Dat lijkt mij een veel simpelere en vooral nettere oplossing. En het scheelt requests.

[Greyfox]

Aangezien het afgelegen gebieden zijn, kan het dan niet liggen aan de netwerkverbinding?

[Johnny]

In het begin stel je dat het probleem bij IE6 ligt en vervolgens zeg je dat je het niet kan reproduceren met IE6. Is het dan niet aannemelijker dat het probleem ergens anders ligt? Bijvoorbeeld in het netwerk?

[TeeDee]

Cloud schreef op woensdag 04 juni 2008 @ 12:11:
[...]
Waarom zou je op die manier de sessie niet laten verlopen? Kun je niet gewoon de Session-timeout veel hoger zetten in IIS en je ASP.NET applicatie? Dat lijkt mij een veel simpelere en vooral nettere oplossing. En het scheelt requests.

Er zijn gebruikers die de applicatie ~ 5 dagen open houden staan. Maar het is inderdaad iets om in te duiken (en dan voornamelijk geheugen, cpu gebruik aan de serverzijde).

Greyfox schreef op woensdag 04 juni 2008 @ 12:12:
Aangezien het afgelegen gebieden zijn, kan het dan niet liggen aan de netwerkverbinding?

Op lokatie met een IE7 en Fx aan hun netwerk gehangen, en het gaat gewoon normaal.

Johnny schreef op woensdag 04 juni 2008 @ 12:15:
In het begin stel je dat het probleem bij IE6 ligt en vervolgens zeg je dat je het niet kan reproduceren met IE6. Is het dan niet aannemelijker dat het probleem ergens anders ligt? Bijvoorbeeld in het netwerk?

^^ zie mijn quote hierboven. De strekking is eigenlijk ook: IE6 gebruikers klagen. Wij kunnen het met IE6 niet reproduceren, dus moeten we alles uit de kast gaan halen om de klagende IE6 gebruikers tevreden te krijgen. En dan voornamelijk, met in mijn ogen micro-optimalisaties.

[ Voor 26% gewijzigd door TeeDee op 04-06-2008 12:19 ]

[Voutloos]

TeeDee schreef op woensdag 04 juni 2008 @ 12:08:
Cookies
Uit onderzoek blijkt dat een cookie van deze applicatie exact 4096 bytes is. Volgens MSDN kan een cookie in IE5.5 (mogelijk ook 6???) maximaal 4096 bytes bevatten. Nu weet ik niet helemaal hoe het mechanisme werkt, maar wordt er een soort FiFo systeem gebruikt waarbij de cookie constant opnieuw aangemaakt wordt, gevuld tot de max. bytes en daardoor er voor zorgt dat het laden traag is/gaat?

Anders bekijk je uberhaupt wat je met cookies doet cq. bekijk je zo'n cookie?

Het volledig negeren van cookies gaat vanwege het karakter van de applicatie niet, maar het limiteren van de cookie info kan een snelheidswinst opleveren?

Ja, want request is kleiner. Maar het versturen van de request zal wel niet de oorzaak zijn van 10s laadtijden.

HTML:

meta http-equiv="Page-Exit" content="blendTrans(Duration=0.0)" />

Het lijkt misschien vrij nutteloos, alleen de interface lijkt responsief. Dat is natuurlijk ook vrij belangrijk. (Alles om de klant tevreden te krijgen).

Transities zijn stom, suf, saai en moeten dood.

Afbeeldingen
Zou het schelen om daar een image/<contenttype> op terug te laten geven?

Je moet *&%^# alles met correcte headers serveren.

Overigens noem je aantal zeer belangrijke optimalisaties niet, zoals het terugbrengen van het aantal requests en het cachebaar maken van responses.

[TeeDee]

Voutloos schreef op woensdag 04 juni 2008 @ 13:01:
Anders bekijk je uberhaupt wat je met cookies doet cq. bekijk je zo'n cookie?

Wat bedoel je hiermee?

Ja, want request is kleiner. Maar het versturen van de request zal wel niet de oorzaak zijn van 10s laadtijden.

Duidelijk. We zullen alleen wel even moeten kijken of bepaalde informatie in de cookie weg kan.

Transities zijn stom, suf, saai en moeten dood.

I know, alleen door het gebruik van blendTrans zitten de gebruikers niet n seconden tegen een wit scherm aan te kijken.

Je moet *&%^# alles met correcte headers serveren.

Ook hierbij kan je je natuurlijk afvragen of dat zo'n grote performance winst kan opleveren. Dat het niet goed is, wist ik al

Overigens noem je aantal zeer belangrijke optimalisaties niet, zoals het terugbrengen van het aantal requests en het cachebaar maken van responses.

Uit de TS:

De gebruikelijke methodes zijn in ieder geval het lijstje van YSlow

en onder het kopje Server Settings staat volgens mij wel het e.e.a. Response cache had ik inderdaad moeten vermelden, maar het 'schijnt' dat dit wel het geval is. Aan de andere kant is dat nog geen verklaring voor het specifieke IE6 gedrag.

[Janoz]

TeeDee schreef op woensdag 04 juni 2008 @ 12:08:

Javascripting
Zoveel mogelijk javascript scripts voorzien van het "defer" attribuut? Dit is natuurlijk vrij gemakkelijk te testen, alleen de webapplicatie draait op het lokale netwerk van de klant. Ook in Frankrijk dus. Onze test- en acceptatieomgevingen performen perfect onder IE6 i.e. geen verschil met Fx en IE7.

Hier hebben we alvast punto numero uno te pakken. Voordat je uberhaupt ook maar 1 minuut aan dit probleem gaat besteden zul je hiernaar moeten kijken. Uiteraard heb ik het dan niet over het defer attribuut, maar over het reproduceren van het probleem.

Zolang je het probleem niet kunt reproduceren en dus eigenlijk alleen maar af kunt gaan op wat de klant verteld kun je nooit constructief bezig zijn. Het enige wat je nu kunt doen is aan dit palletje frotten en kijken wat ze gaan zeggen, vervolgens aan dit pieletje draaien en de resultaten uit frankrijk af gaan wachten.

Het aller eerste dat je zult moeten gaan doen is een gecontroleerde omgeving opzetten waarin het specifieke probleem zich voordoet. Krijg je het hier niet voor elkaar, dan moet je maar naar de lokatie gaan om het probleem daar te aanschouwen. Als dat betekent dat je daarvoor naar Frankrijk moet, then so be it. Een andere constructieve manier is er gewoon niet...

[Voutloos]

TeeDee schreef op woensdag 04 juni 2008 @ 13:10:
[...]

Wat bedoel je hiermee?

Je weet niet hoe het mechanisme werkt of wat (deze) cookies doen --> zoek het uit.

[RobIII]

TeeDee schreef op woensdag 04 juni 2008 @ 12:17:
^^ zie mijn quote hierboven. De strekking is eigenlijk ook: IE6 gebruikers klagen.

Eerst zeg je:

TeeDee schreef op woensdag 04 juni 2008 @ 12:08:
En om alvast de IE6 boeroepers voor te zijn: het zijn o.a. franse gebruikers in afgelegen gebieden op oude machines: upgraden is voor hun geen optie op dit moment.

Nogal logisch: de lui die klagen zijn automatisch de lui in de afgelegen gebieden en dus (automatisch) ook IE6 (volgens jou). Dan blijkt het niet aan IE6 te liggen (want; VM doet het wel goed) en dan ga je niet eens verder kijken naar andere oorzaken zoals GreyFox bijvoorbeeld oppert?

En ik vind het een bull argument dat upgraden niet mogelijk is; als het vanwege een policy niet mag ofzo is andere koek, maar ze kunnen daar natuurlijk ook prima een CD'tje branden (of beter: stuur er 1 op ) of op een enkele PC een upgrade doen om te zien of dat het probleem oplost. En anders heb je nog altijd in een paar MB's een andere browser (FF, Opera, whatever) gedownload om te zien of het probleem zich dan (nog steeds) voor doet => trage lijn en dat soort zaken.

Problemen los je op door 1 voor 1 dingen uit te sluiten om zo (uiteindelijk) de oorzaak te lokaliseren en op te lossen. Niet door in het donker met een honkbalknuppel te gaan rondslaan en hopen dat je iets raakt ((micro)optimalisaties e.d.)

[Tubby]

Heb je IE6 al in combinatie met een pc uit het jaar kruik geprobeert?

Wellicht dat je javascripts een beetje heftig zijn en dat oude machines daar gewoon even mee zoet zijn

En je moet het eerst reproduceerbaar hebben voordat je gericht kan gaan oplossen. En anders moet je inderdaad op lokatie gaan werken.

[ Voor 27% gewijzigd door Tubby op 04-06-2008 13:55 ]

[TeeDee]

Voutloos schreef op woensdag 04 juni 2008 @ 13:46:
[...]
Je weet niet hoe het mechanisme werkt of wat (deze) cookies doen --> zoek het uit.

Ik weet wat cookies doen. Ik weet alleen niet of er een soort stack systeem is wat er voor zorgt dat het traag kan worden als een cookie zeg maar constant moet swappen.

Vandaar ook een beetje de disclaimer mbt het karakter van de vraagstelling. Ik zoek eigenlijk wat mogelijke ingangen om te kijken waar we op een simpele manier, dus zonder het compleet te moeten herschrijven, de applicatie kunnen versnellen.

Janoz schreef op woensdag 04 juni 2008 @ 13:43:
[...]
Hier hebben we alvast punto numero uno te pakken. Voordat je uberhaupt ook maar 1 minuut aan dit probleem gaat besteden zul je hiernaar moeten kijken. Uiteraard heb ik het dan niet over het defer attribuut, maar over het reproduceren van het probleem.

Wat betreft het reproduceren: er is inmiddels een systeem met IE6 gevonden waardoor we het e.e.a. kunnen gaan testen. De eerste indrukken zijn: ook op dat systeem is het traag. Afgaande op de Virtual PC Image met XP en IE6, wat dus wel een goede performance heeft, trokken we in eerste instantie dus verkeerde conclusies.

RobIII schreef op woensdag 04 juni 2008 @ 13:49:
Nogal logisch: de lui die klagen zijn automatisch de lui in de afgelegen gebieden en dus (automatisch) ook IE6 (volgens jou). Dan blijkt het niet aan IE6 te liggen (want; VM doet het wel goed) en dan ga je niet eens verder kijken naar andere oorzaken zoals GreyFox bijvoorbeeld oppert?

En een eigen laptop met IE7 en FireFox op locatie werkt wel prima. Mag jij me vertellen op wat voor manier het dan aan het netwerk kan liggen.

En ik vind het een bull argument dat upgraden niet mogelijk is; als het vanwege een policy niet mag ofzo is andere koek, maar ze kunnen daar natuurlijk ook prima een CD'tje branden (of beter: stuur er 1 op ) of op een enkele PC een upgrade doen om te zien of dat het probleem oplost. En anders heb je nog altijd in een paar MB's een andere browser (FF, Opera, whatever) gedownload om te zien of het probleem zich dan (nog steeds) voor doet => trage lijn en dat soort zaken.

Ach kom op RobIII, jij moet toch weten hoe gebruikers/klanten kunnen doen.

Problemen los je op door 1 voor 1 dingen uit te sluiten om zo (uiteindelijk) de oorzaak te lokaliseren en op te lossen. Niet door in het donker met een honkbalknuppel te gaan rondslaan en hopen dat je iets raakt ((micro)optimalisaties e.d.)

We zijn nog in de voorbereidende fase. En om met jouw analogie door te gaan: we zijn nu aan het kijken of we met die honkbalknuppel uberhaupt iets kunnen raken.

Tubby schreef op woensdag 04 juni 2008 @ 13:54:
Heb je IE6 al in combinatie met een pc uit het jaar kruik geprobeert?

We hebben er inmiddels één gevonden.

Wellicht dat je javascripts een beetje heftig zijn en dat oude machines daar gewoon even mee zoet zijn

De gegenereerde Javascripts zijn inderdaad heftig. Dat is iets waar we op korte termijn niets aan kunnen doen.

Edit:Ik zie dat de informatie over het op locatie geweest zijn helemaal weg is. Daar had ik nog een alinea over staan in mijn oorspronkelijke TS. Denk dat dat weggevallen is door het 'Bekijk bericht' etc. etc.

[ Voor 3% gewijzigd door TeeDee op 04-06-2008 14:29 ]

[Meekoh]

Wij hebben ook ooit zo'n probleem gehad met onze webapp. Deze vertrouwd ook heel erg op Javascript en je zag gewoon bij de klant (in UK) dat zijn CPU stond te pieken als een gek, toen vroeg ik naar wat de specs van de pc waren. Deze waren ietwat aan de lage kant (pentium 3 800Mhz machines). Bij ons op onze Core 2 duo's ging het allemaal lekker soepel en snel. Bleek dus dat die machines niet zo rap waren in het op het scherm krijgen van een webgrid. Wij konden ze zeggen dat ze moesten upgraden, bij jou kan dat misschien niet dus denk dat je je javascript in moet duiken...

[ Voor 16% gewijzigd door Meekoh op 04-06-2008 14:37 ]

[Dark Blue]

Je kan geloof ik in je browser ook gewoon Javascript uitzetten. Als je nu eens die testpc die jullie gevonden hebben aanslingeren, Javascript uitzetten en dan de site runnen? Dan is hij wellicht lelijker maar je kunt wel gelijk zien of die Javascripts 'm de das omdoen.

En hey, wat is er mis met een reisje Frankrijk op kosten van de zaak?

[RobIII]

TeeDee schreef op woensdag 04 juni 2008 @ 14:08:
En een eigen laptop met IE7 en FireFox op locatie werkt wel prima. Mag jij me vertellen op wat voor manier het dan aan het netwerk kan liggen.

Ik zei dan ook zoals...

TeeDee schreef op woensdag 04 juni 2008 @ 14:08:
Ach kom op RobIII, jij moet toch weten hoe gebruikers/klanten kunnen doen.

Jazeker, maar wat wil je nou van ons horen? Dat je zelf naar Frankrijk moet sjezen? Of je pleegt een telefoontje/email naar 1 van je betere klanten waar je een beetje dik mee bent en je probeert samen met hem tot een oplossing te komen. Ik weet donders goed hoe klanten (kunnen) zijn, maar je mag ook best wat medewerking vragen als ze een oplossing willen en je kunt het niet reproduceren. Zelfs grote jongens als (pak) Microsoft, IBM, Oracle en ga zo maar door werken nauw samen met resellers/klanten/testers door heel de wereld om dit soort (vage, niet lokaal te reproduceren) problemen op te lossen. Of is dat pijnlijk voor jullie ego?

TeeDee schreef op woensdag 04 juni 2008 @ 14:08:
We zijn nog in de voorbereidende fase. En om met jouw analogie door te gaan: we zijn nu aan het kijken of we met die honkbalknuppel uberhaupt iets kunnen raken.

Om daar dan weer op in te haken: Doe het licht eens aan

TeeDee schreef op woensdag 04 juni 2008 @ 14:08:
Edit:Ik zie dat de informatie over het op locatie geweest zijn helemaal weg is. Daar had ik nog een alinea over staan in mijn oorspronkelijke TS. Denk dat dat weggevallen is door het 'Bekijk bericht' etc. etc.

Dat is wel redelijk relevante info ja Net zoals dat je laptop het daar wel goed deed.
Zijn de specs van die PC's daar dan zo laag? Er moet toch een aanwijsbare reden voor zijn

[ Voor 9% gewijzigd door RobIII op 04-06-2008 15:54 ]

[TeeDee]

Dark Blue schreef op woensdag 04 juni 2008 @ 15:32:
Je kan geloof ik in je browser ook gewoon Javascript uitzetten. Als je nu eens die testpc die jullie gevonden hebben aanslingeren, Javascript uitzetten en dan de site runnen? Dan is hij wellicht lelijker maar je kunt wel gelijk zien of die Javascripts 'm de das omdoen.

Zonder Javascript is de applicatie niet werkend te krijgen. En dat is een beetje jammer.

En hey, wat is er mis met een reisje Frankrijk op kosten van de zaak?

Zo'n reisje is geen snoepreisje, dat kan ik je wel vertellen.

RobIII schreef op woensdag 04 juni 2008 @ 15:51:
Jazeker, maar wat wil je nou van ons horen? Dat je zelf naar Frankrijk moet sjezen? Of je pleegt een telefoontje/email naar 1 van je betere klanten waar je een beetje dik mee bent en je probeert samen met hem tot een oplossing te komen. Ik weet donders goed hoe klanten (kunnen) zijn, maar je mag ook best wat medewerking vragen als ze een oplossing willen en je kunt het niet reproduceren. Zelfs grote jongens als (pak) Microsoft, IBM, Oracle en ga zo maar door werken nauw samen met resellers/klanten/testers door heel de wereld om dit soort (vage, niet lokaal te reproduceren) problemen op te lossen. Of is dat pijnlijk voor jullie ego?

Het betreft hier onder andere een welles, nietes issue. Wij zijn aan het/willen uit zoeken waar het aan ligt. We zijn er bijna (IE6 op een (oude) PC) en met dat advies kunnen we dus naar de klant. Maar de klant wil niet investeren in iets wat volgens hun aan ons ligt. Daar moeten we nu dus over bomen. Het is voorlopig onwil van de klant om te upgraden.

Om daar dan weer op in te haken: Doe het licht eens aan

Kon het lichtknopje niet vinden, mede dankzij het verkeerde beeld wat we gekregen hebben door Virtual PC.

Dat is wel redelijk relevante info ja Net zoals dat je laptop het daar wel goed deed.

Dat, zoals ik al zei, had inderdaad erin moeten staan, maar vergeef me, het is/was een flinke TS voor mijn doen, en het e.e.a. is weggevallen.

Zijn de specs van die PC's daar dan zo laag? Er moet toch een aanwijsbare reden voor zijn

De oude IE6 testmachine is, achteraf gezien, een flinke office pc. P4 1,7 Ghz met 1 Gb Ram. Op datzelfde systeem staat ook een Firefox 2. Qua performance rent die setup (dus Firefox) rondjes om dezelfde PC met IE6. We kunnen nu dus pinpointen dat het om IE6 gaat, en niet zozeer de systeem eisen.

[ Voor 61% gewijzigd door TeeDee op 04-06-2008 16:19 ]

[JJvG]

Heb zelf ook redelijk wat te maken gehad met performance en wat ik meestal doe is het volgende:
- Eerst inventariseren welke componenten je mee te maken hebt
- Dan bepalen welke componenten mogelijke bottlenecks zijn
- Verschillende scenario's met op de verschillende componenten testen

Als ik je bovenstaande verhaal lees concludeer ik tot nu toe het volgende:
Componenten zijn:
- Server hardware
- Netwerk verbinding
- Client hardware
- Client software

Je geeft aan dat het op andere locaties en met andere browsers wel goed werkt en dat het een flinke office PC is: De eerste drie zullen dus niet het probleem zijn. Blijft over: de client software (dus:IE6).

Ik weet dat IE6 erg slecht is in het verwerken van javascript en veel moeite heeft met (complexe) geneste tabellen. Zeker de combinatie is killing. Ik vermoed dat Webgrid of clientside-sorteringsmogelijkheden best een bottleneck kunnen vormen bij het opbouwen van de pagina. Op de frontpage van tweakers.net staat een mooi scriptje waarmee je de client-side parsing time kan monitoren. Die kun je in de statusbar schrijven (zoals hier wordt gedaan), of als paramenter aan een (zelfgemaakte) asp(x) pagina meegeven. Probeer de clientside en serverside parsing tijden te achterhalen (liefst incl. gebruikersgegevens)

Nog even heel pragmatisch misschien, maar waarom maken ze niet gewoon gebruik van Firefox, als dat goed genoeg werkt?

[bigbeng]

JJvG schreef op donderdag 05 juni 2008 @ 12:47:
...
Ik weet dat IE6 erg slecht is in het verwerken van javascript en veel moeite heeft met (complexe) geneste tabellen. Zeker de combinatie is killing.
...

Wat ook aardig is om te weten, is dat wij in een aantal van onze omgevingen ontdekt hebben dat de combinatie javascript + geneste tabellen + Windows XP Theme tot verhoogde rendertijden leidden. Bij ons (op P4 2.4 GHZ bakken) leidde dat soms tot 2+ seconden extra rendertijd op niet heel erg data intensieve webpagina's.

Je zou eens kunnen kijken of het uitzetten van themes (oftewel lekker naar windows classic mode) tot verbeterde performance leidt. Niet echt een structurele oplossing, maar mogelijk hou je de klant/gebruiker dan in elk geval tot de upgrade (dit gaat gebeuren, toch? ) rustig.

[TeeDee]

JJvG schreef op donderdag 05 juni 2008 @ 12:47:
Ik weet dat IE6 erg slecht is in het verwerken van javascript en veel moeite heeft met (complexe) geneste tabellen. Zeker de combinatie is killing. Ik vermoed dat Webgrid of clientside-sorteringsmogelijkheden best een bottleneck kunnen vormen bij het opbouwen van de pagina. Op de frontpage van tweakers.net staat een mooi scriptje waarmee je de client-side parsing time kan monitoren. Die kun je in de statusbar schrijven (zoals hier wordt gedaan), of als paramenter aan een (zelfgemaakte) asp(x) pagina meegeven. Probeer de clientside en serverside parsing tijden te achterhalen (liefst incl. gebruikersgegevens)

Dat het traag is in IE6 door het veelvuldig (en mogelijk onjuist gebruik van) tabellen en/of javascript was ons inmiddels al duidelijk. Het enige wat we uit willen sluiten is bijvoorbeeld het aangedragen punt mbt de cookies, script defer etc. etc.

De afbeelding.aspx is inmiddels uit de masterpage gehaald. Dit moeten we dus nog gaan testen. Als laatste heb ik inderdaad al een soort clientside performancce metertje gebouwd. Deze zal zsm in het systeem terecht komen.

Nog even heel pragmatisch misschien, maar waarom maken ze niet gewoon gebruik van Firefox, als dat goed genoeg werkt?

Het laatste argument is eigenlijk: IT heeft geen zin/tijd om een andere browser te installeren.

[Voutloos]

TeeDee schreef op donderdag 05 juni 2008 @ 13:10:
Het laatste argument is eigenlijk: IT heeft geen zin/tijd om een andere browser te installeren.

Dat is wel een heel slecht argument. Ze hoeven echt niet elke dag hun best doen om cutting edge software te draaien (graag niet zelfs ), maar IE 6 mag al een tijdje dood. Meestal wordt aan IE6 vastgeklampt ivm bepaalde ouderwetse intranet sites, maar als dat hier niet het geval is, mag je anno 2008 toch wel fluitend naar 7 upgraden...

Zeker als hun dat minder tijd kost dan jij aan het ondersteunen van legacy browsers zou moeten besteden.

offtopic:
Het mag geen excuus zijn, maar een PIV 1.7 is geen flinke office pc, maar al reeds jarenlang afgeschreven meuk. Gezien de huidige hardware prijzen tov salarissen maak je al gauw over het totaalplaatje winst door wat low end/mainstream 2008 spul neer te zetten.

[alex3305]

Overigens wil ik even kwijt aan TeeDee dat er altijd wel Javascripts zijn die uit kunnen staan zonder het systeem qua 'echte' functionaliteiten aan te passen.

Ga dus eerst met die javascripts testen voordat je uberhaupt conclusies gaat trekken, want wat je nu doet is uitsluiten zonder te testen (althans dat gevoel heb ik) en dat moet je nooit doen...

EDIT:

Voutloos schreef op donderdag 05 juni 2008 @ 13:21:
[...]

offtopic:
Het mag geen excuus zijn, maar een PIV 1.7 is geen flinke office pc, maar al reeds jarenlang afgeschreven meuk. Gezien de huidige hardware prijzen tov salarissen maak je al gauw over het totaalplaatje winst door wat low end/mainstream 2008 spul neer te zetten.

offtopic:
Een Pentium IV 1.7Ghz is wel een flinke office PC hoor! Word, Excel en Powerpoint zullen er perfect op draaien en vooral met 512MB of meer geheugen erin. Bij mijn ouders draait het al jaren perfect. Kijk dat jij vindt dat er op een bedrijf een Core 2 Duo moet staan om Office te draaien, moet je zelf weten, ik vind dat persoonlijk zware overkill! Een thin client moet namelijk al genoeg zijn.

[ Voor 52% gewijzigd door alex3305 op 05-06-2008 13:36 ]

[TeeDee]

bigbeng schreef op donderdag 05 juni 2008 @ 13:10:
[...]
Wat ook aardig is om te weten, is dat wij in een aantal van onze omgevingen ontdekt hebben dat de combinatie javascript + geneste tabellen + Windows XP Theme tot verhoogde rendertijden leidden. Bij ons (op P4 2.4 GHZ bakken) leidde dat soms tot 2+ seconden extra rendertijd op niet heel erg data intensieve webpagina's.

Dat is iets wat we natuurlijk kunnen testen...

Je zou eens kunnen kijken of het uitzetten van themes (oftewel lekker naar windows classic mode) tot verbeterde performance leidt. Niet echt een structurele oplossing, maar mogelijk hou je de klant/gebruiker dan in elk geval tot de upgrade (dit gaat gebeuren, toch? ) rustig.

En dat kan dus in dit geval niet, want dan kan er net zo goed geupgrade worden. Als in: alle pc's langs.

Voutloos schreef op donderdag 05 juni 2008 @ 13:21:
[...]
Dat is wel een heel slecht argument. Ze hoeven echt niet elke dag hun best doen om cutting edge software te draaien (graag niet zelfs ), maar IE 6 mag al een tijdje dood. Meestal wordt aan IE6 vastgeklampt ivm bepaalde ouderwetse intranet sites, maar als dat hier niet het geval is, mag je anno 2008 toch wel fluitend naar 7 upgraden...

Zeker als hun dat minder tijd kost dan jij aan het ondersteunen van legacy browsers zou moeten besteden.

Het is ook een slecht argument. Maar als de opdrachtgever vooralsnog niet wil upgraden is dit een discussie die wij (en jij) toch niet kunnen winnen.

offtopic:
Het mag geen excuus zijn, maar een PIV 1.7 is geen flinke office pc, maar al reeds jarenlang afgeschreven meuk. Gezien de huidige hardware prijzen tov salarissen maak je al gauw over het totaalplaatje winst door wat low end/mainstream 2008 spul neer te zetten.

offtopic:
Komop, een PIV 1.7 met 1 Gb ram zou theoretisch voldoende voor simpel (waar dus de webapplicatie onder valt) office werk moeten zijn.

alex3305 schreef op donderdag 05 juni 2008 @ 13:33:
Overigens wil ik even kwijt aan TeeDee dat er altijd wel Javascripts zijn die uit kunnen staan zonder het systeem qua 'echte' functionaliteiten aan te passen.

Ga dus eerst met die javascripts testen voordat je uberhaupt conclusies gaat trekken, want wat je nu doet is uitsluiten zonder te testen (althans dat gevoel heb ik) en dat moet je nooit doen...

Jij kent DevExpress niet zeker?

[ Voor 38% gewijzigd door TeeDee op 05-06-2008 13:42 ]

[BtM909]

Ik snap een ding nog steeds niet.

Krijgen jullie het nou wel of niet gereproduceerd?

[TeeDee]

BtM909 schreef op donderdag 05 juni 2008 @ 13:38:
Ik snap een ding nog steeds niet.

Krijgen jullie het nou wel of niet gereproduceerd?

Jaja, we krijgen het nu wel gereproduceerd. We hebben op die P4 1.7 Ghz een XP met IE6 draaien. Een dramatisch verschil tussen XP met Virtual PC en een 'native' Windows XP installatie.

Edit:
Het uitschakelen van Themes (of Classic modus kiezen) biedt helaas ook geen soelaas.

[ Voor 24% gewijzigd door TeeDee op 05-06-2008 13:48 ]

[bigbeng]

TeeDee schreef op donderdag 05 juni 2008 @ 13:34:
...
En dat kan dus in dit geval niet, want dan kan er net zo goed geupgrade worden. Als in: alle pc's langs.
...

Ik bedoelde meer dat het als workaround aan klagende users kan worden aangeboden. Themes uitzetten kan iedere gebruiker (als je hem vertelt waar hij dat kan doen).

[TeeDee]

Kleine update:
We zijn in ieder geval een stap verder in de missie om de opdrachtgever/klant het gevoel te geven dat er een upgrade moet komen naar in ieder geval IE7. Maar goed, blijkt dus dat bij een nieuwe opdrachtgever er ook nog behoorlijk wat IE6 gebruikers (+/- 2000) zullen zijn. Laten we hopen dat deze opdrachtgever zijn netwerk + beheer wel op orde heeft.

Als laatste, voor de .net mensen:
We zijn druk bezig met het verkennen en testen van o.a. http://www.runtimepageoptimizer.com/. Zojuist mijn eerste support aanvraag verzonden, dus ik weet nog niet helemaal hoe dit in elkaar gaat steken. De eerste tests waren dusdanig dat ik er behoorlijk van onder de indruk ben.

Edit:
Voor alsnog is de support goed. Ze reageren vrij vlot en op de meest vreemde tijdstippen (aangezien ze in Nieuw Zeeland zitten).

Een simpel AspXGridView op een pagina, zonder LLBLgen datasource etc. geeft een standaard Grade C (+/- 10 request) en 175KB aan informatie in YSlow. Na het inschakelen van RPO ging dit naar een Grade A (+/- 3 requests) en 40 KB aan informatie.

Edit: nog vergeten te vermelden dat het verhogen van de session timeout naar ~ 1 dag geen resultaat gaf. De session is toch echt weg na ~ 20 minuten (De default tijd dus).

[ Voor 14% gewijzigd door TeeDee op 12-06-2008 16:50 ]

[TeeDee]

Een kleine update:
Na uitvoerig overleg met de mannen van DevExpress hebben we misschien een oplossing.

This issue has something to do with IIS6 + IE6 combination. Generally, the compression must be completely turned off to improve performance.

Aan de ene kant compleet onlogisch, aan de andere kant is er wel wat voor te zeggen. Nu is het nog even meten en testen.