[PHP] Hoe het beste server-sent events te implementeren?

[Sméagol]

Ik probeer PHP + MySQL te leren zodat ik zowel de frontend and de backend van een site kan maken. Ik ben nu bezig met een soort shoutbox of comment achtige applicatie, de simpele sql queries lukken prima, ajax werkt ook, maar nou lijkt het me ideaal om server sent events te gebruiken om automatisch nieuw geplaatste posts te pushen. Hier gaat ’t mis. Ik krijg ’t enigszins werkend, Maar de browser wordt erg unresponsive. In m’n enigszins werkende shoutbox applicatie gaat ’t mis als ik met meer dan 2 browsers werk, en sowieso duurt ’t een halve minuut voordat ze daadwerkelijk de stream gevonden hebben. Dus om te kijken waar ’t probleem zat heb ik een simpelere test stream en html file gemaakt:

PHP:

<?php
  header("Content-Type: text/event-stream");
  header("Cache-Control: no-cache");
  
  $x = 0;
  
  while (true)
  {
    sleep(1);
    
    echo "id: {$x}" . PHP_EOL;
    echo "data: " . date("H:i:s") . PHP_EOL;
    echo PHP_EOL;
    $x++;
    flush();
  }
?>

De html file doet geen bijzondere dingen verder, maar hier’s de javascript voor ’t geval dat:

JavaScript:

      var source = new EventSource("test_stream.php");
    
      source.onmessage = function(event)
      {
        console.log(event.data); // debug
      
        document.getElementById("stream").innerHTML = event.data;
      };

2 dingen:

1] De sleep() functie, zorgt er voor dat de code heel anders behandelt wordt. Als ik ’m eruit sloop, dan reageert ie zoals verwacht, ik krijg een stortvloed aan events, waardoor de browser dus unresponsive raakt. Als ik ’m echter toevoeg, dan lijkt ie unresponsive (en dat is waarom ik ’m er aanvankelijk uitgesloopt heb), maar na verder onderzoek m.b.v de dev tools, blijkt dat er om de 5 minuten (precies) in 1 keer alle events van die afgelopen 5 minuten tevoorschijn komen. ik snap niet hoe de sleep() functie voor dit verschil zorgt, en wat er op de achtergrond precies gebeurt. Zou ik naar PHP’s output buffer functies moeten kijken om dit goed werkend te krijgen? Is ’t iets anders? De verwachting was dat ie simpelweg om de seconde een nieuwe event fired, en dat ik dus in de browser elke seconde een nieuwe tijd te zien krijg, en niet om de 5 minuten.

2] ik zou ook graag willen weten hoe ik ’t beste variables in de stream kan verwerken. Om het shoutbox voorbeeld te nemen: in m’n huidige code kijkt de stream zelf in een externe file wat de laatste post is. Die externe file bevat niks anders dan de id van de laatste post. Maar omdat die stream dus niet echt werkt zoals verwacht met de sleep() functie, gebruik ik ’m zonder, maar dan wordt die file dus constant geopend, wat er (volgens mij) dus voor zorgt dat dit niet werkt met meer dan 2 connecties. Iemand een suggestie hoe ik de stream het beste op de hoogte kan brengen van b.v. nieuwe posts?

Als ik google, kan ik niet erg veel vinden op dit gebied wat dieper in gaat op de server-side kant van het verhaal, dus geen idee wat ik fout doe, of hoe ’t hoort. Als iemand mij op mijn fouten kan wijzen dan graag.

[NMe]

Waarom doe je dit überhaupt niet met polling?

[Sméagol]

Dat zou inderdaad waarschijnlijk makkelijker zijn (en ik had zo’n vraag kunnen verwachten). Ik denk dat het antwoord iets van “optimalisatie” is. In theorie zou dit de meest geschikte oplossing moeten zijn voor zo’n soort situatie. 2 gebruikers zijn online, gebruiker 2 maakt een nieuwe post. Dan kan de server toch doorgeven dat die post er is, zonder dat gebruiker 1 constant de server hoeft lastig te vallen om te kijken of er al een post is? Het kwam mij natuurlijker over in alle opties die ik tegenkwam. Dit was ook de algemene conclusie die getrokken werd op de sites die ik tegenkwam op dit onderwerp. Het beste artikel dat ik denk ik tegenkwam was deze. Om maar de inleiding te quoten:

But to really understand Server-Sent Events, we need to understand the limitations of its AJAX predecessors, which includes:

Polling is a traditional technique used by the vast majority of AJAX applications. The basic idea is that the application repeatedly polls a server for data. If you're familiar with the HTTP protocol, you know that fetching data revolves around a request/response format. The client makes a request and waits for the server to respond with data. If none is available, an empty response is returned. So what's the big deal with polling? Extra polling creates greater HTTP overhead.

Long polling (Hanging GET / COMET) is a slight variation on polling. In long polling, if the server does not have data available, the server holds the request open until new data is made available. Hence, this technique is often referred to as a "Hanging GET". When information becomes available, the server responds, closes the connection, and the process is repeated. The effect is that the server is constantly responding with new data as it becomes available. The shortcoming is that the implementation of such a procedure typically involves hacks such as appending script tags to an 'infinite' iframe. We can do better than hacks!

Server-Sent Events on the other hand, have been designed from the ground up to be efficient. When communicating using SSEs, a server can push data to your app whenever it wants, without the need to make an initial request. In other words, updates can be streamed from server to client as they happen. SSEs open a single unidirectional channel between server and client.

Een andere oplossing zou zijn om simpelweg die while loop achterwege te laten. Wat je dan krijgt is een statische file, en de gebruikers verliezen constant de connectie met de stream (want er is geen stream), om die vervolgens weer automatisch aan te maken. Maar ook dit gaat tegen de gedachte van een stream in.

Nogmaals, SSE lijkt mij de ideale methode voor deze situatie, en ik ben dus vastbesloten dit te gaan gebruiken, maar ik lijk te weinig kennis te hebben om het goed werkend te krijgen. Als ik puur naar de W3 HTML5 specs kijk, wordt ik er ook niet wijzer van, die vertellen me niet meer dan alle andere artikelen die ik ben tegen gekomen, zoals die hierboven.. Dus ik vraag me af of ik me moet indiepen op b.v. het http protocol zelf, of bepaalde functies van PHP. Ik zie zo gauw niet in welke richting ik verder moet kijken voor dit specifieke probleem.

[creator1988]

Tah dah? http://code.google.com/p/phpwebsocket/

[NMe]

Sméagol schreef op woensdag 01 augustus 2012 @ 13:35:
Dat zou inderdaad waarschijnlijk makkelijker zijn (en ik had zo’n vraag kunnen verwachten). Ik denk dat het antwoord iets van “optimalisatie” is. In theorie zou dit de meest geschikte oplossing moeten zijn voor zo’n soort situatie. 2 gebruikers zijn online, gebruiker 2 maakt een nieuwe post. Dan kan de server toch doorgeven dat die post er is, zonder dat gebruiker 1 constant de server hoeft lastig te vallen om te kijken of er al een post is? Het kwam mij natuurlijker over in alle opties die ik tegenkwam. Dit was ook de algemene conclusie die getrokken werd op de sites die ik tegenkwam op dit onderwerp.

Als PHP niet zo'n ramp zou zijn in het continu blijven draaien had je misschien gelijk. PHP staat alleen al bol van de memory leaks. Daarnaast is pollen echt niet zo veel zwaarder. In tegenstelling tot af en toe een requestje op de server af te sturen zit je nu een verbinding open te houden. Hoe is dit precies een voordeel?

[Cartman!]

PHP is er simpelweg niet voor gemaakt om een verbinding open te houden. Als het om een kleine site gaat hoeft polling echt geen probleem te zijn, zeker niet als het om enkele gebruikers gaat die elke paar seconden een check doen. Die call zelf kun je natuurlijk goed cachen.

Als je echt 'push' wilt kun je bijv. kijken naar Node.JS of APE Server maar dat klinkt als overkill voor wat jij wilt.

[Sméagol]

Ik kreeg al hier en daar te horen dat PHP daar niet ’t meest geschikt voor was. Zelf ben ik meer bekend met Java, en ik zou daar zelf waarschijnlijk de voorkeur geven om dat voor persoonlijke projecten te gebruiken, maar dat neemt niet weg dat ’t handig is om PHP te leren (m.b.t. de arbeidsmarkt). Ik kwam Node.js inderdaad ook al tegen, maar ik denk niet dat ’t handig is om me daar tussendoor ook nog ’ns in te verdiepen, dus ik wacht daar nog even mee. Ik heb ook zo ’t idee dat java servers, of in dit geval node.js servers, niet bepaald standaard features zijn bij webhosts, wat ook kan meewegen wanneer ik eindelijk een persoonlijke site online zet.

In de tussentijd denk ik dat ik maar ga pollen, en daarna kijk ik naar node.js. Is Java ook beter geschikt voor dit soort dingen?

[NMe]

Ook met Java zou ik gewoon gaan pollen. Wat is volgens jou het voordeel van een verbinding open houden ten opzichte van het doen van een request om de 10 seconden? 't Is niet alsof de overhead nou zó veel groter is dat het problemen oplevert in vergelijking met de andere methode.

HTTP is stateless en as such is polling een veel logischere methode dan het openhouden van een verbinding.

[Barryvdh]

Voor je 2de punt, in plaats van de file te openen, zou je ook kunnen kijken naar de tijd dat het bestand aangepast is (http://php.net/manual/en/function.filemtime.php)

[Sméagol]

NMe schreef op woensdag 01 augustus 2012 @ 16:15:
Ook met Java zou ik gewoon gaan pollen. Wat is volgens jou het voordeel van een verbinding open houden ten opzichte van het doen van een request om de 10 seconden? 't Is niet alsof de overhead nou zó veel groter is dat het problemen oplevert in vergelijking met de andere methode.

HTTP is stateless en as such is polling een veel logischere methode dan het openhouden van een verbinding.

Ik kreeg het idee dat dat het efficiënst was. Als dat niet zo is mag je me dat zeggen. Ik weet de getallen niet, maar het kwam logischer op me over dat als de server 1 keer relevante data stuurt dat dit zowel voor de server als de client efficiënter is dan dat de client om de zoveel tijd gaat checken of er übrhaupt relevante data is. Het maakt voor een simpele shoutbox op een persoonlijke site misschien inderdaad niks uit, maar ik probeer zo algemeen mogelijk te coden, en doe dit graag zo “net” mogelijk. Ik had het idee dat SSE hiervoor gewoon het geschikts is, dus dat wou ik graag gebruiken. Verder moet ’t scalable zijn, als ik met m’n simpele site klaar ben wil ik graag iets groters proberen, zoals een forum (maar zover zijn we nog niet).

PHP lijkt ’t probleem te zijn als ik ’t zo hoor, niet mijn gekozen oplossing.

[ Voor 22% gewijzigd door Sméagol op 01-08-2012 16:32 ]

[NMe]

Sméagol schreef op woensdag 01 augustus 2012 @ 16:29:
Ik kreeg het idee dat dat het efficiënst was. Als dat niet zo is mag je me dat zeggen. Ik weet de getallen niet, maar het kwam logischer op me over dat als de server 1 keer relevante data stuurt dat dit zowel voor de server als de client efficiënter is dan dat de client om de zoveel tijd gaat checken of er übrhaupt relevante data is.

Totdat je 100 users hebt die tegelijkertijd allemaal een verbinding open aan het houden zijn?

PHP lijkt ’t probleem te zijn als ik ’t zo hoor, niet mijn gekozen oplossing.

Ook je gekozen oplossing is absoluut niet gangbaar in webdevelopment. Ik heb er ook geen cijfers voor maar ik betwijfel dat je hiermee de performancewinst krijgt die je verwacht te krijgen, zelfs in een systeem dat er wél voor bedoeld is.

[Sméagol]

NMe schreef op woensdag 01 augustus 2012 @ 16:35:
[...]

Totdat je 100 users hebt die tegelijkertijd allemaal een verbinding open aan het houden zijn?

Nogmaals, het leek me de beste oplossing. Ik ging ging uit van een feature: "Goh, het zou leuk zijn als nieuw posts in een shout box (of nieuwe comments onder een artikel, etc) automatisch verschenen". Dit is niet gek om te willen. Ik ging dus op zoek naar verschillende push methodes, en kwam op SSE uit, en daar ging ik dus mee aan de slag. Het werkte niet helemaal naar behoren, dus kwam ik hier.. Ik wou weten wat ik fout deed en waarom. Ik weet wat de alternatieven zijn, dus daar kwam ik niet voor, tenzij SSE dus niet de oplossing blijkt te zijn.

Als je zegt dat 100 users die, zeg, om de seconde een nieuwe request sturen, beter is dan 100 users die een open verbinding hebben, maar alleen data gestuurd krijgen wanneer het nodig is, dan hoor ik het graag, en ook waarom, of een link naar een artikel dat me dat uitlegt, want daar leer ik weer van. Je stelt die vraag namenlijk wel, maar ik weet ’t het antwoord niet, wat mij wel duidelijk leek eigenlijk.

[NMe]

Elke seconde pollen voor iets simpels als een shoutbox is sowieso niet handig. Dat wil je elke 15 seconden doen, of misschien elke 10, dat is meer dan genoeg voor een shoutbox. Sterker nog, dat is precies de reden waarom pollen zo veel minder zwaar is dan continu een verbinding open houden: gemiddeld heb je als server veel minder mensen tegelijk aan je hoofd zeuren.

[Sméagol]

En dus is de conclusie die ik moet trekken: open verbindingen zijn slecht, ongeacht de hoeveelheid data die daar wel of niet doorheen loopt", klopt dat? Want dan ga ik daar ’ns verder over nadenken.

[NMe]

Open verbindingen schalen in elk geval erg slecht. Afhankelijk van de situatie kan het alsnog best de beste keus zijn, maar ik heb ze zelf nog nooit nodig gehad.

Vergeet verder ook niet dat de opzet die je hierboven had (volgens mij) betekent dat je een proces hebt draaien per gebruiker, allemaal met een oneindige loop erin.

[Zeebonk]

Ligt denk ik een beetje aan de interactie snelheid die je van de app verwacht. Als je deze bijna zo snel als een normale chat wilt hebben kan push best wel voordeel hebben. Stel je hebt 100 kijkers die af en toe een berichtje sturen dan moet je bij pull per client een request per seconden doen om iets van interactiviteit te kunnen bieden. Terwijl bij pull je dan 100 connecties open houd en de nieuwe data direct kan verspreiden. Is interactiviteit niet heel belangrijk dan kan je zoals nme al zei 1x in de zoveel seconden de nieuwe data opvragen, dan blijft de load minimaal.

(Geen rekening gehouden met gebruikte programmeertalen enzo)

[ Voor 5% gewijzigd door Zeebonk op 01-08-2012 17:34 ]

[creator1988]

Event loop based apps (node.js bijvoorbeeld) schalen prima met concurrent connections. PHP+Apache, 99% van de Java implementaties en .NET niet vanwege thread overhead.

[Cartman!]

FYI: Node.JS is JavaScript, geen Java. Juist webservers als Node en APE zijn gemaakt om heel veel concurrent openstaande verbindingen te hebben itt. Apache.

[creator1988]

Cartman! schreef op woensdag 01 augustus 2012 @ 19:52:
FYI: Node.JS is JavaScript, geen Java. Juist webservers als Node en APE zijn gemaakt om heel veel concurrent openstaande verbindingen te hebben itt. Apache.

Volgens mij beweer ik dat ook nergens?

[NMe]

Volgens mij beweert Cartman ook nergens dat hij dat tegen jou zegt? Zie de laatste zin van de eerste reactie van de topicstarter na Cartman's vorige post.

[Cartman!]

Ik had het niet tegen jou idd maar gewoon een algemene opmerking om even duidelijk te maken dat de bekendere servers voor dit soort toepassingen werken met (serverside) javascript. Het is daarom relatief makkelijk te leren maar je moet vooral nadenken over het non-blocking maken van je calls. Uit de reactie van de TS maakte ik vanwege de zinsconstructie op dat hij het idee heeft dat Node.JS een Java server is.

[BtM909]

NMe schreef op woensdag 01 augustus 2012 @ 16:15:
Ook met Java zou ik gewoon gaan pollen. Wat is volgens jou het voordeel van een verbinding open houden ten opzichte van het doen van een request om de 10 seconden? 't Is niet alsof de overhead nou zó veel groter is dat het problemen oplevert in vergelijking met de andere methode.

Mwa, tegenwoordig is schalen geen issue en wil je juist geen polling hebben als je gaat schalen.
Kijk bijvoorbeeld alleen al naar producten ala http://www.frozenmountain.com/websync/.

HTTP is stateless en as such is polling een veel logischere methode dan het openhouden van een verbinding.

HTTP kan ook gewoon connecties openhouden

[NMe]

BtM909 schreef op donderdag 02 augustus 2012 @ 12:23:
[...]

Mwa, tegenwoordig is schalen geen issue en wil je juist geen polling hebben als je gaat schalen.
Kijk bijvoorbeeld alleen al naar producten ala http://www.frozenmountain.com/websync/.

Je wil daar dan wel je serversoftware op aanpassen en sowieso de juiste tools gebruiken. PHP is er absoluut niet geschikt voor, en Apache in mindere mate ook niet.

HTTP kan ook gewoon connecties openhouden

Je kan ook een ei bakken op de motorkap van je auto, maar of dat nou een goed idee is...? Natuurlijk kan HTTP connecties openhouden, maar dat maakt het nog niet direct een goed idee in dit soort dingen te pas en te onpas toe te passen. Voor een shoutbox is het domweg overkill.

[BtM909]

NMe schreef op donderdag 02 augustus 2012 @ 12:31:
[...]

Je wil daar dan wel je serversoftware op aanpassen en sowieso de juiste tools gebruiken. PHP is er absoluut niet geschikt voor, en Apache in mindere mate ook niet.

Nee dat klopt... Had het ook niet over PHP (of apache)

[...]

Je kan ook een ei bakken op de motorkap van je auto, maar of dat nou een goed idee is...? Natuurlijk kan HTTP connecties openhouden, maar dat maakt het nog niet direct een goed idee in dit soort dingen te pas en te onpas toe te passen. Voor een shoutbox is het domweg overkill.

Ik heb niet echt het idee dat we hier over een eitje op een motorkap hebben hoor

Wikipedia: HTTP persistent connection

[Sméagol]

Thanks guys. Ik had al een vermoeden dat PHP niet zo geschikt was voor dit, van een enkele opmerking die ik tegenkwam in de gevonden artikelen, maar ik had geen idee dat ’t zo'n probleem was. Voor nou heb ik ’t met polling opgelost, zodra de basis van een site er is, ga ik ’ns kijken naar die Node.js, ’t klinkt goed. Maar ’t ziet er naar uit dat ik dan ook toch eindelijk aan Cygwin moet om ’t te compilen (want de installer installeert alleen op C).. Ohhh.

En:

Cartman! schreef op woensdag 01 augustus 2012 @ 19:52:
FYI: Node.JS is JavaScript, geen Java. Juist webservers als Node en APE zijn gemaakt om heel veel concurrent openstaande verbindingen te hebben itt. Apache.

Sméagol schreef op woensdag 01 augustus 2012 @ 16:10:
[..]
In de tussentijd denk ik dat ik maar ga pollen, en daarna kijk ik naar node.js. Is Java ook beter geschikt voor dit soort dingen?

Ik weet dat JS en Java 2 verschillende dingen zijn, ik had ’t dan ook daadwerkelijk over servlets . In een grijs verleden op school daar nog iets mee gedaan, maar da’s niet blijven hangen, bovendien was dat ver voor HTML 5 en zo.

[creator1988]

Sméagol schreef op donderdag 02 augustus 2012 @ 14:43:
Thanks guys. Ik had al een vermoeden dat PHP niet zo geschikt was voor dit, van een enkele opmerking die ik tegenkwam in de gevonden artikelen, maar ik had geen idee dat ’t zo'n probleem was. Voor nou heb ik ’t met polling opgelost, zodra de basis van een site er is, ga ik ’ns kijken naar die Node.js, ’t klinkt goed. Maar ’t ziet er naar uit dat ik dan ook toch eindelijk aan Cygwin moet om ’t te compilen (want de installer installeert alleen op C).. Ohhh.

Node.js is er gewoon native voor Windows sinds 0.6.x; ontwikkeld door een collega van mij, dus je hoeft geen Cygwin. Sterker nog, Microsoft draait het zelfs op Windows Azure etc. Of draai het zonder local install via http://c9.io (dat maak ik dus).

[Cartman!]

Ah, prima. Zoals ik zei was t me niet 100% duidelijk of je dat bedoelde. Het zou imo zonde zijn om een platform over het hoofd te zien vanwege een klein misverstand. Node.JS is namelijk best wel leuk om mee te spelen.

[418O2]

Wat facebook doet is het volgende, zij sturen een pollrequest en de server reageert pas als er wat is, of na 1 minuut. Hij houdt dus de verbinding open tot er wat nieuws is, of de timeout verloopt.

JavaScript:

SyncChat : function(doRepeat) {
            return;
                var self = this;
                $.ajax({
                    context: this,
                    url:"chatHandler.php",
                    dataType: "json",
                    data:  {
                        action: "getChat",              
                        sessionId: this.sessionId,
                        lastReceived:  this.options.lastReceived
                    },
                    success : $.proxy(function(data) {

                        });
                    }, this),
                    complete: $.proxy(function() { 
                                        if(doRepeat) { 
                                                var self = this; 
                                                setTimeout(function() { 
                                                        self.SyncChat(); 
                                                        }, 5000); 
                                         }; 
                                    }
                                , this),
                    timeout: 2000,
                    contentType: 'application/json'
                });
        },

zo heb ik het opgelost (dit is een methode uit een jQuery widget dat ik heb geschreven voor een chatbox).

[ Voor 68% gewijzigd door 418O2 op 02-08-2012 15:26 ]

[alienfruit]

Ik heb dat node.js (en LESS) nog nooit fatsoenlijk aan de praat gekregen onder Windows. Het werkt perfect onder OSX.

[418O2]

Node is wat lastig, voor LESS kan je WinLESS gebruiken, of de JS parser natuurlijk.

[curvemod]

418O2 schreef op donderdag 02 augustus 2012 @ 15:25:
Wat facebook doet is het volgende, zij sturen een pollrequest en de server reageert pas als er wat is, of na 1 minuut. Hij houdt dus de verbinding open tot er wat nieuws is, of de timeout verloopt.

//Code

zo heb ik het opgelost (dit is een methode uit een jQuery widget dat ik heb geschreven voor een chatbox).

Je zou dit ook met websockets op kunnen lossen toch? Volgens mij is dit een typisch voorbeeld van "long polling", dat is wat cleaner met zoiets als Socket.IO? Of klets ik uit m'n nek?

[418O2]

jhuiting schreef op donderdag 02 augustus 2012 @ 15:44:
[...]

Je zou dit ook met websockets op kunnen lossen toch? Volgens mij is dit een typisch voorbeeld van "long polling", dat is wat cleaner met zoiets als Socket.IO? Of klets ik uit m'n nek?

Nee, daar zijn websockets voor gemaakt, alleen nog niet breed genoeg supported (html5 he).

[curvemod]

418O2 schreef op donderdag 02 augustus 2012 @ 15:48:
[...]
Nee, daar zijn websockets voor gemaakt, alleen nog niet breed genoeg supported (html5 he).

Maar die support lost Socket.IO toch voor je op? Volgens mij werkt dat zelfs in IE6, met een of andere ranzige Flash-based constructie. Of zitten daar weer andere nadelen aan vast?

[Cartman!]

@Catch22: dat is dus 'gewoon' een framework met eigen webserver die dat voor hun regelt. Reken er maar niet op dat het een Apache webserver is met PHP.

@jhuiting Socket.IO kan dat voor je oplossen ja, klopt.

[Apache]

NMe schreef op woensdag 01 augustus 2012 @ 16:15:
Ook met Java zou ik gewoon gaan pollen. Wat is volgens jou het voordeel van een verbinding open houden ten opzichte van het doen van een request om de 10 seconden? 't Is niet alsof de overhead nou zó veel groter is dat het problemen oplevert in vergelijking met de andere methode.

HTTP is stateless en as such is polling een veel logischere methode dan het openhouden van een verbinding.

Met java zou ik zoiets gebruiken: http://wiki.eclipse.org/J...ns#Suspend_Resume_Pattern

In de servlet 3 spec zit hier sowieso ook support voor ingebakken: http://www.javaworld.com/...-2009/jw-02-servlet3.html

We gebruiken hier een native weblogic implementatie, al sinds wls 10, dus pre servlet 3, voor een hoop flex clients om ze op de hoogte te brengen wanneer een requested rapport klaar is bvb of een batchjob klaar is met runnen, schaalt uitermate goed.