Performance .net applicatie

[dotacom]

Beste Tweakers,

Ik ben junior sysengineer (samen met één collega) in een bedrijf dat .net applicaties ontwikkelt.
Deze applicaties worden oa geïnstalleerd op een testserver die op VMware draait. (ESXi 5.5)
Onlangs kreeg ik de "klacht" dat de applicaties opmerkelijk trager werken/aanvoeler op de testserver dan als de lokaal worden geïnstalleerd op de werkstations. Lokale werkstations zijn wél krachtige PC's met allemaal SSD.

Op het eerste zicht is er niks met met de performance van deze VM.(WS 2K8 R2)
Deze krijgt meer dan genoeg resources aangeboden en benut 99% van de tijd maar een kwart hiervan.

Ik vermoed dat het probleem ligt bij de storage waarop deze VM draait. Onze storage bestaat uit zes HP Lefthand P4500 nodes die individueel RAID-5 opgebouwd zijn. De aangemaakte volumes zijn Network Raid-10 (2-way mirror met thin provisioning). De connectie onderling verloopt via 10 Gb-netwerk.

Ik ben meer een IT-generalist en heb geen diepgaande kennis in bovenstaande zaken. Heb al zitten kijken in de Performance Monitor van de storage maar bezit momenteel helaas niet de nodige kennis om hier problemen uit af te leiden. IO Latency Total is gemiddeld 1.9 ms & IOPS Total is gemiddeld 34.1 IO/s.

Hoop dat ik niet te lazy overkom maar hoop op een aantal goeie reacties die mij op goeie weg zouden zetten om dit "probleem" op een correcte manier te troubleshooten.

[Knutselsmurf]

Meten is weten. En dan niet meten aan de storage, maar aan de applicatie. Wij kunnen niet raden wat de bottleneck van de applicatie is. Is dat de storage, pure CPU-power, GPU-rekenkracht, netwerk-snelheid?

Pas als je dat weet, kun je op dat punt gaan kijken naar de verschillen tussen de werkstations en de ESX-server

[raptorix]

Vinden er soms database queries plaats naar een andere server?
Ik moet zeggen dat het probleem herkenbaar is, toch is het echt doormeten vaak lastig omdat de resources op de server voldoende zijn, maar in de praktijk toch niet de performance opleveren die je zou verwachten.

[cvs79]

.net performance counters inbouwen en meten samen met de OS counters?

[RobIII]

Wat hierboven al gezegd is: meten == weten. Voor een snelle oplossing kun je eens kijken naar Metrics.Net. Dat is relatief snel en eenvoudig in te bouwen en beschikbaar als Nuget package.

Verder, maar dat is een long shot: ik heb er zelf ooit een paar dagen op gezocht (onze applicaties zijn erg zwaar WCF based): mocht(en) je VM('s) een e1000 o.i.d. virtual NIC gebruiken: bij ons maakte 't een verschil van dag en nacht om een VMXNet3 NIC in te stellen. Ik ben er tot op de dag van vandaag nog niet achter waar dat verschil in zit en waarom-de-<bleep> het WCF uberhaupt zou roesten welke (virtuele notabene) NIC gebruikt wordt/werd maar het is aantoonbaar en reproduceerbaar op meerdere ESXi bakken opgelost door VMX3Net te gebruiken en weer traag als we de oude (ik meen e1000, pin me d'r niet op vast) NIC gebruiken waarbij dat het enige verschil is zonder andere wijzigingen whatsoever. En dat verschil was tussen .3 tot .8 seconden voor het afhandelen voor een request tot .03 seconden en lager(!) voor 't afhandelen van een request.

[ Voor 3% gewijzigd door RobIII op 18-11-2015 10:51 ]

[gekkie]

MIsschien omdat een e1000 geemuleerd moet worden (zodat de generieke driver voor fysieke e1000's kan worden gebruikt in je guest) ?

VMX3Net is hun eigen driver .. geen emulatie nodig .. en wellicht nog wat handigheidjes en shortcuts mogelijk (betere afstemming met het host gedeelte van de driver, zerocopy van packets etc.).

(hetzelfde geldt overigens ook voor local storage, en ook voor andere hypervisors Xen, KVM etc.)

[ Voor 16% gewijzigd door gekkie op 18-11-2015 10:58 ]

[RobIII]

gekkie schreef op woensdag 18 november 2015 @ 10:55:
MIsschien omdat een e1000 geemuleerd moet worden (zodat de generieke driver voor fysieke e1000's kan worden gebruikt in je guest) ?

Ik denk dat ik de e1000e bedoelde, maar again, pin me d'r niet op vast. Die is volgens dit document iig. de default voor Win8 en nieuwer VM's (wij draaien Win 2012 R2 VM's). En emulatie of niet: los van de algehele performance die voor de VMX NIC veel hoger lag wilde de andere (vermoedelijk e1000(e)) NIC met vlagen gewoon enkele seconden bokken / niet reageren.

[ Voor 26% gewijzigd door RobIII op 18-11-2015 11:11 ]

[dotacom]

raptorix schreef op woensdag 18 november 2015 @ 10:37:
Vinden er soms database queries plaats naar een andere server?
Ik moet zeggen dat het probleem herkenbaar is, toch is het echt doormeten vaak lastig omdat de resources op de server voldoende zijn, maar in de praktijk toch niet de performance opleveren die je zou verwachten.

Er vinden inderdaad database queries uit naar een andere server.
Maar dit gebeurd ook als ik de applicatie lokaal installeer, dan verwijs ik naar dezelfde database server dus dit zou niet mogen uitmaken.

[gekkie]

RobIII schreef op woensdag 18 november 2015 @ 11:06:
[...]
Ik denk dat ik de e1000e bedoelde, maar again, pin me d'r niet op vast. Die is volgens dit document iig. de default voor Win8 en nieuwer VM's (wij draaien Win 2012 R2 VM's). En emulatie of niet: los van de algehele performance die voor de VMX NIC veel hoger lag wilde de andere (vermoedelijk e1000(e)) NIC met vlagen gewoon enkele seconden bokken / niet reageren.

Laat ik het dan anders zeggen .. alles wat geen paravirtual drivers zijn voor dat virtualisatie platform, maar bestaande drivers voor bestaande fysieke hardware is geemuleerd en niet geoptimaliseerd.

Tsja kan zijn dat de emulatie een bug veroorzaakt of triggert die je bij fysieke hardware dan niet hebt.

Die drivers zou je eigenlijk alleen moeten gebruiken voor een guest OS waarvoor geen paravirtuele drivers beschikbaar zijn, of tijdens de installatie, of als performance je niet zo veel kan schelen.

TS:
Klinkt alsof het een GUI applicatie is ?
Is vooral je GUI traag ?
Wat draait er naast deze specifieke VM's nog aan andere VM's ?
(latency is niet ongebruikelijk .. je hypervisor moet toch schedulen, beetje afhankelijk van de scheduler hoeveel gevolgen dat heeft voor latency.)
En als het een GUI is, op welke wijze wordt deze dan bekeken ?
(remote desktop geeft ook weer wat extra latency over het algemeen)

[ Voor 15% gewijzigd door gekkie op 18-11-2015 11:25 ]

[dotacom]

gekkie schreef op woensdag 18 november 2015 @ 11:20:
[...]

Laat ik het dan anders zeggen .. alles wat geen paravirtual drivers zijn voor dat virtualisatie platform, maar bestaande drivers voor bestaande fysieke hardware is geemuleerd en niet geoptimaliseerd.

Tsja kan zijn dat de emulatie een bug veroorzaakt of triggert die je bij fysieke hardware dan niet hebt.

Die drivers zou je eigenlijk alleen moeten gebruiken voor een guest OS waarvoor geen paravirtuele drivers beschikbaar zijn, of tijdens de installatie, of als performance je niet zo veel kan schelen.

TS:
Klinkt alsof het een GUI applicatie is ?
Is vooral je GUI traag ?
Wat draait er naast deze specifieke VM's nog aan andere VM's ?
(latency is niet ongebruikelijk .. je hypervisor moet toch schedulen, beetje afhankelijk van de scheduler hoeveel gevolgen dat heeft voor latency.)
En als het een GUI is, op welke wijze wordt deze dan bekeken ?
(remote desktop geeft ook weer wat extra latency over het algemeen)

Gebruikte NIC's zijn reeds vmxnet3.
Het is inderdaad vooral de GUI die traag aanvoelt.
Bijvoorbeeld het wisselen tussen de verschillende tabs etc.

Een ander voorbeeld: bij het klikken op een bepaalde tab wordt achterliggend een query uitgevoerd naar een remote databaseserver. Lokaal duurt dit iets van een 8-tal seconden eer alles ingeladen is en de data correct wordt afgebeeld in dashboard. Als ik dat op de testserver doe ligt dit rond de 11 seconden.

[RobIII]

dotacom schreef op woensdag 18 november 2015 @ 11:35:
Een ander voorbeeld: bij het klikken op een bepaalde tab wordt achterliggend een query uitgevoerd naar een remote databaseserver. Lokaal duurt dit iets van een 8-tal seconden eer alles ingeladen is en de data correct wordt afgebeeld in dashboard. Als ik dat op de testserver doe ligt dit rond de 11 seconden.

Holy moly; die 8 seconden is al onwerkbaar IMHO, laat staan nog langer
Misschien is 't een idee om eens te gaan kijken naar preloading, caching en andere technieken om die 8 seconden ook (drastisch) naar beneden te gaan krijgen? Dan zullen die 11 seconden vanzelf mee naar beneden gaan (en acceptabel(er) worden). En als je die 8 seconden nodig hebt om een hele sloot data neer te zetten in dat formulier/tab is 't misschien een idee om dat eens (flink) uit te dunnen? Vaak zijn devvers van 't slag "dump alles op 't scherm dan kan de gebruiker er alles mee doen / zien" en zijn de gebruikers daar stiekem helemaal niet mee geholpen maar weten ze niet beter als dat ze 5 minuten moeten scrollen in een grid voordat ze gevonden hebben wat ze zoeken.

[ Voor 22% gewijzigd door RobIII op 18-11-2015 11:41 ]

[gekkie]

dotacom schreef op woensdag 18 november 2015 @ 11:35:
[...]


Gebruikte NIC's zijn reeds vmxnet3.
Het is inderdaad vooral de GUI die traag aanvoelt.
Bijvoorbeeld het wisselen tussen de verschillende tabs etc.

Een ander voorbeeld: bij het klikken op een bepaalde tab wordt achterliggend een query uitgevoerd naar een remote databaseserver. Lokaal duurt dit iets van een 8-tal seconden eer alles ingeladen is en de data correct wordt afgebeeld in dashboard. Als ik dat op de testserver doe ligt dit rond de 11 seconden.

Loggen dus als je dergelijke concrete gevallen hebt .. zou je vrij snel moeten kunnen bekijken of het de query, processing, displaying (in form? zal dan ook wel geen tiental regels zijn ?) is of dat het totaal buiten de app ligt. En 3 seconden op 8 .. ach kwestie van een extra bakkie koffie

[ Voor 9% gewijzigd door gekkie op 18-11-2015 11:41 ]

[roy-t]

De applicatie is dus +- 30% langzamer? Is dat niet wat je gewoon kan verwachten? Je vertelde dat je eigen dev machine redelijk stevig is, wel een SSD heeft, en deze is natuurlijk ook nog eens 100% van zijn tijd aan het besteden aan het werken met jouw applicatie. De gevirtualiseerde server heeft natuurlijk veel meer te doen, naast alleen al de virtualisatie bottleneck en het mogelijke verschil in andere hardware. Zijn er toevallig ook nog eens meerdere gebruikers tegelijkertijd bezig op deze test server?

Dat de server niet aan zijn resource limieten komt, maar toch langzamer is, is niet gek. Als de computer 30 seconden wacht op IO (processor gebruik is 0%) en dan 30 seconden lang met deze data werkt (IO gebruik is 0%) dan zijn beide resources maar voor 50% belast.

Kortom, is de applicatie zelf niet gewoon te langzaam? Het lijkt er op (zolang je niets meet) dat de server het zo goed doet als je zou kunnen verwachten.

[ Voor 32% gewijzigd door roy-t op 18-11-2015 12:29 ]

[Hydra]

dotacom schreef op woensdag 18 november 2015 @ 11:35:
Een ander voorbeeld: bij het klikken op een bepaalde tab wordt achterliggend een query uitgevoerd naar een remote databaseserver. Lokaal duurt dit iets van een 8-tal seconden eer alles ingeladen is en de data correct wordt afgebeeld in dashboard. Als ik dat op de testserver doe ligt dit rond de 11 seconden.

Is dat dan dezelfde remote database?

[dotacom]

RobIII schreef op woensdag 18 november 2015 @ 11:38:
[...]

Holy moly; die 8 seconden is al onwerkbaar IMHO, laat staan nog langer
Misschien is 't een idee om eens te gaan kijken naar preloading, caching en andere technieken om die 8 seconden ook (drastisch) naar beneden te gaan krijgen? Dan zullen die 11 seconden vanzelf mee naar beneden gaan (en acceptabel(er) worden). En als je die 8 seconden nodig hebt om een hele sloot data neer te zetten in dat formulier/tab is 't misschien een idee om dat eens (flink) uit te dunnen? Vaak zijn devvers van 't slag "dump alles op 't scherm dan kan de gebruiker er alles mee doen / zien" en zijn de gebruikers daar stiekem helemaal niet mee geholpen maar weten ze niet beter als dat ze 5 minuten moeten scrollen in een grid voordat ze gevonden hebben wat ze zoeken.

Dit is nu wel het extreemste voorbeeld dat ik aanhaal. Het schrijven & de werking van de applicatie trek ik mij niet aan, dit is voor de developers. Ik moet wel kunnen verantwoorden waarom dezelfde applicatie trager aanvoelt op de testserver dan als deze lokaal wordt geïnstalleerd. En ja, de verwijzing is steeds naar dezelfde databaseserver.

Ik heb eens een HDD benchmark laten lopen zowel lokaal als op de testserver. Linkse foto is vanop server, rechtse is mijn lokale PC:

[ Voor 6% gewijzigd door dotacom op 18-11-2015 14:32 ]

[Damic]

Foto doet het niet

[Cloud]

dotacom schreef op woensdag 18 november 2015 @ 13:32:
[...]
Ik moet wel kunnen verantwoorden waarom dezelfde applicatie trager aanvoelt op de testserver dan als deze lokaal wordt geïnstalleerd.
[...]

Apart. Ik snap dat je als beheerder daarbij betrokken wordt maar het lijken me toch eerst de devvers die moeten onderzoeken waarom een applicatie langzamer is op locatie B dan op locatie A. Het is al moeilijk genoeg. Maar voor ontwikkelaars wel een stuk makkelijker dan voor systeembeheerders.

[johnkeates]

Mist er niet een DevOps schakel tussen jullie afdelingen? Of neem je dat op je (of staat dat in je contract)?

[dotacom]

johnkeates schreef op woensdag 18 november 2015 @ 14:37:
Mist er niet een DevOps schakel tussen jullie afdelingen? Of neem je dat op je (of staat dat in je contract)?

Inderdaad, onze enige DevOps die hier rondliep is 3 maand geleden vertrokken waardoor dit nu eigenlijk "onterecht" tot bij mij gekomen is. Staat zeker niet in mijn contract. Niettegenstaande wil ik deze opdracht zo goed en grondig mogelijk bekijken.

[sig69]

Het blijft altijd een beetje gissen, zo op afstand. Je verdenkt zelf de storage, dat kan, als de applicatie veel lees- en/of schrijfwerk doet. Maar je hebt natuurlijk met heel veel variabelen te maken: storage, cpu, geheugen, netwerk, OS. En dan draait het ook nog gevirtualiseerd, dus dan komen er nog wat meer bij. Dit is gewoon geen taak voor een systeembeheerder, laat een ontwikkelaar er een profiler aanhangen of zoals reeds genoemd performance counters of logging inbouwen. Dan heb je gegevens die je kan vergelijken tussen omgeving A en omgeving B ipv maar wat te gokken.

[The Eagle]

Als je de storage uit wilt sluiten: kopieer die testVM eens naar je lokale machine en start hem daar. Uiteraard wel de storage ook even kopieren anders heb je nog niks
Als je daar ook geen performnce hebt is het iig niet je storage