Long polling serverside implementatie

[EddoH]

Even vooraf: ik ben van origine geen web programmeur en daarom ook niet helemaal op de hoogte van de latest & greatest web technologiën. Vandaar dat ik deze vraag even bij jullie neerleg, om zo advies en ideeën op te doen.

Ik ben bezig met een project waarbij een flink aantal clients (say, >10.000, maar in principe moet het oneindig schaalbaar worden) d.m.v een HTTP request bij een server moeten vragen of zij een bepaalde actie moeten
uitvoeren. Om de delay zo klein mogelijk te houden en de server niet te overbelasten met een constante HTTP requests, heb ik bedacht om de HTTP request 'open' te houden totdat er daadwerkelijk vanaf de server data is om terug te sturen. Nu blijkt dat meerdere mensen dit idee al hadden en het voor zover ik weet long-polling hebben genoemd

Nu zijn er bij mij wat onduidelijkheden over de server implementatie hiervan, en hoe dit in de praktijk gedaan wordt. De onduidelijkheden zitten voornamelijk in het feit hoe de server de requests gaat afhandelen. Bij een standaard Apache+PHP installatie wordt er voor elke request een nieuwe thread gestart. Als er dus 1000 clients een HTTP request open hebben staan, draaien er dus 1000 threads. Geef al deze threads een stack van 4MB + wat overhead, en bij elkaar ben je zo 5GB aan geheugen kwijt. Klopt dit, of zie ik hier iets over het hoofd? Voor mijn gevoel is dit hartstikke inefficiënt, vooral omdat 99% van de requests de komende uren geen data gaan ontvangen, compleet idle zijn dus.

Je zou ook voor een webserver met een ander threading model (Nginx bijvoorbeeld?) welke niet voor elk request een aparte thread start. Echter is het mij niet helemaal duidelijk hoe Nginx andere requests gaat afhandelen als 1 request aan het blocken is (stel, even heel dom, we zetten een sleep() in een php script).
Gelet op het voorgaande zoek ik dus eigenlijk iets event-driven.

Kunnen jullie mij even wat schoppen in de goede richting geven v.w.b de common practices bij long-polling? Misschien overbodig, maar web-sockets etc hebben niet de voorkeur. Ook is de client een heel simpel embedded bordje en ondersteund bijvoorbeeld geen Java, .Net, of andere 'enterprisy' frameworks.

edit: Ik geloof dat ik zojuist het nut van Node.js heb ontdekt... Nog meer methoden om efficient long-polling toe te passen, behalve het helemaal zelf op de server te gaan implementeren in [insert taal]?

[ Voor 4% gewijzigd door EddoH op 03-06-2014 10:35 ]

[Badeend]

Heb je al gekeken naar websockets? In combinatie met bijvoorbeeld node.js een erg mooie oplossing voor zoiets.

[RobIII]

Badeend schreef op dinsdag 03 juni 2014 @ 10:26:
Heb je al gekeken naar websockets?

EddoH schreef op dinsdag 03 juni 2014 @ 09:53:
Misschien overbodig, maar web-sockets etc is geen optie

Waarom TS web-sockets geen optie vindt is een tweede en is de vraag "waarom" imho wel waard. Maar om web-sockets aan te dragen als oplossing terwijl expliciet in de topicstart staat dat 't geen optie is is weer een ander uiterste...

[Badeend]

Oh crap, helemaal dat zinnetje gemist

[EddoH]

Wat Roblll zegt dus

In den beginne wil ik het zo simpel en portable mogelijk houden, en zou wget op de client genoeg functionaliteit moeten bieden. Als websockets iets fundamenteels toevoegen kunnen we dat ook gebruiken, mits er een goede low-footprint implementatie in bijvoorbeeld C voor beschikbaar is.

[TheNephilim]

Apache is misschien wat lomp, ik denk dat je nginx + php-fpm al veel specialistischer kun inrichten en meer performance uit je clients haalt. Tenminste, ik maak uit je verhaal op dat je clients geen full-blown PC's zijn.

Voor proof-of-concept zou je misschien wat met http://pusher.com/ kunnen doen. De gratis account biedt genoeg ruimte voor development.

[EddoH]

Het probleem zit hem niet zozeer in de configuratie, als in de architectuur. Als er voor elk request een thread gemaakt wordt, kan ik tweaken wat ik wil, maar blijven er een x aantal threads gemaakt worden. Voor Nginx + PHP geldt dat ik voor zover ik kan zien geen blocking acties in een request kan doen, gezien ik dan de afhandeling van de andere requests ook tegenhoud. Dit ligt natuurlijk meer aan PHP dan aan Nginx, die zover ikweet wel event-based is.

Pusher ziet er leuk uit, maar sowieso niet geschikt voor onze clients.

[EgoH]

Met een java servlet/http server zoals jetty kan je vrij eenvoudig een efficient long polling mechanisme implementeren door middel van Continuations.
http://wiki.eclipse.org/Jetty/Feature/Continuations
Onderaan de pagina staan een aantal voorbeelden (zoals een chat applicatie).

Meeste complete frameworks zoals CometD maken tegenwoordig gebruik van websockets, met een long polling fallback indien websockets niet ondersteund zijn op de client. Aangezien je hele basic clients hebt is een framework misschien niet de beste keuze, omdat je geen client library hebt die je kan gebruiken.

Normale http requests met een jetty server implementatie zou je reletief snel werken moeten hebben als je wat ervaring hebt met java.

[EddoH]

Thanks, daar kan ik wat mee! Continuations is inderdaad precies wat ik zoek. CometD had ik zelf inderdaad ook gezien, maar zoals je zegt is dat geen optie op de clients die we ontwikkelen.

[EddoH]

For future reference: ik heb een werkend proof-of-concept in elkaar geflanst met Node.js. 1000-en HTTP requests open en minimale server belasting. Perfect dus. Ik had nooit gedacht Node.js te gaan gebruiken, maar voor dit soort toepassingen is het toch wel uitermate geschikt. Right tool for the job zullen we maar zeggen.

Gezien de simpelheid van deze setup prefereer ik dit boven een Jetty servlet.

[drm]

Als je dan toch de node hoek induikt is socket.io wel de moeite waard om te gebruiken / te onderzoeken.

[EddoH]

Niet echt, want de clients draaien geen Javascript

[drm]

Interessant Waarom dan HTTP?

[farlane]

drm schreef op dinsdag 03 juni 2014 @ 22:39:
Interessant Waarom dan HTTP?

Gemak waarmee aan de serverkant dingen gedaan kan worden methinks .... misschien handig ivm firewalls/proxies die ander verkeer blocken?

[Verwijderd]

farlane schreef op dinsdag 03 juni 2014 @ 23:59:
[...]

Gemak waarmee aan de serverkant dingen gedaan kan worden methinks .... misschien handig ivm firewalls/proxies die ander verkeer blocken?

Dat "gemak" blijkt wel weer uit de gebleken noodzaak voor TS om een topic te openen
Firewalls/proxies jazeker, en gemak aan de client ook.

Dus die clients hoeven alleen te weten óf ze een actie mogen uitvoeren, en jij hebt op de server een event die je kunt pushen? Waarom zou je dan niet zelf een simpel tcp/ip servertje (:80) in elkaar flansen die nog véél kleiner en lichter is dan node.js, en gewoon een regel pusht? Daarop kan de client dan actie ondernemen.

[EddoH]

Grotendeels wat farlane zegt.

- firewalls en proxies, denk ook aan clients die via 'exotische' gprs netwerken verbinding maken. Ervaring wijst uit dat HTTP het enige is wat nog een beetje betrouwbaar is, helemaal als er ook firewalls gebruikt worden die daadwerkelijk het verkeer inspecteren.
- de server hoeft niet licht en klein te zijn. Daarnaast moet er makkelijk gebruik worden gemaakt van databases en diverse andere server toepassingen, dit is makkelijker met een standaardoplossing.
- not-invented-here syndroom tegengaan.
- bestaande HTTP authenticatie API moet gebruikt worden.
- de clients kunnen al HTTP(S) requests uitvoeren, onnodig om voor dit geval weer een apart protocol te gaan implementeren.

[farlane]

Verwijderd schreef op woensdag 04 juni 2014 @ 00:05:
Dat "gemak" blijkt wel weer uit de gebleken noodzaak voor TS om een topic te openen

Jaja, en zelf een robuuste server maken die 10K+ clients kan onderhouden is kattepis? Daar kun je waarschijnlijk nog wel meer topics aan wijden. Om nog maar niet te spreken van alle libraries die je dan *niet* kunt gebruiken.

[Verwijderd]

farlane schreef op woensdag 04 juni 2014 @ 09:08:
[...]

Jaja, en zelf een robuuste server maken die 10K+ clients kan onderhouden is kattepis? Daar kun je waarschijnlijk nog wel meer topics aan wijden. Om nog maar niet te spreken van alle libraries die je dan *niet* kunt gebruiken.

Ja, zeker, en wie heeft het over libraries, maar de punten die TS noemt zijn absoluut doorslaggevend om bij http te blijven.

[begintmeta]

AFAIK (nsf) wordt voor dit soort dingen ook nog wel eens met Erlang gewerkt, misschien dat in de bestaande projecten (cowboy, mochiweb, yaws etc) als wat nuttigs te vinden is.

[EddoH]

Bedankt voor de tip.
Gezien in ons bedrijf in het geheel geen Erlang kennis aanwezig is, is dit niet een heel voor de hand liggende optie v.w.b onderhoudbaarheid. Tenzij het echt serieuze voordelen biedt ten opzichte van de genoemde opties.

[cytherea]

EddoH schreef op woensdag 04 juni 2014 @ 10:56:
Bedankt voor de tip.
Gezien in ons bedrijf in het geheel geen Erlang kennis aanwezig is, is dit niet een heel voor de hand liggende optie v.w.b onderhoudbaarheid. Tenzij het echt serieuze voordelen biedt ten opzichte van de genoemde opties.

Erlang is gebouwd voor heel veel connecties en is multithreaded by default. node.js is singlethreaded en schaalt dus uiteindelijk niet meer. Vooral als je veel berekeningen uit gaat voeren is node.js snel aan zijn eind. Alle connecties moeten wachten tot de berekening klaar is, dan krijg je een queue van wachtende IO en kom je in de problemen.

Erlang komt oorspronkelijk van Ericsson en wordt gebruikt voor telefooncentrales die per definitie met veel connecties te maken hebben. Whatsapp draait op erlang.

Verder heb je het over oneindig schaalbaar, dat bestaat niet. Je gaat altijd een keer tegen een limiet van wat dan ook aanlopen. Al is het maar dat het aantal machines op de aarde eindig zijn. Dus het is handiger om wat realistischer daarin te zijn.

[EddoH]

cytherea schreef op woensdag 04 juni 2014 @ 11:08:
[...]


Erlang is gebouwd voor heel veel connecties en is multithreaded by default. node.js is singlethreaded en schaalt dus uiteindelijk niet meer. Vooral als je veel berekeningen uit gaat voeren is node.js snel aan zijn eind. Alle connecties moeten wachten tot de berekening klaar is, dan krijg je een queue van wachtende IO en kom je in de problemen.

Als je m'n startpost even leest dan is juist de overhead die multithreaded oplossingen voor deze case bieden het probleem. Daarnaast gebeurt er juist heel weinig op de server, maar moeten er alleen heel veel connecties open staan. Een single-threaded event-driven aanpak is hier volgens mij veel efficienter (zoals in de praktijktests ook blijkt). Ik ben wel met je eens dat dit niet tot in den treure schaalbaar is.

Verder heb je het over oneindig schaalbaar, dat bestaat niet. Je gaat altijd een keer tegen een limiet van wat dan ook aanlopen. Al is het maar dat het aantal machines op de aarde eindig zijn. Dus het is handiger om wat realistischer daarin te zijn.

Verkeerde woordkeuze van mij inderdaad. Met 100.000 client shebben we de praktische limiet wel bereikt. Dat het aantal machines op aarde eindig is..tja... je kan het ook té letterlijk nemen

Ik denk dat je met Erlang zeker wel dit probleem heel goed kunt oplossen. Maar voor deze situatie zie ik nu geen meerwaarde.

[drm]

EddoH:
Grotendeels wat farlane zegt.

- firewalls en proxies, denk ook aan clients die via 'exotische' gprs netwerken verbinding maken. Ervaring wijst uit dat HTTP het enige is wat nog een beetje betrouwbaar is, helemaal als er ook firewalls gebruikt worden die daadwerkelijk het verkeer inspecteren.
- de server hoeft niet licht en klein te zijn. Daarnaast moet er makkelijk gebruik worden gemaakt van databases en diverse andere server toepassingen, dit is makkelijker met een standaardoplossing.
- not-invented-here syndroom tegengaan.
- bestaande HTTP authenticatie API moet gebruikt worden.
- de clients kunnen al HTTP(S) requests uitvoeren, onnodig om voor dit geval weer een apart protocol te gaan implementeren.

Lijkt me opzich allemaal terecht hoor, maar als je heel moeilijk moet gaan doen omdat je HTTP gebruikt staat HTTP misschien ook wel ter discussie. Ik ken de achtergrond van je vraag natuurlijk niet, dus ik vroeg het vooral om een idee bij je overwegingen te hebben

Verder doe ik natuurlijk domweg de aanname dat HTTP + Client al gauw "browser" betekent en dat statefulness voornamelijk voor gebruikerstoepassingen (die dan in een browser draaien) interessant is, maar dat hoeft natuurlijk helemaal niet.

[EddoH]

Op zich snap ik je, en heb er natuurlijk ook aan gedacht zelf een(non-http) simpele implementatie te maken, maar gezien bovenstaande punten was dat eigenlijk geen optie. Daarnaast wist ik al dat het mogelijk was met HTTP, omdat Long Polling al veelvuldig gebruikt wordt.

Daarnaast, zo moeilijk doen is dit allemaal toch niet? Ik neem aan dat iedereen die een server side long polling implementeert even tegen dit vraagstuk aanloopt?

[ Voor 8% gewijzigd door EddoH op 05-06-2014 08:33 ]