Tjerk Wolterink
24/09/05, 19:55
Ik heb een leuk tooltje gevonden waarmee ik mijn
web applicatie kan testen op performance.
Maar wat is een normale troughput voor een
webapplicatie, en wat is bijvoorbeeld onacceptable.
Ik kom nu aan 1700 request / minute troughput.
Dat lijkt met een zeer goede troughput.
Dus vraag:
Wat is normaal voor een webserver/webapplicatie.
David Baakman
24/09/05, 21:15
Tjerk Wolterink wrote...
> Ik heb een leuk tooltje gevonden waarmee ik mijn
> web applicatie kan testen op performance.
Welke tool als ik vragen mag?
> Maar wat is een normale troughput voor een
> webapplicatie, en wat is bijvoorbeeld onacceptable.
>
> Ik kom nu aan 1700 request / minute troughput.
> Dat lijkt met een zeer goede troughput.
>
> Dus vraag:
> Wat is normaal voor een webserver/webapplicatie.
Dat is helemaal afhankelijk van wat de eis is. Als dat 1500
request/minuut is dan is 1700 goed, als dat 2000 request/minuut is is
dat niet genoeg.
Wanneer die eis niet bekend is, dan zul je die (als het even kan:
voordat je gaat testen) moeten definieren. En hoe hoog de eis moet zijn
is helemaal afhankelijk van de business (de homepage van msn.nl zal een
iets hogere eis hebben dan de site van de bakker om de hoek). Bij het
definieren van de eis is het trouwens ook gebruikelijk om te spreken van
een bepaalde transactie, dat zegt meer dan een aantal requests (wanneer
je het aantal statische objecten dat opgehaald moet worden verhoogt, dan
zal je ook meer requests/minuut kunnen afhandelen).
Dus eisen als: 'de applicatie moet in staat zijn om minimaal 1000
bestellingen van een broodje per uur af te handelen', of 'de applicatie
moet in staat zijn om 10 zoekopdrachten per dag af te handelen'.
Wat een goede transactie is is belangrijk om te definieren (denk aan:
wat te doen met bezoekers die alleen een beetje op de bakker-op-de-hoek-
site rondbrowsen zonder iets te bestellen, wat te doen met bezoekers die
op pagina 9 van 11 van de broodjes-bestel-module terechtkomen). In de
praktijk wil je aan de ene kant een mix maken tussen alle transacties
die plaats zullen vinden, maar aan de andere kant wil je je test ook
eenvoudig houden.
En de hoeveelheid in de eisen moet je natuurlijk ook definieren: hoeveel
bezoekers heeft de site nu; hoeveel klanten heeft de bakker nu; worden
broodjes de hele dag door besteld, of vooral tussen de middag; het hele
jaar door, of alleen in de zomer? Wordt er groei verwacht, en zo ja,
hoeveel. In sommige gevallen is dat relatief eenvoudig doordat er al
informatie beschikbaar is, in andere gevallen moet je aannames maken en
moeten vertrouwen op schattingen van anderen.
Houd ook rekening met de situatie over een aantal jaar (wat gebeurt er
als de database goed gevuld is, blijft de performance gelijk?).
Verder is het ook nog belangrijk om rekening met de hardware te houden.
Op wat voor hardware wordt getest, en op welke hardware komt de
applicatie te draaien (ik heb wel eens wat op m'n laptop ge-performance-
test wat uiteindelijk op een zooi IBM p670's komt te draaien, dan zijn
absolute getallen leuke bladvulling, maar meer ook niet).
Maar om op die 1700 terug te komen. Als het puur om requests gaat is het
heel moeilijk om daar iets over te zeggen zonder te weten hoeveel van
die requests statisch is, en wat er gebeurt op de dynamische pagina's
(het ophalen van wat content uit een CMS is natuurlijk heel wat anders
dan het afhandelen van een gecombineerde vakantie boeking waar
gelijktijdig de vlucht als het hotel gereserveerd worden).
Groeten,
David
On Sat, 24 Sep 2005 21:12:03 +0200, David Baakman <davidbaakman@nl.invalid> wrote:
> Tjerk Wolterink wrote...
[aantal requests per foo]
> Maar om op die 1700 terug te komen. Als het puur om requests gaat is het
> heel moeilijk om daar iets over te zeggen zonder te weten hoeveel van
> die requests statisch is, en wat er gebeurt op de dynamische pagina's
> (het ophalen van wat content uit een CMS is natuurlijk heel wat anders
> dan het afhandelen van een gecombineerde vakantie boeking waar
> gelijktijdig de vlucht als het hotel gereserveerd worden).
En op het moment dat je daar in gaat ronddolen spelen weer heel andere
zaken mee.
* heb je veel io verkeer vanuit je model.
* heeft de betreffende webserver voldoende cache.
* hoeveel concurrent users zitten erop.
.....
Hans
--
<iemand>
iemand heeft een gat gevonden in pdp's access.db? bel cnn
http://blacklist.kernelnewbies.nl