Ajax load balancer

[Rekcor]

In mijn script maak ik aardig wat ajax-calls. Wat ik eigenlijk aan het doen ben is pollen of de server al iets nieuws heeft van andere users*. Nu wil ik voorkomen dat de server overbelast raakt. Met andere woorden: als het niet druk is op de server, mag iedere client bijv. 1 ajax call per seconde doen, maar als het wel druk is, max 1 ajax call per minuut.

Nu vraag ik me af hoe ik dit het beste aan kan pakken. Momenteel zie ik twee opties:
1. De server geeft met iedere call een getalletje terug: serverScriptExecutionTime. Het object wat de calls afhandelt stopt serverExecutionTime in een formule om het volgende tijdstip uit te rekenen.
2. Gelijk aan 1, echter nu meet ik op de client voor de Ajax-call en op het moment dat de call terugkomt (met new Date().getTime(); Deze twee van elkaar afgetrokken geeft serverExecutionTime.

Vervolgens stop ik serverExecutionTime in de volgende formule:

JavaScript:

var max_user_waiting_time = 10; //the maximum amount of seconds for the next call
var min_user_waiting_time = 0.500; //the minimum amount of seconds for the next call
var max_server_execution_time = 10000; //the maximum server time in ms we accept
var min_server_execution_time = 50; //the minimum server time (so time the server side script takes when server has little load)

var timeOutInSeconds = min_user_waiting_time+((max_user_waiting_time-min_user_waiting_time)*((serverExecutionTime-min_server_execution_time)/max_server_execution_time));

Wat vinden jullie hiervan?

* Ik ben op de hoogte van Wikipedia: Comet (programming) technieken, maar ik ben nu gelimiteerd tot een standaard LAMP-configuratie (zonder Tomcat). Ik zal het dus met PHP moeten zien te rooien. Zie ook http://stackoverflow.com/...3201/using-comet-with-php. In mijn project wil ik een 'proof of principle' leveren, waarbij ik wel nodig heb dat verschillende gebruikers elkaars gegevens in (zo veel mogelijk) realtime binnenkrijgen. Als het blijkt te werken met weinig gebruikers (max 30), wil ik eea echt schaalbaar maken met Comet oid.

[Cartman!]

Zoiets is eerder een lapmiddel dan het probleem aanpakken maar dat weet je zelf ook wel denk ik. Ik zou gewoon gaan voor een schaalbare oplossing:

1. Een server als APE installeren, die is gemaakt voor comet-achtige constructies, erg lichtgewicht en kan vele concurrent users aan.
2. Loadbalancen op server-niveau. Wordt t drukker: server erbij plaatsen en horizontaal schalen.

Ik zou optie 1 verkiezen omdat je niet direct extra servers nodig hebt dan.

[ Voor 4% gewijzigd door Cartman! op 12-08-2011 11:01 ]

[Rekcor]

Cartman! schreef op vrijdag 12 augustus 2011 @ 11:01:
Zoiets is eerder een lapmiddel dan het probleem aanpakken maar dat weet je zelf ook wel denk ik. Ik zou gewoon gaan voor een schaalbare oplossing:

1. Een server als APE installeren, die is gemaakt voor comet-achtige constructies, erg lichtgewicht en kan vele concurrent users aan.
2. Loadbalancen op server-niveau. Wordt t drukker: server erbij plaatsen en horizontaal schalen.

Ik zou optie 1 verkiezen omdat je niet direct extra servers nodig hebt dan.

Ik begrjip je reactie, maar 'men' (degenen met het geld) willen eerst weten of het principe achter de webapplicatie werkt. Met andere woorden: of de afnemers het überhaupt willen gebruiken. Pas daarna wil men investeren in extra hardware. Ik zoek dus inderdaad naar een lapmiddel, die mij in staat stelt om uit te zoeken of de webapplicatie potentie heeft. Zie het als een pilot-experiment .

[ameesters]

misshien even hier naar kijken: Wikipedia: Reverse Ajax

[Cartman!]

Best zinloos, dat komt gewoon neer op "COMET" en er staat ook niet uitgelegd hoe je dat zou moeten doen met de middelen die de TS heeft

@TS Dan begrijp ik je topic niet helemaal, je beiden methoden komen redelijk overeen en ik zou t dan gewoon maar proberen. Wat je van ons verwacht is een beetje onduidelijk nu want je keuze is al gemaakt dat je niet een "echte" oplossing wil/kunt gebruiken.

[ameesters]

Cartman! schreef op vrijdag 12 augustus 2011 @ 11:39:
Best zinloos,

niet.

Cartman! schreef op vrijdag 12 augustus 2011 @ 11:39:
dat komt gewoon neer op "COMET"

Hoeft niet kan wel...

Cartman! schreef op vrijdag 12 augustus 2011 @ 11:39:
en er staat ook niet uitgelegd hoe je dat zou moeten doen met de middelen die de TS heeft

[google=reverse ajax]
LMGTFU achtige linkjes mogen wel achterblijven

[ Voor 7% gewijzigd door BtM909 op 15-08-2011 12:06 ]

[Rekcor]

Cartman! schreef op vrijdag 12 augustus 2011 @ 11:39:
@TS Dan begrijp ik je topic niet helemaal, je beiden methoden komen redelijk overeen en ik zou t dan gewoon maar proberen. Wat je van ons verwacht is een beetje onduidelijk nu want je keuze is al gemaakt dat je niet een "echte" oplossing wil/kunt gebruiken.

Mijn vraag was of mijn 'lapmiddel' volgens jullie ook daadwerkelijk iets lapt, of ik niet iets fundamenteels over het hoofd zie, enz.

Het zou namelijk wel prettig zijn als de boel niet vastloopt tijdens de pilot.

[peterkuli]

Helemaal zeker weten doe ik het niet maar volgens mij is node.js voor dit soort dingen best geschikt. Veel chat-achtige applicaties (waar je dus ook graag een open socket wil) gebruiken dit. Node schijnt ook veel requests aan te kunnen omdat het (net als client side JS uiteraard) event-driven is.

[joppybt]

1) In een ver verleden heb ik wel eens een code-analyse van de Google suggest gelezen en Google doet (deed?) precies wat jij hier beschrijft. Ze geven een indicatie terug hoe druk hun server is.

2) Is een slecht plan. Als een gebruiker een heel langzame verbinding heeft duurt het lang voordat hij zijn antwoord heeft zonder dat jou server druk is. Vervolgens ga jij er om te pesten ook nog een server-vertraging bovenop doen?

[Rekcor]

Bedankt voor jullie reacties!

[Wolfboy]

Optie 1 lijkt me hier de beste (non-comet) optie. Maar voor je er een ingewikkeld systeem van gaat maken om de load in te schatten... probeer eerst eens te kijken hoe erg het daadwerkelijk gaat worden met de load