Concurrent users en server specificaties

[maniak]

Aan mij is gevraagd om een website, welke in de laatste fase van de development zit, te "load testen". Nu lijkt het erop dat bij 10 concurrent users de pagina's een response tijd krijgen bover de 1 seconden wat niet acceptabel is voor het bedrijf.

De website wordt gerealiseerd in Sitecore versie 6.4. Als ontwikkelaar heb ik de code al eens gereviewed. Er wordt heel netjes gecodeerd en de html die eruit komt is ook minimaal, de ontwikkelaars van de website leveren goed werk.

In mijn test had de server 2 cores en 2GB memory en haalde net niet 10 concurrent users. Ik verwacht dat er een discussie gaat ontstaan tussen de afdeling die over de server resources gaan en het project. Waarbij het project meer server resource wil hebben en de afdeling zal hameren op verbetering van de software.

Nu mijn vraag aan mijn mede tweakers, kan iemand wat zinnigs melden over specificaties van frontends en de bijbehorende concurrent users? Volgens de specificaties moet het systeem 100 concurrent users aan kunnen waarbij de pagina's een laadtijd hebben van gem. 0.5 seconden.. hierbij is niet de tijd gerekend dat het de client kost om te renderen.

[Pogostokje]

Wat je bij zo'n project soms kunt doen om een en ander pragmatisch op te pakken, in plaats van dagen of weken theoretisch er over blijven praten, is de server tijdelijk upgraden naar fors hogere specificaties. Dan weet je of het realistisch is om een grotere server neer te zetten of dat de oplossing echt een applicatie oplossing moet worden.

De applicatieontwikkelaars moeten daarnaast gaan bekijken waar de vertraging zit, in welk deel van hun code. Dat moet mogelijk geoptimaliseerd worden.
De webserver beheerder kan kijken naar zaken als caching en het algehele gebruik van memory en cpu.

2GB geheugen voor 100 users op een applicatie site klinkt mij als wat weinig in de oren, maar ... meten is weten.

[ Voor 8% gewijzigd door Pogostokje op 18-09-2011 10:02 ]

[maniak]

Belangrijk om te weten is "wat is normaal?", referentiekaders waaraan de nieuwe website getoetst kan worden vandaar ook mijn vraag hier.

[Freezerator]

Heb je al geanalyseerd wat de vertraging veroorzaakt? Want de html code kan misschien minimaal zijn, maar de meeste tijd kan bijvoorbeeld zitten in de query's.

Zelf blijft mijn website bij honderden concurrent users on de 1 seconde page load, en dat is een eenvoudig php en mysql gebaseerd forum.

[Motrax]

Is de server alleen maar om een pagina te serveren, of is dit inclusief de volledige applicatie? En wat draait er nog meer op de bak, zijn er voldoende resources beschikbaar?

Want als een bak met 2GB en 10 users het al niet trekt: dat is _bizar_ traag.

Vermoedelijk zit het probleem niet in de hardware specificaties, maar als de applicatie lineair schaalt heb je dus minimaal 20GB + 20 cores nodig voor 100 users

[Pogostokje]

Er is niet echt een 'normaal', dat hangt van de applicatie af. De hardware en de software moet op elkaar zijn afgestemd, dat is nu niet het geval want je vindt het zelf te traag.
je hebt onderzoeken naar maximale laadtijd van sites die bezoekers nog accepteren, even googlen en je vindt ze wel. Paar seconden is wel het max, maar voor een interne site zal dat lager zijn ivm de verwachtingen.

[ Voor 37% gewijzigd door Pogostokje op 18-09-2011 10:42 ]

[maniak]

De website wordt geheel gemaakt in asp.net en c#. Sitecore is dan niets meer dan een aantal dll's waar je tegenaan programmeerd om je data op te halen, je maakt dus niet zelf rechtstreeks een koppeling met de database.

Als ik de pagina's bekijk zijn het vooral de pagina's met lijsten en het zoeken welke een zwaardere belasting opleveren. En dan moet je denken aan een lijst met nieuws items, max 10 items. Aan de achterkant wordt er in de aspx linq gebruikt om de data te fetchen.

Maar goed, wat ik graag wil weten welke server specificaties normaal is bij welke belasting. Als we 2 frontends willen inzitten bij 100 concurrent users, aan welke specificaties moeten we denken? De website is niets meer dan een corporate website met Sitecore als cms met her en der wat lijstjes met producten en nieuws.

[Pogostokje]

Nogmaals, dat kun je dus niet zeggen. Als het probleem in jullie database zit, kun je de frontend wel upgraden maar wordt het er niet sneller door. Er is geen gemiddelde te noemen bij een cms met een backend integratie.
Laat je applicatie developers checken waar de vertraging zit, en datzelfde aan de server kant. Dan weet je wat er mis is, dan weet je wat je moet upgraden en wat je kunt verwachten.

[Gomez12]

Waarom zou het vingerwijzen om de hoek komen?

Als er in de specs staat 100 users minder dan 0.5 sec dan verwacht ik dat er ook in de specs staat wat voor hardware er nodig is. Dan lijkt het mij dus heel eenvoudig om te checken wie er fout zat (is de hardware lager dan specs of is de software trager dan specs)

Het is een samenspel tussen software en hardware die de uiteindelijke load bepaalt. Daar is geen hard cijfer voor te geven (alhoewel, ik op een 486 wel eens 100 concurrent users heb geserveerd)

Gaat je sitecore / dbase in de knoei komen met locking querys dan kan je er wel 300 frontend servers tegenaan gooien, sneller dan je dbase het kan serveren gaat het niet worden.

[Paul]

Bij ons op het werk programmeren we ook tegen Sitecore, webserver is bijna 3 jaar oud en de databaseserver ook. Daarop draaien (shared hosting) een stuk of 100 websites, al zijn die lang niet allemaal Sitecore, maar wel met meer dan 10 concurrent users. Een klant heeft een dedicated server met (imho) best brakke specs en die draait zowel sitecore als de databaseserver op die machine, en dat gaat ook meer dan uitstekend.

Aan je hardware kan het gewoon bijna niet liggen tenzij daar hele erge bottlenecks zitten. De keren dat ik erbij werd gevraagd (systeembeheerder/DBA) omdat de programmeurs er niet uit kwamen was het steeds een select over iets zonder index. Kijk eens wat je SQL-server roept in de 'recently slow queries' Wat de programmeurs aan optimalisaties hebben uitgevoerd weet ik uiteraard niet

[maniak]

Ik vergat te vermelden dat de SQL server op 1% cpu belasting blijft, ongeacht de load die ik er tegenaan gooi. Sitecore heeft zijn caching goed op orde. Het is echt de CPU belasting op de frontend die nu de limit is.

[Paul]

SQL Server kan op 1% CPU heel goed 99% van de tijd aan het wachten zijn op I/O

Maar, de CPU van de frontend staat dus wel op 100%? Dan zou ik inderdaad daar beginnen en kijken wat het is dat zo lang duurt

[Motrax]

Worden er dan nog veel client Side berekeningen uitgevoerd? En een lock op de DB kan er ook voor zorgen dat de belasting blijft...

Het rijmt totaal niet met dat je meldt dat de html output heel simpel is en dat je front end aan het flatlinen is.

[Gomez12]

Wat is nu eigenlijk de vraag? Waarom ga je hier nog zelf naar kijken en leg je het niet gewoon bij de verantwoordelijke neer?

Kloppen alle specs dan mag de spec-schrijver uitzoeken wie er verantwoordelijk is.
Kloppen de specs niet dan is het simpelweg alles naar specs brengen en dan verder kijken.

Daarom zet je toch juist specs op? Nu negeer je de specs en ga je enkel op basis van gokwerk wat proberen...

[Paul]

Nee, hij is aan het zoeken hoe hij de specs kan halen...

Als er in het design staat: 'Het systeem moet 100 concurrent users aankunnen mer 0.5 sec laadtijd' en bij 10 users heb je een laadtijd van 1 sec dan is het geen oplossing om de spec aan te passen, dan zoek je een manier om wel die aantallen users te bedienen.

Als jouw auto nog maar maximaal 30 km/uur rijdt ga je toch ook naar de garage in plaats van dat je de 180 in het boekje doorkrast en er 30 neerzet?

[Gomez12]

Paul schreef op zondag 18 september 2011 @ 12:54:
Nee, hij is aan het zoeken hoe hij de specs kan halen...

Als er in het design staat: 'Het systeem moet 100 concurrent users aankunnen mer 0.5 sec laadtijd' en bij 10 users heb je een laadtijd van 1 sec dan is het geen oplossing om de spec aan te passen, dan zoek je een manier om wel die aantallen users te bedienen.

Ik hoop toch dat er ook in de specs ietwat meer staat zoals bijv hardware eisen... 100 concurrent users met 0,5 sec laadtijd op een c64 is ietwat onrealistisch...

En ik bedoel niet dat je de spec aan moet passen, enkel is dit zo'n groot verschil (100 users met 0,5 sec vs nu <10 users met 0,5 sec) dat is gewoon simpelweg een major f*ckup.
Dat moet je niet als welwillende 3e even willen uitzoeken, dat moet simpelweg degene die de fout gemaakt heeft oplossen.

En mits er aan de hw-specs voldaan is, dan mag spec-schrijver uit gaan zoeken of hij het fout gedaan heeft of de software partij.

[Paul]

Waarom zou er in de specs iets staan over hardware eisen? Die zijn alleen maar lastig... Zo draaien wij een aantal machines waar in de offertes staat 'dual processor en 4gb ram'. Ding staat compleet uit zijn neus te eten, maar we kunnen/mogen het ding niet virtualiseren want dan voldoen we niet meer aan de hardware eisen (terwijl de software net zo snel zou blijven werken).

Het boeit de opdrachtgever / klant meestal ook totaal niet; die wil dat 100man zijn site tegelijk goed kan benaderen en wil daar X bedrag voor betalen, hoe de leverancier dat dan oplost is niet zijn probleem

Mij lijkt overigens dat bottlenecks identificeren juist onder 'load testen' valt? Je kunt het wel weer over de schutting gooien met een post-itje erop 'het is traag' maar dat is geen manier van doen natuurlijk...

[Gomez12]

Paul schreef op zondag 18 september 2011 @ 13:49:
Waarom zou er in de specs iets staan over hardware eisen? Die zijn alleen maar lastig...

Als ik het goed begrijp is er niet 1 partij de hw en sw levert (het vingerwijzen). Als er niet 1 team is en je hebt in je specs niet alle 2 de kanten belicht dan ga je dit soort dingen krijgen.

100 users in 0,5 sec zegt niets zonder verdere uitwerking qua hw eronder. Als de sw-leverancier nu het hele zaakje oppakt en op een "super"-computer gooit en daar blijkt het pakket 101 users aan te kunnen wat zegt het dan als de hw van de klant geen super-computer is?

Zo draaien wij een aantal machines waar in de offertes staat 'dual processor en 4gb ram'. Ding staat compleet uit zijn neus te eten, maar we kunnen/mogen het ding niet virtualiseren want dan voldoen we niet meer aan de hardware eisen (terwijl de software net zo snel zou blijven werken).

Tja, dat heb je nu eenmaal als performance eisen wilt.
Laat de performance eis bij je lev vallen en hij ondersteunt het pakket in basis weer perfect. Enkel geeft hij geen garantie meer over hoelang het duurt om 1 record op te halen...

Mij lijkt overigens dat bottlenecks identificeren juist onder 'load testen' valt? Je kunt het wel weer over de schutting gooien met een post-itje erop 'het is traag' maar dat is geen manier van doen natuurlijk...

Bottle necks identificeren vereist vrij veel kennis van de onderliggende systemen. Het is mij niet helemaal duidelijk of TS dat ook heeft.

Load testen is veel simpeler : Verzin een manier om de load te reproduceren en geef aan of het voldoet aan de wens/eis.

Voor hetzelfde geld is bottleneck een proces op de dbase-server wat continu giga-I/O vraagt waardoor SQL-server simpelweg geen I/O meer kan doen (en dus totaal instort met 1% cpu belasting) veel plezier met uitzoeken waar die bottleneck zit als je enkel maar vanuit de gemaakte app kijkt...

[gorgi_19]

maniak schreef op zondag 18 september 2011 @ 09:54:
De website wordt gerealiseerd in Sitecore versie 6.4. Als ontwikkelaar heb ik de code al eens gereviewed. Er wordt heel netjes gecodeerd en de html die eruit komt is ook minimaal, de ontwikkelaars van de website leveren goed werk.

Dat de code netjes gedocumenteerd wordt en de HTML netjes is, wil niet zeggen dat de code ook goed is en er rekening is gehouden met performance. Zeker met ASP.Net kan je vrij agressief gaan cachen (zowel outputcache als iets 'abstracter' als httpruntime.cache).
Is er met een profiler ook bepaald welk gedeelte van de code de vertragende factor is?

LINQ is trouwens een venijnige; het kan makkelijk gebeuren dat je 100.000 records uit de database ophaalt en hier vervolgens rij 11 tot 20 uit haalt in de code, of filtert.

[maniak]

Toch leuk om te zien dat er zoveel reacties zijn, dat had ik niet verwacht. Laat ik de vraag anders formuleren dan:

Stel de startpagina bestaat uit "statische content" en er staat een lijstje met bedrijfs nieuws op, stuk of 5 items. De "statische content" wordt opgehaald via een api uit het CMS. Deze content is 100% gecached in het geheugen op de frontend.

Ervan uitgaande dat er gewerkt wordt met de huidige cpu's, hoeveel cpu's (cores) en geheugen is er nodig om 100 concurrent users aan te kunnen waarbij elke request rond de 0.5 seconden afgehandeld wordt. De internetconnectie is geen bottleneck en de rendertijd aan de client wordt niet meegerekend.

[nielsl]

maniak schreef op zondag 18 september 2011 @ 16:58:
Toch leuk om te zien dat er zoveel reacties zijn, dat had ik niet verwacht. Laat ik de vraag anders formuleren dan:

Stel de startpagina bestaat uit "statische content" en er staat een lijstje met bedrijfs nieuws op, stuk of 5 items. De "statische content" wordt opgehaald via een api uit het CMS. Deze content is 100% gecached in het geheugen op de frontend.

Ervan uitgaande dat er gewerkt wordt met de huidige cpu's, hoeveel cpu's (cores) en geheugen is er nodig om 100 concurrent users aan te kunnen waarbij elke request rond de 0.5 seconden afgehandeld wordt. De internetconnectie is geen bottleneck en de rendertijd aan de client wordt niet meegerekend.

Wordt de content uit het CMS gehaald bij elke page request? Of is de content nu echt gecached? Dat scheelt waarschijnlijk nogal wat in hetgeen er moet worden uitgevoerd op de server side. Zoals iedereen hierboven aangeeft is dat meten gelijk staat aan weten, gewoon testen dus.

[barber]

Ik mis in je verhaal eigenlijk hoeveel requests een user per seconde (of minuut) maakt. Of algemener geformuleerd het typische gebruik van de verschillende gebruikersrollen van de site en de verhoudingen tussen dit soort gebruikersrollen.

Dat kan een simpel model zijn als:
lichte gebruiker: 1 request per minuut, 100% leesacties, 30%
standaard gebruiker: 3 requests per minuut, 100% leesacties, 50%
Zware gebruiker: 6 requests per minuut, 100% leesacties, 20%

Of nog simpeler:
Gebruiker: 6 requests per minuut, 100% leesacties

Bij 10 gebruikers tegelijk kom je dan uit op het halen van 1 request per seconde (6requests*10 users/60 seconden) die je webserver moet afhandelen en per request mag het er 0.5 seconde over doen.

10 users zo snel mogelijk requests afsturen is eigenlijk geen realistische test. Hoewel ik niet weet of je dit nu ook zo doet. Je moet het te verwachte gebruikspatroon nabootsen.

Bovenstaand model is dan het scenario wat je in je loadtest moet nadoen dan om te bepalen of je voldoet aan de requirements. Behalve bepalen of je de requirements haalt, zou je ook kunnen bepalen wat de performance nu daardwerkelijk is door de 10 users oplopende hoeveelheden requests per seconden te laten doen tot je de grens van 0.5 per pagina overschrijdt. Dit is dan ook leuk te vergelijken door het aantal requests per seconden per user gelijk te houden, maar dan het aantal gelijktijdige users te verhogen totdat je de 0.5 seconde per pagina limiet voorbij gaat.

P.S.
Die 6 requests per seconde gebruik ik zelf wel vaak voor een zware gebruiker al. Dit is meestal niet realistisch dat iemand dit 8 uur per dag doet. Hoewel er natuurlijk uitzonderingen zijn. ;-)

[maniak]

Ik voer de test uit met de test modules uit Visual Studio 2010. Ik heb 1 test controller en 2 test agents. Ik heb verschillende scenario's aangemaakt en gebruikt voor de loadtest. Hoeveel een bepaalde scenario gebruikt wordt tijdens het testen is gebasseerd op cijfers uit het verleden.

Als er bij 100 concurrent users een gem. laadtijd van 0.5 seconden mag zijn dan moet de server 200 pagina's per seconden kunnen uitspugen. Dat haal ik dus bij lange niet. Ik weet dat de CMS, Sitecore, alles gecached heeft omdat er zo goed als geen I/O is tussen de frontend en de database. Dit wordt tijdens het load testen gemeten door de test controller.

[barber]

maniak schreef op zondag 18 september 2011 @ 21:39:
Als er bij 100 concurrent users een gem. laadtijd van 0.5 seconden mag zijn dan moet de server 200 pagina's per seconden kunnen uitspugen.

Bovenstaande lijkt me niet vanzelfsprekend. Sterker nog, ik denk dat de aanname hier fout is of de definitie van concurrent users is anders dan gebruikelijk.

100 concurrent users zorgen namelijk nooit voor 200 requests per seconde. Dan zouden ze 2 keer per seconde op een knop moeten drukken. 100 concurrent users zorgen eerder voor 5 a 10 requests per seconden.

Ook kan een webserver anders schalen dan je verwacht. Als een enkele pagina 0.1 seconde duurt. Dat betekent niet dat 2 pagina's 0.2 seconden duren, of 10 pagina's 1 seconde. Je hebt te maken met multi threading en multi core cpu's die taken tegelijk kunnen uitvoeren. Ook kunnen er zaken worden toegepast om threads die wachten op IO weer achteraan de queue te gooien, zodat de threads die daadwerkelijk cpu nodig hebben gewoon verwerkt kunnen blijven worden. Op zo'n manier kan je meer requests per seconde verwerken, hoewel de individuele verwerktijd per pagina wel kan toenemen.

Ik zou dus bepalen hoewel requests per seconde 100 concurent users genereren. En dan gaan testen met dat aantal requests per seconde om te bepalen of de 0.5 seconde laadtijd haalbaar is.

[maniak]

100 concurrent users betekend dat als ik op een willekeurig moment een lijst met requests open er dus 100 requests geopend zijn. Dat hoeft dus niet 100 dezelfde gebruikers zijn.

Maar goed, het is duidelijk dat hier (bij ons dus) iedereen in het duister tast over dit onderwerp. Door een simpele rekensom leert dat de vorige website ongeveer 2 miljoen page request heeft gehad, dat is minder dan 1 concurrent user