[AJAX] Load testing continuous AJAX update script op server

[Flowmo]

Voor een project van ons webbureau hebben we een javascriptje ontwikkeld dat elke 0.5 sec een request afvuurt naar de server om nieuwe data op te vragen. Dit gebeurt dmv jquery en ajax, die dan een request voor data afvuurt en deze dan op de pagina verwerkt zodra de data binnen is.

Nu willen we de server load van dit script testen op de server met ongeveer 500 gelijktijdige verbindingen op de betreffende pagina met het scriptje. Probleem is dat een heleboel web-based load testing services alleen verbinding maken met een pagina, daarna de verbinding droppen en weer opnieuw beginnen om de load te simuleren.

Dat werkt dus niet icm dat scriptje, aangezien dat scriptje pas begint te draaien zodra de pagina geladen is. Wat ik dus in feite wil is de pagina simultaan te laten bezoeken door 500 echte browsers en deze verbinding ongeveer 20 minuten open laten staan om te kijken hoe de server omgaat met zoveel requests per seconde.

Ik heb gisteren al Browsermob.com gevonden. Deze site laat echte browsers de site bezoeken en kan ook nog dmv een Selenium script acties uitvoeren op de betreffende pagina, alleen is dat niet wat we nodig hebben aangezien er geen acties uitgevoerd hoeven te worden, alleen de pagina bezoeken en daar 20 minuten rondhangen.

Heeft er iemand ervaring met een dergelijke load test, of een partij die zo'n service aanbiedt?

[Bosmonster]

Je kunt zelf een redelijke hoeveelheid testen door die timer flink te verlagen natuurlijk

Als je het 10x zo snel doet heb je nog maar 50 clients nodig. En dat kan makkelijk op 5 computers met 10 sessies om maar iets te noemen.

Maar goed.. je hebt het over 1000 requests per seconde voor dat poll-scriptje alleen. Kan je server zo'n hoeveelheid requests uberhaupt wel aan? De requests alleen kun je ook op een andere manier testen. Als er zoveel clients tegelijkertijd mee moeten kunnen werken is pollen waarschijnlijk gewoon niet de beste oplossing om mee te beginnen

[ Voor 45% gewijzigd door Bosmonster op 19-08-2010 16:57 ]

[Niemand_Anders]

Maar je kunt dit toch gewoon helemaal buiten de browser om testen? Het gaat toch om de load op de webserver? Bijvoorbeeld via de Microsoft Web Application Stress tool kun je vrij eenvoudig honderden requests naar het update script uitvoeren, eventueel vanaf verschillende computers. De response van de server zelf is inrelevant..

Hier kun je een korte handleiding vinden: http://www1bpt.bridgeport...eb_application_stress.htm

[Flowmo]

Probleem is dat onze up- en downlink waarschijnlijk niet snel genoeg is om dat te simuleren. we hebben hier al eens 50 browser vensters open gezet, maar dan loop je toch tegen een limiet aan.

Pc's vonden dat ook niet heel erg fijn eigenlijk, van 20 browser tabs * 2x per seconde een request + data afhandeling Zelfs Google Chrome blijft dan een beetje hangen

[Flowmo]

Niemand_Anders schreef op donderdag 19 augustus 2010 @ 16:56:
Maar je kunt dit toch gewoon helemaal buiten de browser om testen? Het gaat toch om de load op de webserver? Bijvoorbeeld via de Microsoft Web Application Stress tool kun je vrij eenvoudig honderden requests naar het update script uitvoeren, eventueel vanaf verschillende computers. De response van de server zelf is inrelevant..

Hier kun je een korte handleiding vinden: http://www1bpt.bridgeport...eb_application_stress.htm

Zoiets zou wel kunnen inderdaad, maar het gaat hier ook op een LAMP server. Windows apps zullen daar dus niet op werken.

Zou een php cronjob kunnen werken die iets van 1000x per seconde wordt uitgevoerd? Dan kunnen wij hier achter onze pc's de responstijd van de server wel in de gaten houden.

Bosmonster schreef op donderdag 19 augustus 2010 @ 16:52:Maar goed.. je hebt het over 1000 requests per seconde voor dat poll-scriptje alleen. Kan je server zo'n hoeveelheid requests uberhaupt wel aan? De requests alleen kun je ook op een andere manier testen. Als er zoveel clients tegelijkertijd mee moeten kunnen werken is pollen waarschijnlijk gewoon niet de beste oplossing om mee te beginnen

Nu weten we niet of dat er ooit uberhaupt 500 clients tegelijkertijd dat scriptje aan zullen roepen, maar we willen gewoon weten "what if" en hoe gaat de server ermee om?

Zie bijvoorbeeld deze site: http://www.bidrivals.com/
Deze site heeft geloof ik ook zo'n dergelijk scriptje draaien op de achtergrond die de laatste biedingen op die producten ophaalt.
Nu hebben we voor ons project ook zo'n dergelijk scriptje dat dus om de paar tiende van een seconde data ophaalt van de server. Dit gebeurt 2x per seconde, dat is al minder vaak dan wat Bidrivals heeft als ik het goed zie.

Nu weet ik niet wat de traffic is van Bidrivals, maar het lijkt me dat ze daar ook met een redelijke load te maken hebben, als je ziet hoe actief die website is.

[ Voor 40% gewijzigd door Flowmo op 19-08-2010 17:16 ]

[RobIII]

Flowmo schreef op donderdag 19 augustus 2010 @ 17:04:
[...]

Zoiets zou wel kunnen inderdaad, maar het gaat hier ook op een LAMP server. Windows apps zullen daar dus niet op werken.

Je begrijpt het niet helemaal. De stresstool (of "een" stresstool) doet niets anders dan een shitload http requests versturen (net zoals een browser dat doet) zonder daarna de moeite te nemen de response (html, afbeeldingen etc.) te gaan renderen zoals een browser dat zou doen. Eventuele http-status codes etc. worden wél bekeken (zodat de tool kan aangeven dat er een "server too busy" ofzo optreedt bij X connecties). Of je die tool nou draait op Windows, OSX of op een Commodore64 boeit niet (behalve dat die laatste niet veel load zal veroorzaken )

[Cartman!]

Gewoon je requests capturen en dan replayen, steeds sneller zodat je weet wanneer je problemen krijgt. Je hostingprovider zou daar de juiste tools wel voor moeten hebben.

Overigens ben ik afgelopen dagen bezig geweest met APE Server wat misschien voor jou ook interessant is. Dan hoef je niet continu te pollen, als de server nieuwe data heeft dan krijg je t direct

[Flowmo]

Cartman! schreef op donderdag 19 augustus 2010 @ 17:40:
Gewoon je requests capturen en dan replayen, steeds sneller zodat je weet wanneer je problemen krijgt. Je hostingprovider zou daar de juiste tools wel voor moeten hebben.

Overigens ben ik afgelopen dagen bezig geweest met APE Server wat misschien voor jou ook interessant is. Dan hoef je niet continu te pollen, als de server nieuwe data heeft dan krijg je t direct

Dat is in feite AJAX long polling, de server pas een antwoord laten geven zodra er nieuwe data is. Zouden we ook kunnen doen, alleen voorkom je dan niet dat zodra er nieuwe data is, dat deze data alsnog naar een paar honderd gebruikers moet worden verzonden.

Daarnaast is het concept waar wij dit voor ontwikkelen gebaseerd op een behoorlijk actieve pagina, waar in feite meerder acties per seconde op plaats kunnen vinden en er dus bijna altijd wel nieuwe data is.

[wackmaniac]

Je kan hier volgens mij prima Apache Benchmark voor gebruiken. Zit volgens mij standaard bij de Apache webserver meegeleverd.

[Cartman!]

Flowmo schreef op vrijdag 20 augustus 2010 @ 13:17:
[...]

Dat is in feite AJAX long polling, de server pas een antwoord laten geven zodra er nieuwe data is. Zouden we ook kunnen doen, alleen voorkom je dan niet dat zodra er nieuwe data is, dat deze data alsnog naar een paar honderd gebruikers moet worden verzonden.

Daarnaast is het concept waar wij dit voor ontwikkelen gebaseerd op een behoorlijk actieve pagina, waar in feite meerder acties per seconde op plaats kunnen vinden en er dus bijna altijd wel nieuwe data is.

En dat is dus precies waar APE voor gemaakt is, een low-level manier om op de snelste manier de data bij je gebruikers te krijgen, ook al is dat meerdere keren per seconde. APE is daar helemaal voor geoptimaliseerd terwijl Apache dit niet is. Alle keren dat jij voor niks een poll doet bij de server moet je wel al die verbindingen opbouwen, zonde van je resources. Je moet t zelf weten natuurlijk maar als je schaalbaar wilt zijn dan zou ik t wel weten.