Ervaringen met performance van een webserver

[107mb]

Een programmeur heeft voor ons een webapp ontwikkeld. De server waar deze app op draait is een:

• Dell PowerEdge T440
• Xeon Silver 4110 processor
• 96 GB 2667 DDR4 geheugen
• SSD voor het OS en 15K schijven in RAID 10

De webapp is geheugenhongerig en performt ondermaats, en nu meent men het geheugen uit te moeten breiden naar 128 GB.

Ik heb echter geen kijk op de power van een server, maar mijn gevoel zegt dat we best een zware jongen van een server hebben, en dat er gekeken moet worden naar optimalisatie van de code. Hier is m.i. echte winst te behalen.

Kan iemand aangeven waarvoor een server met deze spec's ingezet kan worden, om zo alles in perspectief te kunnen laatsen.

[ Voor 7% gewijzigd door 107mb op 11-07-2018 11:40 . Reden: typo's ]

[oef!]

Geheugenlek? Dit is een beest van een ding.

[sanderdw]

Werkt deze programmeur toevallig bij het bedrijf die ook deze geheugenuitbreiding moet doen?...

Maar even serieus, dit kan 'bijna' nooit, wat doet deze webapp?

[mcDavid]

sja dat is nogal afhankelijk van watvoor app het betreft en hoe zwaar die gebruikt wordt. Als je een flinke database doorzoekbaar moet maken en het moet performen voor tienduizenden bezoekers per dag, verbaast het me dat je met één (web)server af komt. Als het een portal is wat door 3 medewerkers gebruikt wordt en hooguit wat simpele queries doet gaat er duidelijk wat fout.

[com2,1ghz]

We kunnen vrij weinig met deze info. Dit is echt afhankelijk van de applicatie en de load hierop. Zo kan je oneindiig veel memory bij prikken bij een memory leak terwijl er maar 2 users op zitten.

Wat versta je onder geheugen hongerig? Een memory leak valt nooit recht te praten. Het kan ook een programmeerfout geweest zijn waarbij onnodig objecten in het geheugen vast gehouden worden.

De vraag die je nu ons stelt is:
We hebben een volkswagen transporter busje met 200 PK alleen trekt hij onze lading niet. Komen wij soms PK's tekort?

[downtime]

107mb schreef op woensdag 11 juli 2018 @ 11:38:
Een programmeur heeft voor ons een webapp ontwikkeld. De server waar deze app op draait is een:

• Dell PowerEdge T440
• Xeon Silver 4110 processor
• 96 GB 2667 DDR4 geheugen
• SSD voor het OS en 15K schijven in RAID 10

De webapp is geheugenhongerig en performt ondermaats, en nu meent men het geheugen uit te moeten breiden naar 128 GB.

Ik heb echter geen kijk op de power van een server, maar mijn gevoel zegt dat we best een zware jongen van een server hebben, en dat er gekeken moet worden naar optimalisatie van de code. Hier is m.i. echte winst te behalen.

Kan iemand aangeven waarvoor een server met deze spec's ingezet kan worden, om zo alles in perspectief te kunnen laatsen.

Zoals mijn voorgangers al aangaven geef je veel te weinig informatie om echt iets zinnigs te kunnen zeggen maar met 128GB is het met afstand de zwaarste webserver die ik ooit heb gezien. Werken er 1000 man op, dan is het uit te leggen, maar als het er een handvol zijn dan is het extreem.

Ik snap ook niet waarom dit op 1 server draait. Dergelijk zware applicaties zou ik willen verdelen over meer (en lichtere) servers zodat uitval van een server niet een probleem is.

[107mb]

het is een interne webapp, die met NAV communiceert. Ik denk niet dat er een geheugenlek is. er is veel communicatie (via directe SQL commando's, dus niet via een NAV NST) met de database. Hooguit tien gebruikers.

De analogie die com2,1ghz plaatst is correct. Dat is ook de houding van ons MT. In die context heb ik dan geen verstand van auto's, maar heb het gevoel dat als wij één pakketje met die transporter moeten bezorgen, en dat wij dan met de complete magazijn-voorraad in die bus rondrijden :-)

[CodeCaster]

Hier kan niemand iets over zeggen zonder de code te zien. Ja, het is een stevige server, en ja, hier zou makkelijk een webapplicatie op kunnen die duizenden gebruikers gebruiken. Tenzij de applicatie slecht is geprogrammeerd, de applicatie veel werk moet verzetten of veel op andere systemen moet wachten, of de server(configuratie) brak is. Wie weet hinkt de CPU op een fractie van z'n vermogen door temperatuurproblemen.

Koffiedikkijken is niet productief. Laat de developer z'n applicatie profilen om erachter te komen welk stuk code precies zoveel CPU-tijd en geheugen vreet. Wij kunnen dit niet.

In ieder geval kunnen we met zekerheid zeggen dat 9 GB geheugengebruik per gebruiker absurd is.

[ Voor 7% gewijzigd door CodeCaster op 11-07-2018 12:25 ]

[mcDavid]

Sja, nog steeds zul je echt meer inzage moeten geven in wat er gebeurt. Waarschijnlijk kan of mag dat uberhaupt niet op een publiek forum, dat begrijp ik. Maar dat betekent wel dat wij er verder weinig over kunnen zeggen. Misschien is het een goed idee een externe ontwikkelaar of systeembeheerder in te schakelen voor een second opinion.

@downtime het klinkt mij ook bizar in de oren, maar gezien de HDD's lijkt me dat deze server gigantische hoeveelheden data verwerkt. Dan is een flinke sloot RAM voor memcache of soortgelijke oplossingen ook geen gek idee. Normaalgesproken zou je dat idd delegeren naar een database-server maar dat hoeft niet perse.

[Haan]

Het blijft natuurlijk een beetje gissen zonder de exacte specs van de applicatie, maar mijn gevoel zegt dat je een web app met max 10 gebruikers bij wijze van spreken op je eigen laptop moet kunnen draaien en dan nog steeds prima performen.

[ipsec]

Installeer desnoods eens Newrelic op je applicatie, met de trial versie kan je er dan redelijk snel achter komen waar de bottleneck van je applicatie precies ligt.

[downtime]

mcDavid schreef op woensdag 11 juli 2018 @ 12:25:


@downtime het klinkt mij ook bizar in de oren, maar gezien de HDD's lijkt me dat deze server gigantische hoeveelheden data verwerkt.

Ik hoop niet dat je “15K schijven in RAID 10” interpreteert als 15.000 schijven. Het zijn harddisks die op 15.000 toeren draaien. Niks bijzonders in serverland. Hooguit kun je zeggen dat er sprake zal zijn van minimaal 4 disks en dat zal toch zeker een TB aan ruimte opleveren. Ik weet niet wat de minimale grootte van een 15K disk tegenwoordig is. Aan de andere kant: Het maakt ook niet uit. Voor hetzelfde geld is die ruimte voor 95% leeg en staat er een database van een lullige 10GB op.

[Gomez12]

Het is een beest van een server, alleen bedenk je wel goed dat hardware bijna altijd goedkoper is dan optimalisaties...

Alleen ergens bereik je qua hardware een punt dat het weer veel zinniger is om te gaan optimaliseren zodat je op dezelfde hardware verder kan met meer gebruikers...

Als iemand 40 uur gaat optimaliseren a 100 euro per uur, dan kan je daarvoor ook 256 GB geheugen erbij zetten (als het je eigen server is).

Als de programmeur gewoon regelmatig refactored en geen duidelijke verbeterpunten ziet momenteel, dan kan je met een vastgesteld aantal uren hem een laten profilen / newrelic installeren.
Alleen je kan tot in de eeuwigheid bezig blijven met optimalisaties en daarop compleet leeg lopen.

Oftewel als je gaat optimaliseren zeg goed wat je einddoel is, want waarschijnlijk kan je webserver ook wel met 8GB vooruit, alleen vereist dit een paar duizend uur optimaliseren...

Programmeren is heden ten dage een afweging tussen gemak en optimalisatie, oftewel bijna in elke methode is er wel iets te optimaliseren, alleen veelal is het totaal irrelevant

[sig69]

Tsja het is onmogelijk te zeggen of extra geheugen dit op gaat lossen. Iemand zal simpelweg moeten gaan meten waar de bottleneck zit.
Nog even ter vergelijking (die nergens op slaat): wij draaien voor 3 vestigingen 6 redelijk zware webapplicaties voor een stuk of 400 gebruikers tegelijk en tientallen webservices voor integratie met klanten op een webserver met 8GB geheugen, en dat gaat prima.

[mcDavid]

downtime schreef op woensdag 11 juli 2018 @ 13:15:
[...]

Ik hoop niet dat je “15K schijven in RAID 10” interpreteert als 15.000 schijven. Het zijn harddisks die op 15.000 toeren draaien. Niks bijzonders in serverland. Hooguit kun je zeggen dat er sprake zal zijn van minimaal 4 disks en dat zal toch zeker een TB aan ruimte opleveren. Ik weet niet wat de minimale grootte van een 15K disk tegenwoordig is. Aan de andere kant: Het maakt ook niet uit. Voor hetzelfde geld is die ruimte voor 95% leeg en staat er een database van een lullige 10GB op.

I know. Maar je gaat uberhaupt geen HDD's in een (web)server hangen als je niet meerdere TB's op te slaan hebt. Maargoed we weten idd niet of het een bewuste keuze geweest is of dat er gewoon maar wat in gesmeten is.

[downtime]

Gomez12 schreef op woensdag 11 juli 2018 @ 13:18:
Het is een beest van een server, alleen bedenk je wel goed dat hardware bijna altijd goedkoper is dan optimalisaties...

Alleen ergens bereik je qua hardware een punt dat het weer veel zinniger is om te gaan optimaliseren zodat je op dezelfde hardware verder kan met meer gebruikers...

Als iemand 40 uur gaat optimaliseren a 100 euro per uur, dan kan je daarvoor ook 256 GB geheugen erbij zetten (als het je eigen server is).

Want symptoombestrijding is veel beter dan problemen oplossen. Ik heb vaker gesproken met developers die met zulke argumenten komen. En wat gebeurt er? Management knikt, er wordt extra geheugen besteld, en dan blijkt die applicatie gewoon het extra geheugen ook te gebruiken maar het duurt 24 uur langer en de performance verbetert nauwelijks.
Dan heb je geld aan extra geheugen en een boel uren discussie uitgegeven (want beheerders, management en gebruikers werken ook niet gratis) maar je bent geen stap dichter bij een oplossing. Dus altijd starten met een analyse en niet domweg extra geheugen bestellen.

[desmond]

107mb schreef op woensdag 11 juli 2018 @ 12:16:
het is een interne webapp, die met NAV communiceert. Ik denk niet dat er een geheugenlek is. er is veel communicatie (via directe SQL commando's, dus niet via een NAV NST) met de database. Hooguit tien gebruikers.

Het zou mij niet verbazen als de crux hem zit in de database-acties naar de NAV-server.

Ofwel dat Navision traag reageert, ofwel dat de opbouw van connecties veel overhead creëert op de web server, ofwel dat de verwerking van de via SQL opgehaalde data totaal inefficiënt gebeurt (bijvoorbeeld omdat er meer gegevens worden opgehaald dan strikt noodzakelijk).

Ik zou er een onafhankelijke expert bij halen die de gehele stack analyseert; hoeft maar een of twee dagen te kosten om de bottleneck te bepalen.

[downtime]

desmond schreef op woensdag 11 juli 2018 @ 13:48:
[...]

Ik zou er een onafhankelijke expert bij halen die de gehele stack analyseert; hoeft maar een of twee dagen te kosten om de bottleneck te bepalen.

Dat is, wanneer haalbaar, het beste. Eerst een analyse en bij voorkeur niet eentje door de oorspronkelijke developer. Slagers moeten hun eigen vlees niet keuren.

[CodeCaster]

downtime schreef op woensdag 11 juli 2018 @ 13:58:
[...]

Dat is, wanneer haalbaar, het beste. Eerst een analyse en bij voorkeur niet eentje door de oorspronkelijke developer. Slagers moeten hun eigen vlees niet keuren.

Een goede developer kan prima z'n eigen code profilen. Sterker nog, dat zou onderdeel van het ontwikkelproces moeten zijn.

[sig69]

desmond schreef op woensdag 11 juli 2018 @ 13:48:
[...]


Het zou mij niet verbazen als de crux hem zit in de database-acties naar de NAV-server.

Ofwel dat Navision traag reageert, ofwel dat de opbouw van connecties veel overhead creëert op de web server, ofwel dat de verwerking van de via SQL opgehaalde data totaal inefficiënt gebeurt (bijvoorbeeld omdat er meer gegevens worden opgehaald dan strikt noodzakelijk).

Blijft allemaal gokwerk natuurlijk. Het kan, maar hoeft absoluut niet. Zolang we niet meer weten dan

De webapp is geheugenhongerig en performt ondermaats,

valt er helemaal niets over te zeggen.

[Gomez12]

downtime schreef op woensdag 11 juli 2018 @ 13:44:
[...]
Want symptoombestrijding is veel beter dan problemen oplossen.

Hoe kom je erbij dat het symptoombestrijding is?

Dus altijd starten met een analyse en niet domweg extra geheugen bestellen.

Hoe kom je erbij dat er geen analyse gedaan is?

Een beetje programmeur doet dat juist continue door te refactoren en newrelic etc erbij te betrekken.

Als je het dan echt officieel wilt doen, dan mag 107mb eerst eens even de vraag bij management gaan stellen hoeveel tijd/geld er in dit project gestoken mag worden.

Dan de originele specs erbij pakken en kijken of de app ondermaats performt volgens de laatste geprogrammeerde specs. Want als het wel volgens spec is dan wordt het weer een ander verhaal.

Daarnaast kan je een simpele analyse laten doen om het grootste pijnpunt naar boven te halen, maar als het goed is is dat pijnpunt gewoon al duidelijk. En gaat het enkel maar om de oplossing en dat is een totaal andere orde van grootte.
Ik ken genoeg projecten waarin giga-pijnpunten zitten en iedereen weet die te zitten, het is alleen bedrijfstechnisch niet verantwoordelijk om ze eruit te halen.

[ElCondor]

Het zou ook zo maar kunnen zijn dat NAV en de WebApp elkaar in de weg zitten en rources op de database van elkaar locken of bezet houden en dat er daardoor traagheid optreed. Moeilijk te zeggen inderdaad.
Maar een WebApp die 96GB aan gehheugen voltrekt, daar is iets mis mee...
Haalt hij hele grote datasets op uit de database voor interne bewerking of zo? Je zou resource intensieve tasks nooit door een webap uit moeten laten voeren. Eerder door een API waar de WebApp op inprikt.
Of via NAV natuurlijk. Dat is er voor bedoeld.

[downtime]

CodeCaster schreef op woensdag 11 juli 2018 @ 14:11:
[...]

Een goede developer kan prima z'n eigen code profilen. Sterker nog, dat zou onderdeel van het ontwikkelproces moeten zijn.

Een goede developer wel. Maar er zijn nogal wat minder goede developers op de markt. En wat is zijn belang om jou te vertellen dat het aan zijn code ligt? Immers, als het aan zijn code ligt dan heeft hij al gefaald, want deze code draait al in productie.

Gomez12 schreef op woensdag 11 juli 2018 @ 14:31:
[...]

Hoe kom je erbij dat het symptoombestrijding is?

Zonder analyse van de oorzaak is elke cent die je uitgeeft onverantwoord. Ik heb het te vaak gezien. Eerst geld uitgeven aan meer CPU's en extra RAM, soms zelfs een switch van VM's naar fysieke machines omdat de developer de schuld aan de gevirtualiseerde hardware geeft, en daarna ontdekken dat je duizenden euro's in hardware en uren hebt gestoken en er niks wezenlijks verbeterd is voor de eindgebruiker.

Hoe kom je erbij dat er geen analyse gedaan is?

Een beetje programmeur doet dat juist continue door te refactoren en newrelic etc erbij te betrekken.

Een beetje programmeur wel. Maar ken jij de mensen die dit gemaakt hebben?

Als je het dan echt officieel wilt doen, dan mag 107mb eerst eens even de vraag bij management gaan stellen hoeveel tijd/geld er in dit project gestoken mag worden.

Juist bij een beperkt budget is een behoorlijke analyse van het probleem belangrijk. Op z'n allerminst een goed gesprek met de developer om hem uit te laten leggen waarom 10GB per gebruiker normaal is.