[PHP] Vraag over architectuur script

[Dimby]

Hallo mede-tweakers,

Ik speel al een tijdje met een idee in mijn hoofd om gebruikers (spelers) van websites beter met elkaar te verbinden door een soort instant message service te beginnen. Spelers van bijvoorbeeld mijn online spel kunnen andere spelers heel simpel een berichtje sturen. Ze klikken op de gebruiker en rechts onder verschijnt een tekstvlak. Na het verzenden schiet er zo'n, msn soort, popup omhoog bij die gebruiker met het bericht. Daarop kan hij/zij reageren enzevoorts, je kunt dit zo uitgebreid maken als je zelf wilt. Dit geheel ben ik aan het maken met PHP, MySqlI en Jquery. Met Jquery/javascript (setTimeout) controleer ik elke 2 seconde via een .load() functie of er een bericht voor die spelers is. Zo ja laat ik die zien en de rest weten jullie wel. Nu gaat het mij om het controle systeem of er een bericht klaar staat. Is deze constructie te zwaar voor een dedicated server ? Kan het 100, 1000 of 5000 tegelijk aan? Raden jullie mij totaal iets anders aan (voor de controle)?

Bedankt,
Paul du Long

[muksie]

Dat ligt natuurlijk voornamelijk aan hoeveel werk één check is. In ieder geval zul je je systeem zo schaalbaar mogelijk op moeten zetten, zodat je eenvoudig meer servers bij kunt plaatsen wanneer dat nodig is.

[Dimby]

De check zal bestaan uit 1 bestand met daarin 1 query die gegevens haalt uit 1 tabel.

[Borizz]

Aangezien het een instant message is (neem ik aan gezien de voorbeelden die je erbij geeft) zou je er ook nog voor kunnen kiezen om de berichten in het geheugen op te slaan i.p.v. in de database. Dit kan in PHP bijvoorbeeld met memcache. Dit is veel sneller dan de berichten in de database opslaan (en weer ophalen).

Of een bepaalde dedicated server dit aankan is helemaal afhankelijk van de server hardware en de gebruikte software en hoe de (PHP) applicatie in elkaar zit die erop draait.

[Ahrnuld]

Zoals je het schetst lijkt het me een goede oplossing die heel makkelijk 5.000 simultane users aankan op een dedicated server. Weinig dataverkeer en weinig processing time. Doen!

[cariolive23]

Hoeveel concurrent users verwacht jij op de database? MySQL kan niet goed tegen veel gelijktijdige gebruikers, zie de tests (een hele serie, zie de linkjes) die Tweakers heeft uitgevoerd. Wanneer je echt veel concurrent users verwacht, gaat MySQL je in de steek laten, dan kun je beter direct met PostgreSQL aan de slag gaan. Tot 1000 concurrent users is dan geen probleem, met wat aanpassingen kun je zelfs doorschalen tot 1500 concurrent users (met aan aan Sun). Daarmee kun je dan vele tienduizenden bezoekers per minuut van data voorzien, ze zitten tenslotte niet allemaal gelijktijdig op de database.

Uiteraard moet je dan wel goede hardware hebben, die moet het ook aankunnen. PostgreSQL is een database die veel voordeel heeft van meerdere cores in een processor, hoe meer hoe beter.

[Cartman!]

Of je draait via een cronjob elke x seconden een update naar een file, dan roep je de file aan ipv. een database call. Misschien iets simpeler dan memcache hoewel ik denk dat die laatste sneller dan zijn

[storeman]

Memcache is inderdaad erg handig bij dit soort dingen, dat wil je niet altijd uit je db blijven pollen. Zeker niet met 1000 gebruikers:

1000 * 30 = 30.000 queries/min dat wordt wel krap! Het is daarnaast natuurlijk ook afhankelijk van de overhead van je PHP script. Houd ook gelijk rekening met goede indexen in je tabellen.

Wat natuurlijk veel mooier is: http://www.ape-project.org/

[Dimby]

Ja nu ik Memcache zie lijkt dit me zeer interessant.
Toevallig kwam ik Ape vanochtend tegen via Ajaxrain maar dit lijkt me meer geschikt als je dezelfde data aan vele users wilt laten zien. Dat is nu niet het geval het is steeds verschillende data per user.

EDIT:
Stel ik wil dit idee uitbreiden met het volgende: Ik wil als operator dienen en dan websites de mogelijkheid geven deze instant messenger te gebruiken tussen hun leden. Zij, als webmaster zijnde, includen een .js bestand die elke 2 seconden via cUrl kijkt of er berichten voor die user is via mijn server.

[ Voor 38% gewijzigd door Dimby op 19-06-2009 22:04 . Reden: uitbreiding ]

[Voutloos]

cariolive23 schreef op vrijdag 19 juni 2009 @ 20:46:
Hoeveel concurrent users verwacht jij op de database? MySQL kan niet goed tegen veel gelijktijdige gebruikers, zie de tests (een hele serie, zie de linkjes) die Tweakers heeft uitgevoerd. Wanneer je echt veel concurrent users verwacht, gaat MySQL je in de steek laten, dan kun je beter direct met PostgreSQL aan de slag gaan. Tot 1000 concurrent users is dan geen probleem, met wat aanpassingen kun je zelfs doorschalen tot 1500 concurrent users (met aan aan Sun). Daarmee kun je dan vele tienduizenden bezoekers per minuut van data voorzien, ze zitten tenslotte niet allemaal gelijktijdig op de database.

Uiteraard moet je dan wel goede hardware hebben, die moet het ook aankunnen. PostgreSQL is een database die veel voordeel heeft van meerdere cores in een processor, hoe meer hoe beter.

Pfff, de keuze tussen RDBMS'en bepaalt dus echt niet de bottleneck. En als dat al wel zo was, zouden ze het allebei ruim afleggen tegen alternatieve, non-relationele db's voor de messages (denk aan producten als CouchDB, Memcached, MemcacheDB etc etc).

De meeste winst tov de startpost situatie zit hem in het minder doen: minder pollen, te pollen met sleep tot er een response is, of te pushen.

[Dimby]

Memcache is niet zo makkelijk te installeren op je Usbwebserver

[Manuel]

Dimby schreef op vrijdag 19 juni 2009 @ 22:33:
Memcache is niet zo makkelijk te installeren op je Usbwebserver

Ik dacht dat je dit zo kon installeren?
clicky of clicky

[Megamind]

Manueltje22 schreef op zaterdag 20 juni 2009 @ 02:49:
[...]


Ik dacht dat je dit zo kon installeren?
clicky of clicky

Dan moet er nog wel een memchached daemon draaien

Alhoewel er wel een aantal windows versies te vinden zijn.

[Wolfboy]

Voor 100 gebruikers is dit prima te doen, bij 1000 zal je alles statisch moeten gaan hosten en niet meer continu een php bestand laten pollen. Met 5000 is het zo goed als onmogelijk met deze oplossing.

De beste oplossing voor dit soort systemen is een server die de verbinding continu open kan houden. Let wel dat Apache hier niet geschikt voor is en PHP kan je dus ook wel vergeten. Wat eventueel nog een leuke (tegenwoordig veelgebruikte) oplossing hiervoor is, een XMPP (Jabber, net als Google talk) server inzetten voor deze communicatie. Dan heb je al een server die het zware werk (veel verbindingen open houden) voor je afhandeld en hoef je dus alleen nog maar de berichten door te sturen.

[Dimby]

Bedoel je met statisch opslaan, het opslaan in een bestand?
Is dit niet arbeidsintensiever dan een database?

[Wolfboy]

Nee, in principe niet. Als je het in de database opslaat heb je de volgende stappen als je het uitvoert
[list=1]• Het php bestand openen en uitvoeren
• De database configuratie includen vanuit bovenstaand php bestand
• Eventueel (afhankelijk van je setup) een database abstractielaag php bestand openen.
• Query naar de database sturen
• Database resultaten verwerken

Dat dus, versus:
[list=1]• Bestand uitlezen (zonder php stap, dus sneller dan een normaal php bestand openen)

Wat alleen lastiger is, je moet bij elk bericht dat er verstuurd wordt dus het bestand gaan updaten.


Om daar omheen te werken en het geheel wat efficienter te laten werken kan je dus een server inzetten die gewoon continu een verbinding open heeft met de client, die hoeft dus ook alleen iets door te sturen zodra er een bericht is.