[php] Gebruikers / sessies limiteren, failover

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Voor een webbased survey applicatie wil ik PHP (LAMP) gaan gebruiken, maar ik zit met een vraag waarop ik via gmane en google geen (eenduidig) antwoord kan vinden.

Wat ik wil is het volgende:

Stel er komen 1000 users tegelijk en ik wil er 100 van toelaten (= laten beginnen aan het invullen van de sessions-gebaseerde vragenlijst).
De overige 900 users moeten nu een lichtgewicht HTML-'Sorry we zitten even vol'-pagina krijgen, totdat er weer <100 visitors bezig zijn met invullen.

Dit limiet (100 is even als voorbeeld) moet daarnaast ook ergens van worden afgeleid... server load bijvoorbeeld.. of bandbreedte.
Het gaat er in elk geval om dat de mensen die bezig zijn met invullen, niet kunnen worden getroffen door uitval van de server door overbelasting..
Hoe kan zo'n (pseudo) failover / protectie mechanisme worden opgezet op 1 server?

Ik ben hier verder nog niet bekend mee, en zit in de orienterende fase.
Sorry als het verwarrend klinkt, ik heb geen specifieke vraag, maar ben op zoek naar ervaringen, tips en technieken.

Acties:
  • 0 Henk 'm!

  • chris
  • Registratie: September 2001
  • Laatst online: 11-03-2022
Het probleem met webbased apps is dat je (neem ik aan) HTTP gaat gebruiken, en HTTP is stateless. Je kunt dus niet zien of een user gestopt is met invullen. Je kan een lijstje bijhouden (bijvoorbeeld in een tekstbestand) met ip-adressen en laatste actie. Die doorloop je iedere minuut om te kijken of er mensen zijn die langer dan 15 min (b.v.) niets gedaan hebben, zo ja: dan verwijder je ze. Op het moment dat een user een nieuwe request start om zo'n survey te beginnen, dan kan je kijken of er niet toevallig meer dan 100 regels in dat tekst-bestand staan, en als dat toch het geval zo'n error-message weergeven.

Het is niet helemaal waterdicht, maar volgens mij is het een prima oplossing voor wat jij wil, toch?

Acties:
  • 0 Henk 'm!

  • GlowMouse
  • Registratie: November 2002
  • Niet online
Wat is 'tegelijk'? Als het invullen van de survey een minuut of 15 duurt, heeft de server tijdens die 15 minuten niets te doen. Ook kun je niet zien of iemand de survey ingevuld heeft, of zijn internetverbinding al heeft verbroken.

Verder: als iemand een 'we zitten vol'-pagina krijgt, en hij gaat steeds refreshen, is het de vraag wanneer je beter af bent.

Acties:
  • 0 Henk 'm!

  • Andre-85
  • Registratie: April 2003
  • Niet online

Andre-85

Sid

Je moet er sowieso voor kiezen om een eigen database gebasseerd sessie systeem te maken en niet de sessies van php gebruiken. Zo kan je in iedergeval het aantal actieve sessies bepalen.

Met behulp van dit topic Adaptive loadbalancing - berekening is vast wel een manier uit te werken om je gebruikerslimiet te bepalen.

Lorem
Whenever we feel the need to comment something, we write a method instead. - Martin Fowler
People who think they know everything really annoy those of us who know we don't - Bjarne Stroustrup


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
chris schreef op maandag 02 januari 2006 @ 13:48:
Het probleem met webbased apps is dat je (neem ik aan) HTTP gaat gebruiken, en HTTP is stateless. Je kunt dus niet zien of een user gestopt is met invullen. Je kan een lijstje bijhouden (bijvoorbeeld in een tekstbestand) met ip-adressen en laatste actie. Die doorloop je iedere minuut om te kijken of er mensen zijn die langer dan 15 min (b.v.) niets gedaan hebben, zo ja: dan verwijder je ze. Op het moment dat een user een nieuwe request start om zo'n survey te beginnen, dan kan je kijken of er niet toevallig meer dan 100 regels in dat tekst-bestand staan, en als dat toch het geval zo'n error-message weergeven.

Het is niet helemaal waterdicht, maar volgens mij is het een prima oplossing voor wat jij wil, toch?
interesting.. dat is misschien wel gewoon voldoende inderdaad

of misschien de sessie-ids bijhouden in een mysql table ipv als files in /temp
en dan voor de rest hetzelfde doen als wat jij hierboven uitlegt... (aantal sessie-ids tellen, >15 minuten-idle-records deleten)

Acties:
  • 0 Henk 'm!

  • Justifier
  • Registratie: December 2004
  • Laatst online: 06-04-2024
kun je niet gewoon als hij de eerste pagina opent de sessie in een database starten en zodra hij bij de laatste pagina op verstuur heeft gedrukt, hem weer uit de database verwijderen.

Acties:
  • 0 Henk 'm!

Verwijderd

Verwijderd schreef op maandag 02 januari 2006 @ 13:56:
[...]

interesting.. dat is misschien wel gewoon voldoende inderdaad

of misschien de sessie-ids bijhouden in een mysql table ipv als files in /temp
en dan voor de rest hetzelfde doen als wat jij hierboven uitlegt... (aantal sessie-ids tellen, >15 minuten-idle-records deleten)
Een iets efficientere manier is wellicht om mbv ajax om de 10 (of whatever) seconde een request te doen naar een pagina die enkel een tijd update in de database. Wanneer er een aanvraag komt van iemand die 'erbij wil', kun je in de database checken hoeveel mensen er binnen de afgelopen 10 seconde zo'n ajax-submit hebben gedaan. Begrijpelijk heb je dan wel een flink aantal requests per seconde, maar gezien de load hiervan mag dit geen problemen opleveren toch.

Acties:
  • 0 Henk 'm!

  • Erkens
  • Registratie: December 2001
  • Niet online

Erkens

Fotograaf

Justifier schreef op maandag 02 januari 2006 @ 13:58:
kun je niet gewoon als hij de eerste pagina opent de sessie in een database starten en zodra hij bij de laatste pagina op verstuur heeft gedrukt, hem weer uit de database verwijderen.
en op gegeven moment zal niemand meer de survey kunnen invullen ;)

Acties:
  • 0 Henk 'm!

  • Justifier
  • Registratie: December 2004
  • Laatst online: 06-04-2024
Erkens schreef op maandag 02 januari 2006 @ 14:27:
[...]

en op gegeven moment zal niemand meer de survey kunnen invullen ;)
waarom kan op een gegeen moment niemand hem meer invullen :?

Acties:
  • 0 Henk 'm!

  • TheRookie
  • Registratie: December 2001
  • Niet online

TheRookie

Nu met R1200RT

Omdat niet iedereen de laatste pagina zal versturen en dus als actieve sessie geregistreerd zal blijven; daarom ook handig om na een x aantal minuten oude sessies te sluiten ..

Acties:
  • 0 Henk 'm!

  • djluc
  • Registratie: Oktober 2002
  • Laatst online: 14:28
Denk je echt dat je aan de limiet van een Apache/PHP server gaat komen? Ik zou eerst eens testen of het wel noodzakelijk is om dergelijke beperkingen op te stellen en of je niet met optimalisaties toch voldoende performance kan bereiken. Sowieso moet je heel wat moeite doen om een DDOS op je server te krijgen waardoor je dus echt plat gaat. Het kan uiteraard wel zijn dat het traag wordt of dat je de beperking in de Apache config tegenkomt.

Acties:
  • 0 Henk 'm!

Verwijderd

Djluc heeft een goed punt, ga eens goed na of je wel een dermate grote serverload gaat krijgen bij gebruik door een x-aantal bezoekers/gebruikers dat je systeem echt `plat gaat`. Mijn ervaring is dat je heel gek moet doen wil dat gaan gebeuren - er vanuitgaand dat je een normale en dus goede server gebruikt voor het hosten van je webbased applicaties.

Acties:
  • 0 Henk 'm!

  • djluc
  • Registratie: Oktober 2002
  • Laatst online: 14:28
Klopt, het is ook eigenlijk alleen maar symptoonbestrijding. Als je echt meer bezoekers krijgt dan je server kan verwerken met een redelijk optimale applicatie dan heb je simpelweg te weinig capaciteit om de gegevens te verwerken. Dat kan je wel gaan bestrijden met dit soort beperkingen maar in principe is alleen het toevoegen van capaciteit een degelijke oplossing.

Acties:
  • 0 Henk 'm!

  • xces
  • Registratie: Juli 2001
  • Laatst online: 20-09 16:56

xces

To got or not to got..

en dat niet alleen, de 100 users die jij als voorbeeld noemt vragen een pagina op, vullen alles client-side in, en doen niets totdat de data verstuurd wordt. D.w.z. de kans dat er 1000 "exact" simultane verwerkingen zijn is wel zo miniem dat je daar in mijn ogen geen tijd en aandacht aan hoeft te besteden, dit werkt apache prima zelf af.

Acties:
  • 0 Henk 'm!

Verwijderd

Moest je hier toch aan willen verderwerken (of anderen die dit topic lezen); hiermee kan je de load opvragen voor een Linux/FreeBSD server:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
$uptime = @exec('uptime');
preg_match("/averages?: ([0-9\.]+),[\s]+([0-9\.]+),[\s]+([0-9\.]+)/",$uptime,$avgs);
  $uptime = explode(' up ', $uptime);
  $uptime = explode(',', $uptime[1]);
  $uptime = $uptime[0].', '.$uptime[1];
$start=mktime(0, 0, 0, 1, 1, date("Y"), 0);
$end=mktime(0, 0, 0, date("m"), date("j"), date("y"), 0);
$diff=$end-$start;
$days=$diff/86400;

$load1=$avgs[1];
$load2=$avgs[2];
$load3=$avgs[3];


En dit is misschien ook handig, het houdt de connectie open zodat de gebruiker een melding kan krijgen wanneer de server minder te doen heeft;

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
<?php

set_time_limit(900);

// Start output buffering
ob_start();

$message = "First test message";
$oldmessage = "bla";

// Keep on repeating this to prevent PHP from stopping the script
while (true)
{
   $timeoutcounter = 0;
   while ($message == $oldmessage)
   {
       // If 10 seconds elapsed, send a dot (or any other character)
       if ($timeoutcounter == 10)
       {
           echo ".";
           flush();
           ob_flush();
           $timeoutcounter = 0;
       }
       // Timeout executing
       sleep(1);
       // Check for a new message
       $message = file_get_contents("chatdata.txt");
       $timeoutcounter++;
   }

   // Keep the old message in mind
   $oldmessage = $message;

   // And send the message to the user
   echo "<script>window.alert(\"" . $message . "\");</script>";

   // Now, clear the output buffer
   flush();
   ob_flush();
}

?>
Pagina: 1