PHP - Chat - Performancewise

[ZpAz]

Hoi hoi.

Ik heb voor een klant de opdracht om een chat systeem te maken, met PHP. Nu weet ik best wel dat Http niet bepaald bedoelt is om een chat systeem op te basseren. Maar op de servers van de klant (shared) kan ik helaas niets op installeren.

Anders kon ik voor een wat minder spartaanse oplossing kiezen.

Nu heb je met Http/Php een beetje twee mogelijkheden voor zo ver ik weet.

- Pollen elke seconde (of minder) kijken of er wat nieuws is. (Ajax)
- Verbinding open laten staan. Als in, via een iFrame een 'pagina' laden die nooit stopt. En daar bij de events een '<script>' tag uitspugen welke direct door de browser wordt opgepakt.
- Iets anders? (Zonder extra software te installeren, het gaat hier enkel om Apache/PHP)

Nu vroeg ik me af, wat is performancewise beter? Pollen lijkt me een waste of bandwith, aangezien je de helft van de tijd geen updates krijgt, en er toch om vraagt. Een enkele client maakt dan laten we zeggen 60 requests per minuut.

Of de verbinding open laten staan, dit heeft als voordeel dat er net wat 'snappier' gereageert kan worden, immers zo snel er wat nieuws is op de server kan er meteen 'gepushed' worden naar de clients. En hoeft er niet eerst gewacht te worden tot de client zelf het inititiatief neemt om te kijken of er data is.

-----------

Mij lijkt de verbinding open laten staan een betere optie, omdat die in bandbreedte scheelt, en nog wat 'sneller' aan gaat voelen. Het nadeel van deze techniek is dat de browser constant een 'laden' icoontje blijft weergeven.

Omdat wanneer de verbindingen open blijven staan, de database verbindingen ook open blijven staan dat lijkt mij de grootste bottleneck (daarna) wordt zat ik te kijken hoe ik dat kan afvangen.

Nu dacht ik er aan om ipv dat elke client de database bekijkt om te kijken of er nieuwe berichten zijn er maar een enkele client is die dat doet, en de nieuwe resultaten in memcache duwt. Dan blijft er eigenlijk maar constant een enkele db connectie over al de clients openen.

(Voor dit moet ik dan wat verzinnen dat ik weet wanneer een client al als 'db connectie' speelt dat de rest dat niet meer doet. En wanneer deze weggaat (als in kruisje, internet valt weg) dat een andere client het overneemt. (Enig idee hoe ik dat kan uitwerken?)

Alle andere clients halen de nieuwste informatie uit de memcache.

-------

Is dat 'de beste manier' om via http/php/mysql een chat op te kunnen bouwen? (Welke een 'redelijke' groep gebruikers aan kan?)

-------

Ps, graag NIET reageren met PHP is daar niet geschikt voor, pleur een 'app-x' op de server welke daar veel beter geschikt voor is. Er draait enkel PHP/Apache op (dus bijvoorbeeld APE of een andere Comet applicatie welke softwarewijzigingen op de server vereist is geen optie.)

Het enige wat ik wil weten wat is de beste manier om via PHP/Javascript een chat op te zetten.

[RedHat]

Misschien kun je eens kijken hoe Mibbit dit doet? Dit is een gerenomeerde IRC-client (webbased).

[ZpAz]

Die heeft een beetje een mix van mijn idee blijkbaar. Een verbinding opzetten dmv ajax, en deze openhouden tot er een bericht binnenkomt. Wanneer deze binnenkomt dan de verbinding sluiten en een nieuwe verbinding opzetten.

Misschien is dat wel beter inderdaad, dat scheelt ook weer het altijd laden icoontje. Zijn er nog andere tips?

[ Voor 20% gewijzigd door ZpAz op 11-12-2009 11:27 ]

[mithras]

De functie van php heeft hier eigenlijk niet veel mee te maken. Het meest cruciale is de client side (die moet uiteindelijk een nieuw bericht binnenhalen). Je hebt comet, met long polling. Daarnaast hoorde ik laatst ook wat over pubsubhubbub, maar dat is meer geschikt voor hele directe messages dan een complete chat.

Kijk maar eens op http://en.wikipedia.org/wiki/Comet_(programming) en Wikipedia: PubSubHubbub

[ZpAz]

Voor comet moet je dacht ik altijd extra software installeren op de server (bijvoorbeeld APE of TomCat) en dat is iets wat niet mogelijk is.

[ Voor 187% gewijzigd door ZpAz op 11-12-2009 11:31 ]

[Joolee]

De beste oplossing zou via comet zijn maar daar heb je inderdaad extra software voor nodig. Verder kun je het beste iedere seconde pollen, of je moet wel heel veel bezoekers krijgen. Maar dan is het handig aan je hoster te vragen of ze een comet pakket kunnen installeren.

Laat de directe comunicatie verlopen via APC of Memcache, dan hoeft er niet bij iedere request een database link gemaakt te worden.

Apache vraagt per openstaande request behoorlijk wat geheugen. 400 requests van enkele ms is lichter voor de server dan 400 request die open gehouden worden. Het 'enige' dat een losse comet oplossing bied is een simpele webserver die minder geheugen gebruikt dan Apache per request.

[mithras]

Comet is toch gewoon een umbrella term voor allerlei long polling technieken? Je kan afaik een XHR long polling doen en wachten op een antwoord. Antwoord is bijv. je reply string van de andere chattende persoon. Op het moment dat je antwoord hebt pak je weer een nieuw XHR en start opnieuw een long polling request

[DexterDee]

Comet is een verzamelnaam voor het openhouden van een HTTP connectie om daar meerdere (semi)real-time events over te laten verlopen. Dat kan prima met een standaard Apache + PHP installatie.

Natuurlijk zijn er plugins die dit proces optimaliseren, maar Apache is prima in staat zonder aanpassingen om een HTTP connectie open te houden voor langere tijd. Hierbij moet gezegd worden dat Apache hier niet voor gemaakt is.

[Joolee]

mithras schreef op vrijdag 11 december 2009 @ 11:31:
Comet is toch gewoon een umbrella term voor allerlei long polling technieken? Je kan afaik een XHR long polling doen en wachten op een antwoord. Antwoord is bijv. je reply string van de andere chattende persoon. Op het moment dat je antwoord hebt pak je weer een nieuw XHR en start opnieuw een long polling request

Probleem daarmee is dus dat je met een beetje load het geheugen van de server vol laat lopen.

[ZpAz]

Pollen lijkt me gewoon niet wenselijk in een chat, zelfs een seconde elke keer is volgens mij irritand, met meerdere mensen komen de berichten dan op verschillende tijden binnen en staat de text bij iedereen op een andere volgorde. Daarnaast blijf ik er bij, dat lijkt me gewoon een bandbreedte verspilling. En dan is het systeem van bijvoorbeeld mibbit.com al weer beter.

(Verbinding maken, open blijven tot er data is, en weer sluiten, opnieuw aanmaken.) Dat zit dus tussen allemaal losse connecties, en een constant openstaande connectie (hidden iframe) in.

@Hierboven okee, comet is dus een verzamelnaam om verbindingen open te houden (al dan niet lijkend), en o.a APE is hier voor geoptimaliseerd en Apache niet.

@Mithras, ja inderdaad dat is dus wat mibbit ook doet. En mij de beste oplossing ook lijkt. Mocht ik er finaal naast zitten, barst los.

[ Voor 20% gewijzigd door ZpAz op 11-12-2009 11:36 ]

[YopY]

Pollen lijkt me gewoon niet wenselijk in een chat, zelfs een seconde elke keer is volgens mij irritand, met meerdere mensen komen de berichten dan op verschillende tijden binnen en staat de text bij iedereen op een andere volgorde. Daarnaast blijf ik er bij, dat lijkt me gewoon een bandbreedte verspilling. En dan is het systeem van bijvoorbeeld mibbit.com al weer beter.

Nee hoor - een chat komt binnen op een bepaalde tijd op de server, en worden teruggegeven op de tijd wanneer ze aangekomen zijn op de server. Daar komt nog bij, is dat zo erg? Als er elke seconde gepolled wordt, zul je chats die in de afgelopen seconde gemaakt zijn binnen halen - en ik betwijfel of mensen binnen een seconde een reply kunnen doen. Natuurlijk heb je altijd wat lag, maar twee omgewisselde chatberichten zullen echt niet zoveel uitmaken.

En qua bandbreedte zal het ook wel genoeg meevallen. Als je simpelweg met strings of CSV werkt, zul je als er chats zijn bij een poll mogelijk

code:

1234567,henk,ik doe een bericht :)
8901234,piet,doe niet zo mal.

teruggeven (een handjevol bytes), en niks of een placeholder als er geen nieuwe berichten zijn. Dat kost 0 bandbreedte, en sowieso kost bandbreedte niks tot weinig. En hoeveel bandbreedte is er beschikbaar op de host? Er zijn genoeg die onbeperkt (écht onbeperkt, geen FUP) bandbreedte leveren voor een 60 euro / jaar.

En als alternatief kun je nog een IRC server huren bij een externe partij. Een Java of Flash IRC client op je website zetten, en je bent klaar.

[DexterDee]

@YopY:
Het probleem is niet zozeer dat pollen per 1 seconde niet werkbaar is, maar dat het niet schaalbaar is. Het opzetten van een socket verbinding en de initialisatie die daarbij komt kijken is vele malen zwaarder dan een socket open te laten. Het verschil in load wordt erg groot als het aantal gebruikers gaat oplopen

[ZpAz]

Ik zie dat onder andere meebo wat toch wel een webbased chatsysteem is wat druk gebruikt wordt ook gebruik maakt van long polling, imho is dat dus nu echt 'the way to go'.

Het zou kunnen dat hun wel een speciale backend hebben aka APE. Maar mocht dit chatsysteem uit de hand lopen moet de klant dan maar over naar een systeem met een speciale Comet server-applicatie.

edit:

Lees hier dat Meebo gewoon gebruik maakt van Lighthttpd ipv Apache.

[ Voor 18% gewijzigd door ZpAz op 11-12-2009 11:57 ]

[Sypher]

DexterDee schreef op vrijdag 11 december 2009 @ 11:31:
Comet is een verzamelnaam voor het openhouden van een HTTP connectie om daar meerdere (semi)real-time events over te laten verlopen. Dat kan prima met een standaard Apache + PHP installatie.

Correct, zie bijvoorbeeld How to implement COMET with PHP.

@Mithras, ja inderdaad dat is dus wat mibbit ook doet. En mij de beste oplossing ook lijkt. Mocht ik er finaal naast zitten, barst los.

In hoeverre wil je afhankelijk zijn van een third party?
Daarbovenop zit je nog met advertenties, of moet je in de buidel tasten om die weg te krijgen..

[ZpAz]

Niet afhankelijk van een third party Ik heb al aangegeven dat dit niet de beste oplossing is, en er andere software dan beter geinstalleerd kon worden op de server. Maar dit was geen optie.

Enkel wat er nu is, dan kan gebruikt worden, een beetje roeien met de riemen die er zijn

[DexterDee]

Er is nog een andere optie als de hosting provider de PHP configuratie niet op safe mode heeft staan en de firewall niet te strak staat ingesteld. Je kunt een PHP proces via apache aftrappen dat z'n werk doet als socket daemon. Je opent een listening socket op een willekeurige poort (bijv. 8080) en serveert daarmee je chatgebruikers. Het PHP proces komt zelf in een oneindige runloop die bijv. een database pollt voor nieuwe berichten. Je maakt hiermee in feite een mini gespecialiseerd HTTP servertje en doordat de functionaliteit zeer beperkt is, is het memory gebruik en overhead erg laag. Ik heb op basis van dit principe een script gebouwd die realtime logregels via Comet naar meerdere concurrent webclients kan sturen en dat werkt perfect en met een zeer kleine footprint (9 mb geheugen, 0.5% CPU)

[ZpAz]

Volgens mij was ik dat inderdaad wel ergens tegen gekomen in de zoekresultaten hier.
Maar dat script moet dan altijd aan staan lijkt me? En hoe kan ik dat dan voor elkaar krijgen.

Misschien zo:
Cronjob op een bepaald bestand, welke elke minuut wordt aangeroepen. Die kijkt of de 'server draait' op poort 8080 oid en als dat zo is dan doet ie niet, en anders start hij hem.

En dat scheelt dus daadwerkelijk in de performance?

Dan zou je toch nog een stap verder kunnen gaan (mits de firewall niet geblocked is, en niet enkel http verkeer wordt doorgelaten) door bijvoorbeeld socket.js te gebruiken. Dan kan je sockets (dmv flash of java applet) in javascript gebruiken en heb je dus geen 'http verkeer overhead' meer.

edit:

Maar dan kan je natuurlijk weer zitten met de lokale firewall settings. Dat lijkt me dus niet zo'n goed plan bij nader inzien. En het bij gewoon http verkeer houden geeft later makkelijker de mogelijkheid om naar een gespecialiseerde comet server te verhuizen.

[ Voor 43% gewijzigd door ZpAz op 11-12-2009 12:33 ]

[DexterDee]

Qua performance zijn een aantal dingen relevant. Natuurlijk is PHP als scripttaal vele malen langzamer dan Apache dat native gecompiled is vanuit C. Het probleem met Apache als ingang voor je Comet calls is dat je verschillende threads of processes krijgt voor je connecties (afhankelijk van hoe Apache geconfigureerd staat). Die gaan op hun beurt weer allemaal de database pollen voor berichten, omdat dat zo'n beetje de enige makkelijke IPC constructie is om tussen processen te praten (shared mem, msg_queues, etc. even buiten beschouwing gelaten). Met de alternatieve methode waarbij je zelf op een socket luistert, zit alles in 1 proces. Je kan alle nieuwe berichten in 1 keer uit de database lezen en verdelen onder de aangesloten Comet connecties. De queryload zal dus een stuk lager zijn bij meerdere verbindingen. Verder kost het openhouden van een socket bijna geen resources, dus daar is Apache niet echt in het voordeel ten opzichte van PHP. En als je response maar snel genoeg is kun je heel veel verbindingen aan.

Het opstarten kan het beste via een cron als je die mogelijkheid hebt. Je kunt de PID (proces ID) wegschrijven in een bestandje en daarop controleren om te kijken of er nog een oude instantie draait. Dat is in ieder geval een courante linux methode om dit te checken. Elke minuut de cron laten draaien en als het proces crasht, dan zit je nooit meer dan een minuut zonder.

[ Voor 2% gewijzigd door DexterDee op 11-12-2009 12:56 . Reden: typo ]

[ZpAz]

edit. kom ik zo op terug.

[ Voor 93% gewijzigd door ZpAz op 11-12-2009 13:04 ]

[ZpAz]

Je idee is inderdaad wel goed. En als ik dan geen verbinding dmv php sockets kan opzetten. Dan kan ik het alsnog zo doen dat er een script is wat altijd draait wat de verbinding met de db in stand houd (dus dmv de cron en process id aanhouden). En deze zet de wijzigingen dan in de mem-cache, waar de gebruikers het dan weer uithalen.

[DexterDee]

Uiteraard opent een apart proces weer een poort naar allerlei alternatieven, zoals je er zelf een van beschrijft. Je kunt ook de geposte chat berichten naar dat ene proces sturen, zodat je daar zowel de binnenkomende als uitgaande berichten afhandelt. Dan wordt het meer een chat server idee. Je kunt dan ook direct een bericht van verstuurder naar ontvanger routeren zonder noodzaak van een database tabel.

[ZpAz]

DexterDee schreef op vrijdag 11 december 2009 @ 13:58:
Uiteraard opent een apart proces weer een poort naar allerlei alternatieven, zoals je er zelf een van beschrijft. Je kunt ook de geposte chat berichten naar dat ene proces sturen, zodat je daar zowel de binnenkomende als uitgaande berichten afhandelt. Dan wordt het meer een chat server idee. Je kunt dan ook direct een bericht van verstuurder naar ontvanger routeren zonder noodzaak van een database tabel.

Ja inderdaad, maar alles moet worden bijgehouden. Dus het moet toch ergens in weg worden geschreven.

[McVirusS]

Als je gaat pollen kan je met de poll request natuurlijk ook het ID van laatst ontvangen bericht doorgeven, dan krijg je alleen de nieuwe berichten binnen, scheelt weer dataverkeer en load (denk ik).

[ZpAz]

Ja inderdaad, maar zoiets zou er zo en zo natuurlijk bijkomen. Dit is meer van wat is de beste methode (voor zo ver beschikbaar met een standaard server configuratie).

[Art-X]

Ik heb voor de lol een compleet chatsysteem geschreven, (een clone van de world of warcraft in-game chat)..
kijk maar even op wowchat.artworkx.nl, als dit is wat je zoekt, wil ik je wel wat sourcecode geven.. het is gebaseerd op ajax (jquery) en php

[ZpAz]

Nee dank je, jij doet het dus precies zo zoals ik niet wil, en dat is pollen voor een nieuwe chat request. Toch bedankt voor het aanbod hoor. Maar ik ga het systeem zelf inelkaar zetten, zodat ik het precies naar mijn hand kan zetten.

Daarnaast stuur je elke keer de hele informatie door, enkel nieuwe informatie doorsturen zal al een verbeterpunt zijn. Alsmede niet direct de html teruggeven, maar de data in bijvoorbeeld Json formaat wat het weer wat kleiner maakt. (En meer portable).

[ Voor 35% gewijzigd door ZpAz op 11-12-2009 14:34 ]

[Art-X]

Geen probleem :-).. het klopt wat je zegt wat betreft pollen, maar als je geposte data wil pushen zul je dat naar alle clients moeten doen.. met meerdere clients is dat lastig, en kan uiteindelijk zelfs meer data en overhead opleveren. Ik was nog bezig om alleen wijzigingen door te sturen, en het laaste line id in de poll mee te sturen, zodat er niets terug (of false) teruggestuurd wordt als er geen nieuwe data is.

[ Voor 4% gewijzigd door Art-X op 11-12-2009 14:55 ]

[MueR]

Art-X schreef op vrijdag 11 december 2009 @ 14:52:
maar als je geposte data wil pushen zul je

..daarvoor niet met HTTP moeten werken. Dat is namelijk een pull protocol. De server stuurt alleen info richting client wanneer client daarom vraagt.

[ZpAz]

Als je dit topic doorleest zijn er dus wel manieren om het naar meerdere clients 'te pushen', en dat is ook waar ik voor ga. En zelf denk ik dat er daardoor (mits juist gedaan!) er minder overhead is dan elke seconde een nieuwe request sturen.

@Hierboven, gelijk. Maar als er geen andere mogelijkheid is, dan moet je roeien met de riemen die er zijn, en daarmee de best mogelijke (ook al kan hij 'creatief' zijn) oplossing gebruiken. En in dit geval is er geen andere mogelijkheid dan het http protocol gebruiken.

[ Voor 36% gewijzigd door ZpAz op 11-12-2009 15:00 ]

[MueR]

Ik heb zelf een tijdje terug een shoutbox moeten maken voor een klant. Daar liep ik tegen ongeveer hetzelfde aan. Hier was realtime checken echter niet zo'n struikelpunt, dus gebeurt dat nu iedere 20 seconden. Dat gaf echter wat veel requests op momenten dat het rustig was (midden in de nacht bijvoorbeeld) die niks deden. Nu werk ik vaak met Mootools, waar een request class in zit die je "standaard" de mogelijkheid geeft om een wisselende request interval te gebruiken. Met andere woorden, voor elke keer dat er geen resultaten zijn, kan je deze interval verhogen, misschien tot een maximum van 1 minuut voor jouw toepassing. Misschien is dat een idee voor je?

[DexterDee]

@MueR:
Voor een shoutbox is 20-60 seconden vertraging inderdaad geen ramp. Maar bij een Instant Message chat toepassing (let op het woord 'Instant' ) kan het erg vervelend zijn om zo lang te moeten wachten op response.
Verder zijn de technieken op basis van Comet redelijk mainstream, worden breed gebruikt en hebben bewezen goed te werken om de load aanmerkelijk te verminderen in vergelijking met polling. Dit topic is ook niet bedoeld om een oplossing voor een niet werkend probleem te zoeken, maar meer om tussen twee mogelijke werkende oplossingen de beste te kiezen. In mijn ogen is dat gezien de requirements van de TS een Comet oplossing, niet een gebaseerd op polling

[devhouse]

ik heb met adobe flash builder 4 in combinatie met stratus een mooie chat applicatie gemaakt. stratus is ontwikkeld door adobe.

Meer info: http://tv.adobe.com/watch...cation-with-adobe-stratus

[ZpAz]

@Dexteree inderdaad. Met IM wil je zo min mogelijk vertraging.En wanneer er niemand is worden er ook geen 'long polling' connecties opgezet En zou het script op de server aangepast kunnen worden om niet te kijken of er nieuwe berichten zijn, aangezien er toch niet zijn dan (als er niemand online is.)

[ Voor 255% gewijzigd door ZpAz op 11-12-2009 16:07 ]

[DexterDee]

Mocht je voor een daemon script gaan die permanent draait, dan heb ik nog een tip om het CPU gebuik binnen de perken te houden. Gebruik in je runloop een stream_select en vul een aantal microseconden in. Deze microseconden wacht het script op activiteit op de luisterende socket. Gedurende deze tijd geeft het script de CPU de mogelijkheid om andere processen tijd te geven. Dit is heel belangrijk, want als je dit niet doet gaat je script als een gek loopen en eet 100% van je CPU op. Het usleep commando doet hetzelfde, maar aangezien je toch socketactiviteit zal moeten lezen is de eerste een betere methode.

Aanbevolen aantal microseconden is afhankelijk van de zogenaamde 'maintenance taken' die je in je runloop moet uitvoeren, zoals het uitlezen van de database voor nieuwe berichten. Een getal onder de 50.000 is niet aan te raden voor de load (dat is 0,05 seconden). In jouw geval is 500.000 - 200.000 een goed getal denk ik, 2 tot 5 keer per seconde.

[Onbekend]

Ik heb ook voor zo'n probleem gehad en had ik hier ook een topic voor geopend:
[php] Hoe verzend je realtime data tussen twee gebruikers?
Uiteindelijk had ik de werking aardig goed d.m.v. sockets.
Helaas kwam ik tot de ontdekking dat de data niet altijd aankwam. Na lang zoeken heb ben ik er maar mee gestopt omdat ik voor mijn applicatie het niet kon veroorloven zoveel procent van de berichten gewoon niet te ontvangen.....

[ZpAz]

Dat ligt hem denk ik toch aan de implementatie (in ieder geval gedeeltelijk) DexterDee hierboven heeft een service draaien op een gelijke manier als ik in mijn hoofd heb, en bij hem draait het wel goed.

[ Voor 8% gewijzigd door ZpAz op 11-12-2009 19:41 ]

[Andre-85]

Je kan ook eens kijken hoe Google in dit doet met de chat in Gmail. Ik vind de chat functionaliteit heerlijk werken. Volgens mij loopt het ook allemaal via HTTP.

[ZpAz]

Okee, op de server kan ik wel sockets starten, maar enkel poort 80 staat volgens mij open, en die is uiteraard al in gebruik door apache. Ook staat er blijkbaar geen mem_cache support op de server.. zijn er nog creatieve oplossingen mogelijk om het mogelijk te maken dat er maar een enkele connectie is naar de database?

Zou het in een bestand kunnen dumpen via bijvoorbeeld Zend_Cache_File, zal dat een betere performance geven?

[ Voor 14% gewijzigd door ZpAz op 13-12-2009 18:18 ]

[Megamind]

Facebook chat werkt in princiepe ook zo, maar het is wel onbetrouwbaar (berichten die niet aankomen, erg lange vertragingen e.d.).

Wat ik zal heb gedaan is een flex/flash app geschreven in AS3 welke weer met een java server praat, die werkt als een soort proxy. Deze kan je echt in een paar regels schrijven en gecompileerd is die misschien maar 30-40kb, en laad dus in een zucht.

[ZpAz]

Ja, ik had ook al voorgesteld om een server applicatie te schrijven (of een bestaand systeem te gebruiken) -- maar helaas, de opdrachtgever kan niet extra software op de server installeren. En wil ook niet verhuizen naar een andere server. Dus helaasch dat is geen optie.

[Cartman!]

Dan moet de opdrachtgever maar accepteren dat hij een brak, niet schaalbaar, systeem gaat krijgen. Reken maar dat een hostingpartij ook niet blij is als je allemaal pollingscripts gaat draaien op een shared accountje.

[ZpAz]

Ja, daar was ik al bang voor. Nja, zal eerst kijken wat ik neer kan zetten, en als er later bijvoorbeeld mem_cache op de server geinstalleerd wordt, dan overstappen naar die betreffende caching methode.

Icm Zend is het dan enkel de naam van de classe aanpassen, aangezien de aan te roepen methods toch hetzelfde zijn. ZF

[Cartman!]

memcached op een shared account? Dan kan iedereen op de server jouw cache inlezen, dat lijkt me niet echt wenselijk.

[Verwijderd]

python pakken met epoll. Dat is de oplossing die je zoekt.

[ZpAz]

Cartman! schreef op maandag 14 december 2009 @ 10:50:
memcached op een shared account? Dan kan iedereen op de server jouw cache inlezen, dat lijkt me niet echt wenselijk.

Je hebt gelijk.. nja.. dan maar in een bestand schrijven. Dat was zo en zo al de enige optie, dusja.

@hierboven, de meeste poorten zijn dichtgetimmerd, sockets zullen dus niet veel helpen helaas.

[ Voor 12% gewijzigd door ZpAz op 14-12-2009 11:48 ]

[eghie]

ach, je kan ook encrypted in memcache opslaan. Al hoewel, misschien wordt het dan niet meer bruikbaar, maar het zou kunnen. Je zou het eens kunnen testen met (http://phpseclib.sourceforge.net/). Gewoon een fatsoenlijke serialize functie maken, die dat soort dingen afhandeld.

Op veel shared hosting servers zijn ook de sessie bestanden van een ander te lezen. Een goede hoster zet dit dicht, maar dat wordt niet vaak gedaan. Heeft te maken met hoe PHP is geïmplementeerd en hoe ze de gebruikers/groepen structuur hebben ingedeeld.

Je zou orbited (http://orbited.org/wiki/TCPSocket) met TCPSocket kunnen gebruiken, maar dan moet de hoster ook dingen installeren. Je zou eventueel orbited ergens anders kunnen hosten.

[Gomez12]

ZpAz schreef op maandag 14 december 2009 @ 11:47:
[...]


Je hebt gelijk.. nja.. dan maar in een bestand schrijven. Dat was zo en zo al de enige optie, dusja.

@hierboven, de meeste poorten zijn dichtgetimmerd, sockets zullen dus niet veel helpen helaas.

Dan zou ik toch eerder voor een fatsoenlijke dbase ( dus geen mysql met table locking ) gaan dan voor een bestand, je hebt iets meer overhead maar veel minder lockingsproblemen.

Maarja, ik zou zelf ook eerst eens met de klant om tafel gaan of hij niet gewoon over wil stappen naar andere hosting.
Zolang jij niet voor 10 euro per uur werkt is dat veelal goedkoper dan dat jij x uur bezig bent met extra workarounds om iets met veel pijn en moeite te maken wat eigenlijk gewoon niet geschikt is hiervoor.

Je uren gaan namelijk hard als je het moet omrekenen naar een verschil van 10 euro per maand ( 50 euro per uur is gewoon 5 maanden hosting per uur )

[ZpAz]

Ja inderdaad, nja de klant wil niet verhuizen. Hij zit al geruime tijd bij deze hosting met meerdere projecten. En wil dus niet verkassen naar een andere hosting. De hosting daarintegen wil niets aan de serverconfiguratie veranderen. Dusja, dan kan je er weinig aan doen.

Heb hem al aanbevolen wel te verkassen (in ieder geval voor dit project) maar goed.

Een andere dbase is dan ook geen optie, aangezien, jawel.. dat er niet op staat

Ik probeer dus echt de maximale performance te krijgen met alle limitien die zijn opgeworpen. En de meeste creatieve ideeen van mij en hier blijken tot nu toe niet mogelijk te zijn.

Dus dan ga ik maar op file-caching over voor de clients. Mocht het dan de 'spuigaten' uitlopen later. Dan kan dat cache mechanisme altijd nog vervangen voor mem_cache oid.

[DexterDee]

Met een beetje geluk kun je de ingebouwde RAMdisk gebruiken van Linux. Die is standaard toegankelijk voor alle gebruikers, dus ook apache

Kijk of je op de volgende locatie files kunt aanmaken:
/dev/shm

Dit is een tempfs filesystem mount die in het geheugen in plaats van op harddisk staat. File operaties gaan hier enorm snel op, zelf getest op 10.000+ operaties per seconde.

Er is zelfs nog een betere optie die ik zelf ook in gebruik heb in mijn projecten, maar dat vereist wel dat de sqlite extensie in PHP is geactiveerd. Je kunt namelijk op de ramdisk een sqlite database zetten en als cache gebruiken. Je profiteert dan van de (vrijwel) volledige SQL2000 featureset om data te manipuleren en de snelheid is fenomenaal. Op mijn laptop haal ik met een random primary key query een performance van rond de 33.000 queries per seconde op een tabel met een paar duizend records. Let wel op dat je in de sqlite settings van de database de temporary storage ook op /dev/shm zet en de overige waardes een beetje tweakt.

[Gomez12]

??? Waarom een dbase op een ramdisk zetten ???

Beetje DB blijft gewoon in het geheugen hoor.

Je ramdisk biedt alleen maar extra risico als je shared hoster besluit te rebooten?

Kijk, het zal allemaal best wel werken hoor. Maar het komt een klein beetje erg houtje touwtje over en ik zie de toegevoegde waarde niet echt, ik zie alleen een ramp als er iets niet helemaal 100% loopt, of als je iets meer dan 10 mensen tegelijk op je site krijgt

[ Voor 42% gewijzigd door Gomez12 op 16-12-2009 11:04 ]

[DexterDee]

Gomez12 schreef op woensdag 16 december 2009 @ 10:58:
??? Waarom een dbase op een ramdisk zetten ???

Beetje DB blijft gewoon in het geheugen hoor.

Je ramdisk biedt alleen maar extra risico als je shared hoster besluit te rebooten?

Kijk, het zal allemaal best wel werken hoor. Maar het komt een klein beetje erg houtje touwtje over en ik zie de toegevoegde waarde niet echt, ik zie alleen een ramp als er iets niet helemaal 100% loopt, of als je iets meer dan 10 mensen tegelijk op je site krijgt

Ik denk niet dat je het snapt.

Ten eerste dient dit alleen als cache, niet als permanente opslag. Een reboot is dus helemaal niet erg, omdat de cache dan gewoon opnieuw opgebouwd wordt. Je permanente dataopslag zit heel ergens anders.

Ten tweede, je hebt geen network latency naar je database server, wat de performance ten goede komt van je cache

Ten derde, door de extreem snelle random IO van een ramdisk kun je JUIST ervoor zorgen dat je veel concurrent gebruikers kan bedienen

Ten vierde, ik heb dit soort opstellingen uitgebreid getest en alhoewel ze niet de flexibiliteit bieden van een distributiemodel zoals Memcache is het qua performance wel verreweg het beste. Het performt zelfs significant beter dan een memory tabel in MySQL, die bovendien grote nadelen kent met betrekking tot het in de perken houden van je geheugengebruik (het niet vrijgeven van geheugen als een record weggegooid wordt, c.q. hergebruiken van primary keys)

[Frash]

Had Sqlite echter geen concurrency problemen?

[ Voor 94% gewijzigd door Frash op 16-12-2009 12:05 ]

[DexterDee]

Frash schreef op woensdag 16 december 2009 @ 12:05:
Had Sqlite echter geen concurrency problemen?

De sqlite PHP extensie is standaard gecompiled met de --enable-threadsafe vlag. Zolang je niet heftig op atomic transactions leunt (iets dat met een cache meestal niet het geval is) kan er weinig misgaan. Ik heb deze opstelling op drie webservers staan in een loadbalancing setup met 200+ (echte!) concurrent gebruikers en dit draait al een hele tijd als een zonnetje.

[ZpAz]

Ik zal eens kijken, bedankt voor de tip in ieder geval!

[Frash]

Twisted wordt trouwens ook nog wel eens gebruikt, onder andere door Tweetdeck en Omegle. Schijnt goed te schalen.