Push or pull model

[Anoniem: 384052]

Ik ben bezig met een bestelsysteem waar meerdere clients aan gekoppeld worden, door middel van een Server <-> Clients principe.
Het betreft ongeveer 30 clients. Met het oog op een paar honderd (remote) clients

Nu moeten deze clients zodra er bestelt is zsm de orders die voor hun bestemd zijn lokaal kunnen ontvangen.

Nu zat ik te denken om een server en client applicatie te schrijven die TCP verbindingen aangaan waarbij de server nieuwe updates in het (sql) database direct pushed naar de client.
Alleen vroeg ik mij af of dit slim is wat betreft server load als ik naar een paar honderd remote clients wil. Ik heb dan natuurlijk een paar honderd open TCP verbindingen + de load van de gebruikers van het bestelsysteem zelf.

Een alternatief is de clients per interval(2min ofso) een pull naar het database te laten doen en kijken voor een update en de data zelf downloaden. Dit vereist geen constante open TCP verbindingen en de clients doen al het werk zelf. Alleen lopen bestellingen dan een kleine vertraging op.

Is er iemand die hier een idee over heeft? ik kan het moeilijk afwegen omdat ik hier niet zoveel kaas van gegeten heb

[ Voor 5% gewijzigd door Anoniem: 384052 op 29-11-2010 23:34 ]

[FragFrog]

In principe kost het opzetten van een verbinding resources, helemaal als je zo'n verbinding ook weer moet authenticaten. Bovendien is er altijd een trade-off in de poll frequentie: te veel pollen betekent dat je veel 'nutteloze' requests hebt (die ook weer resources vereisen), te weinig pollen betekent lange wachttijden tussen updates en minder recente data.

Een paar honderd openstaande verbindingen hoeft absoluut geen probleem te zijn - een beetje MMO gameserver bijvoorbeeld trekt dat makkelijk, en ook een torrent client bijvoorbeeld heeft al snel honderden connected peers. Zeker tot enkele duizenden clients zou het dan ook eigenlijk geen probleem moeten zijn om de connecties open te houden en de pushen.

Let wel, dit hangt uiteraard wel af van je specifieke situatie, de hardware waar het op draait, netwerk infrastructuur, etc, maar als je echt een poll interval van twee minuten overweegt zou ik gaan pushen

[ Voor 3% gewijzigd door FragFrog op 29-11-2010 23:42 ]

[bobo1on1]

Volgens mij is het efficienter om de tcp verbindingen constant open te houden dan om elke client elke 2 minuten te laten pollen.

Een tcp verbinding die open is maar waar verder geen data overheen gaat zou bijna geen resources moeten gebruiken.

[itsalwaysme]

Het ligt eraan wat je belangrijker vindt.
Vind je het belangrijk dat alle clients altijd de correcte voorraad etc hebben, dan push je vanaf de server.
Vind je de server-load belangrijker(of het gebrek ervan), dan laat je de laat je de client het in een bepaald interval pollen.

[apokalypse]

Wellicht om rekening mee te houden, met push zal je wellicht poorten moeten openen/forwarden op de client. Geen idee wat voor clients het zijn en of je hier rekening mee moet houden.

[naam]

Of je push of pull wilt gaan gebruiken is natuurlijk ook afhankelijk van hoeveel er daadwerkelijk via het systeem besteld gaat worden. Ook moet je kijken hoe belangrijk de data is. Als het echt essentieel is dat de clients de data direct krijgen dan zal je een push systeem moeten gaan gebruiken.

[Anoniem: 384052]

het pushen zou natuurlijk ideaal zijn, de server krijgt voor de rest gewoon goede specs en word in een goed datacenter geplaatst.

alleen de webserver komt hier ook op te draaien, en naar verwachting zullen er zeker een paar duizend gebruikers op het bestelsysteem zitten.

maar dit zou gewoon goed moeten gaan?

[Anoniem: 384052]

de clients komen gewoon in beheer bij ons, dus we kunnen doen wat we willen. het direct beschikbaar stellen van de data is niet essentieel maar t zou wel de mooiste optie zijn

verder las ik hier en daar dat tcp veel cpu kan kosten

[ Voor 14% gewijzigd door Anoniem: 384052 op 29-11-2010 23:52 ]

[bobo1on1]

apokalypse schreef op maandag 29 november 2010 @ 23:45:
Wellicht om rekening mee te houden, met push zal je wellicht poorten moeten openen/forwarden op de client. Geen idee wat voor clients het zijn en of je hier rekening mee moet houden.

Niet als de client verbinding maakt en houdt met de server, en de server daarover de pushes doet.

[Victor]

Een push model heeft als belangrijkste voordeel dat je vanuit de server enigzins (met uitzondering van storingen) kunt forceren dat de client met de laatste data werkt. Daarentegen loop je daarbij wel tegen de volgende problemen aan:
- De server moet van alle (beschikbare) clients en hun huidige staat afweten, wat de complexiteit in je serverapplicatie verhoogt (slecht voor je schaalbaarheid).
- De server moet alle clients kunnen bereiken, wat netwerktechnisch lastiger is dan dat alle clients de server moeten kunnen bereiken (zeker als je met remote clients aan de slag gaat).

Mijn advies: gebruik een pull model dat met hoge regelmaat om nieuwe data vraagt. Je hoeft je hierbij echt niet druk te maken over openstaande TCP verbindingen, dat zijn micro-optimalisaties waar je je in deze fase van het ontwikkeltraject nog niet mee bezig moet houden. Richt je op dit moment op het bouwen van werkende software en zie daarbij complexiteit als je grootste vijand, dat is namelijk uiteindelijk hetgene wat je schaalbaarheid, beheersbaarheid en onderhoudbaarheid de nek om kan draaien.

[Herko_ter_Horst]

Als alles in eigen beheer komt, dan zou je ook een peer-to-peer architectuur kunnen overwegen, waarbij peers onderling direct kunnen communiceren. De server kun je dan als rendez-vous gebruiken.

En over de CPU requirements van TCP zou ik me geen zorgen maken, dat gaat echt het probleem niet zijn. De vraag is zelfs of je wel zelf een protocol moet bedenken op basis van TCP, of dat je beter een bestaand protocol uit een hogere laag kunt pakken.

Overigens valt het me op dat je nog niet veel over het systeem hebt verteld, maar vooral over de oplossing die je bedacht hebt. Misschien kun je wat meer uit de doeken doen over waar je dit voor gaat gebruiken. Waarom moeten de clients de data steeds verversen? Kunnen ze niet web-based rechtstreeks op de server werken?

[ Voor 31% gewijzigd door Herko_ter_Horst op 30-11-2010 00:06 ]

[Anoniem: 384052]

Victor schreef op maandag 29 november 2010 @ 23:58:
Een push model heeft als belangrijkste voordeel dat je vanuit de server enigzins (met uitzondering van storingen) kunt forceren dat de client met de laatste data werkt. Daarentegen loop je daarbij wel tegen de volgende problemen aan:
- De server moet van alle (beschikbare) clients en hun huidige staat afweten, wat de complexiteit in je serverapplicatie verhoogt (slecht voor je schaalbaarheid).
- De server moet alle clients kunnen bereiken, wat netwerktechnisch lastiger is dan dat alle clients de server moeten kunnen bereiken (zeker als je met remote clients aan de slag gaat).

Mijn advies: gebruik een pull model dat met hoge regelmaat om nieuwe data vraagt. Je hoeft je hierbij echt niet druk te maken over openstaande TCP verbindingen, dat zijn micro-optimalisaties waar je je in deze fase van het ontwikkeltraject nog niet mee bezig moet houden. Richt je op dit moment op het bouwen van werkende software en zie daarbij complexiteit als je grootste vijand, dat is namelijk uiteindelijk hetgene wat je schaalbaarheid, beheersbaarheid en onderhoudbaarheid de nek om kan draaien.

je maakt een goed punt, een push model maakt het een stuk complexer. een pull model heeft alleen een client-side applicatie nodig (of alleen een scriptje dat refreshed). en aangezien we beginnen met 2 clients en misschien 1000 bezoekers per maand kan ik beter makkelijk beginnen.

In ieder geval goed om te horen dan TCP sockets niet zo'n probleem zijn

[Patriot]

In principe lijkt het me geen probleem om die verbindingen open te houden. Volgens mij raakt een server niet zomaar van slag als je maar pakweg dertig openstaande verbindingen hebt. De overige requests lijken me ook niet erg problematisch.

Wel vraag ik me af of deze complexiteit echt nodig is. Je hebt het over een bestelsysteem, maar ik vraag me af wat de rol van de clients daarin precies is en hoe relevant het is om álle gegevens constant up to date te hebben. Ik neem aan dat iemand niet constant informatie nodig heeft over alle producten, maar steeds bezig is met een selectie daarvan. Waarom update je de gegevens niet gewoon op het moment dat er mee gewerkt word? Misschien kun je ons iets meer vertellen over de taken die op zo'n client moeten worden uitgevoerd.

[Niemand_Anders]

Heb je al gekeken naar een Enterprise Service Bus? De ESB gebruikt message queues (zoals bijvoorbeeld MSMQ) om berichten heen en weer te sturen. Clients kunnen zich abonneren op messages.

De client kan bijvoorbeeld een bericht 'UpdateOrderRequest' versturen naar de server. De server kan vervolgens via Reply een bericht naar alleen een specifieke client (sender van request) of via Publish naar alle clients welke het bericht wensen te ontvangen versturen.

Een voorbeeld van een ESB implementatie in C# kun je vinden in het [ur=https://github.com/ayende/Alexandria]GitHub Alexandria project[/url]. Het 'LearningRhinoServiceBus' project bestaat uit een aantal VS solutions welke verschllende mogelijkheden van de service bus belichten.

Door de inzet van een ESB hoef je je niet meer TCP service te gaan schrijven. Het Apache ServiceMix project is een ESB vooral gericht op Java. Als je voor serialisatie xml, json of ProtoBuffers gebruikt dan ben je zelfs niet gebonden tot een bepaalde taal.

Een ESB is stiekem push en pull. Clients polen alleen hun eigen queue voor ontvangen berichten en versturen berichten naar een externe queue.

[Terranca]

In dezelfde categorie als bovenstaande suggestie kan je ook kijken naar AMQP implementaties zoals RabbitMQ, ZeroMQ, etc.

In het geval van RabbitMQ (een message broker), zouden al je clients zich daarmee verbinden en abonneren op hun eigen locatie (bvb 'heerlen'). Als je vanaf je applicatie nu een bericht naar de broker stuurt met als 'routing key' heerlen, wordt hij real-time gepushed naar de luisterende client.

Voordeel is dat dit systeem enorm goed schaalt, zelf de connecties/berichten afhandelt (minder bugs voor jou) en zichzelf bewezen heeft. Ook hebben ze ingebakken encryptie, authenticatie en support voor load-balancing/failover. En niet te vergeten, omdat het gebaseerd is op een vastgesteld protocol, zijn er language bindings voor behoorlijk wat talen; je zou theoretisch zelfs brokers kunnen wisselen zonder je server/client aan te passen.

Mocht je nog meer uitdaging willen zou je zelfs een queue kunnen maken per product/productgroep en daar je clients naar laten luisteren; dan worden de orders verdeeld onder de clients die zeggen het product/productgroep te kunnen leveren.

Ik heb het zelfs ook het eea. mee gedaan en moet zeggen dat het een slok op een borrel scheelt dat je je niet druk hoeft te maken over tcp connecties, packet-loss, dubbele berichten, disconnects en gelijksoortige problemen.

[Anoniem: 384052]

ik denk dat ESB en AMQP teveel op berichtjes gericht zijn terwijl het meer om sql data gaat dat weer omgezet word in een lokaal database.

de orders moeten zo snel afgehandeld worden omdat er direct geleverd word, vandaar de minimale vertraging

[ Voor 13% gewijzigd door Anoniem: 384052 op 01-12-2010 14:56 ]

[Herko_ter_Horst]

Ok, is dan een peer-2-peer model waarbij de peers gewoon direct onderling communiceren geen optie?

Overigens: dat het SQL data is, maakt voor een MQ niks uit. Je zult toch een messageformaat moeten bedenken, tenzij je je RDBMS rechtstreeks aan het internet wilt hangen (niet doen!).

[ Voor 48% gewijzigd door Herko_ter_Horst op 01-12-2010 18:35 ]

[Niemand_Anders]

Anoniem: 384052 schreef op woensdag 01 december 2010 @ 14:53:
Ik denk dat ESB en AMQP teveel op berichtjes gericht zijn terwijl het meer om sql data gaat dat weer omgezet word in een lokaal database.

de orders moeten zo snel afgehandeld worden omdat er direct geleverd word, vandaar de minimale vertraging

30 clients welke allemaal continue de database pollen zullen voor meer vertragingen zorgen dan het afleveren van 30 berichten. Ik ga er gewoon vanuit dat je database calls atomic zijn (transacties) en dat betekend dat als client A een update uitvoert client B de tabel niet kan lezen. Daarbij als alle calls langs een enkele backend gaan, dan kan de backend ook een eigen cache bijhouden waardoor er zelfs geen database call nodig is. Daarbij vergeet je dat databases ook met messages werken. Elke transactie is een bericht en alle transacties worden in een queue gezet. Het grootste verschil is dat de berichten structuur dan impliciet is.

ESB en AMQP implementaties worden veelvuldig in beurs applicaties en andere financiele applicaties gebruikt. De belangrijkste redenen hiervoor zijn scalibility, domein afbakening (seperation of concerns) en het feit dat de onderliggende infrastructuur door en door getest is en door anderen wordt onderhouden.

Een tijdje geleden hebben wij voor een callcenter een op ESB gebaseerd systeem afgeleverd welke eveneens geintegreerd is met een Asterisk telefoon centrale. De server bestaat uit een enkele backend service en een database instance (er is wel een hot-spare systeem aanwezig ivm HA). Aan het systeem zijn momenteel al 160+ werkplekken aangesloten gebaseerd op de huidige performance kan dit systeem doorgroeien naar 500+ werkplekken.

Definieer zo snel mogelijk. Wat is de maximale verwerkingstijd van een roundtrip? Hoe monitor je of je de SLA niet overschrijd? In het geval van een ESB/AMQP oplossing schrijf je een client welke zowel de request en response messages oppikt, maar niet afhandeld. Deze client kan dan bijhouden wanneer de SLA wordt overschreven. Wordt de SLA binnen x minuten y keer overschreden, dan kun je additionele akties ondernemen zoals het bijschakelen van extra virtuele machines. In ons geval is dat niet meer dan een AddServiceInstanceRequest bericht naar de vServer (vmware) message queue sturen welke de zaken verder afhandeld.

[Anoniem: 384052]

elke peer heeft zijn eigen categorie data, dus ze kunnen niet echt communiceren.

je hebt wel een punt wat betreft het rechtstreeks benaderen van het database, hier moet ik wat op verzinnen idd

[Herko_ter_Horst]

"Eigen categorie data, dus ze kunnen niet communiceren". De centrale server doet dus vertaling? Aangezien de ene client wel bestellingen voor de andere kan doorgeven? Dat betekent voor mij namelijk dat ze een datamodel delen.

Ik snap het idee/waarom van je systeem nog steeds niet. Om wat voor soort bestellingen gaat het? Wat is de functie van de centrale server (buiten jouw oplossing dat hij voor postbkantoor moet gaan spelen)? Hoe verschillend zijn de diverse clients?

[ Voor 8% gewijzigd door Herko_ter_Horst op 01-12-2010 19:25 ]

[Anoniem: 384052]

de server is het bestelsysteem/database, deze verwerkt de orders. de clients zijn aparte 'winkels' zeg maar. de data naar de clients is wat betreft format hetzelfde alleen de inhoud is anders.

[Anoniem: 384052]

de clients hebben in feite niks met elkaar te maken

[Herko_ter_Horst]

Waarom moeten de clients dan zo direct op de hoogte worden gesteld, als de orders centraal verwerkt worden?

[Anoniem: 384052]

omdat de clients direct de levering doen, deze hebben een lokaal bestelsysteem waarin de order weer verwerkt moet worden.

[Herko_ter_Horst]

Is de centrale server dan functioneel gezien alleen voor administratie over het geheel (achteraf)? Want voor het bestelproces zelf lijkt het me een onnodige tussenstap (dus even los van de technische oplossing die je nu in je hoofd hebt)?

[ Voor 24% gewijzigd door Herko_ter_Horst op 01-12-2010 19:34 ]

[Anoniem: 384052]

nee de server is online bestellen en de clients offline
het loopt naast elkaar, het is niet direct gekoppeld.
vandaar dat ik een manier van communicatie zoek

[Herko_ter_Horst]

Ok, dus als ik het goed begrijp kunnen er zowel fysiek in de diverse winkels, als online producten gekocht worden. En als er online iets gekocht wordt (of bij een andere winkel die het zelf niet kan leveren), moet het product direct uit het schap bij de fysieke winkel. Is dat de bedoeling?

[Anoniem: 384052]

ja precies. je kan het zo zien, er zijn een aantal winkels die los van elkaar staan, die een centrale webshop krijgen. ze hebben voor de rest hun eigen 'database'.

mijn taak is om elke order naar de juiste winkel te krijgen, dit is het probleem niet. alleen de manier van communicatie is een punt.

het belangrijkste is dat de winkels direct leveren en zelfs een tijdslimiet(bv binnen een uur) hebben, wat dus maakt dat de data asap beschikbaar moet zijn.

ik denk dat een AMQP/ESB wel een mooie oplossing is, vooral wat betreft scalability en performance

[ Voor 30% gewijzigd door Anoniem: 384052 op 01-12-2010 19:53 ]

[Anoniem: 34929]

Ik heb eens een systeem ontwikkeld wat beide principes (push/pull) combineert:

1) lichtgewicht pushmechanisme dat simpelweg 'broadcast' naar iedereen die 't wil horen, lekker makkelijk: geen authenticatie, maar ook geen inhoudelijke data.
Je moet je dit voorstellen als update notificaties van een bepaald record in een bepaalde tabel, over de tcp verbinding aan berichten als 'tabelnaam|recordid|mutatiecode' (mutatiecode kan ADD/DELETE/UPDATE zijn)
(deze laag gaat over TCP)

2) een poll-achtig meganisme reageert in de client op ontvangen pushnotificaties. De client kan vervolgens bepalen of het de moeite waard is om te gaan pollen. In deze laag handel je ook de authenticatie / encryptie van data af.
(deze laag kun je b.v. over XML/SOAP laten gaan)

Dit principe werkt uit ervaring goed. Misschien heb je hier iets aan?

[ Voor 5% gewijzigd door Anoniem: 34929 op 01-12-2010 19:59 ]

[Anoniem: 384052]

ja zo is de structuur hierbij ook, de client moet namelijk reageren dat de order ontvangen is.

nogmaals denk ik dat AMQP hier mooi voor te gebruiken is

[Victor]

Niemand_Anders schreef op woensdag 01 december 2010 @ 19:09:
[...]

30 clients welke allemaal continue de database pollen zullen voor meer vertragingen zorgen dan het afleveren van 30 berichten.

De meeste databaseservers trekken 30 queries/sec. wel

Ik ga er gewoon vanuit dat je database calls atomic zijn (transacties) en dat betekend dat als client A een update uitvoert client B de tabel niet kan lezen.

Dat is volledig afhankelijk van het isolation level.

Daarbij als alle calls langs een enkele backend gaan, dan kan de backend ook een eigen cache bijhouden waardoor er zelfs geen database call nodig is.

Databaseservers werken ook met caches, dus daar hoef je niet per definitie voor met een aparte laag te werken.

Daarbij vergeet je dat databases ook met messages werken. Elke transactie is een bericht en alle transacties worden in een queue gezet. Het grootste verschil is dat de berichten structuur dan impliciet is.

Dat is gewoonweg niet waar.

Begrijp me niet verkeerd, ik heb niets tegen messaging systemen, maar de motivatie voor het gebruik ervan die je hier aanvoert laat de nodige steken vallen. Messaging is met name interessant als je veel writes te verwerken hebt (dat is namelijk waar databaseservers het als eerste benauwd gaan krijgen) en dan eigenlijk ook alleen als dat asynchroon mag gebeuren. Wat ik er hier van begrijp zullen de writes met name door de webshop gedaan worden en zullen de clients vooral reads doen. Je staat hier dus nu al complexiteit te introduceren om een probleem op te lossen waar de TS nog helemaal geen last van heeft. Ik blijf bij mijn eerdere standpunt, hanteer een eenvoudig pull model waarbij de clients gewoon bij de centrale server aankloppen (ontsluit de data eventueel via een eenvoudige REST-service, iets netter dan rechtstreeks de database induiken) en bewaar alle grote, omvangrijke oplossingen voor het moment dat je daadwerkelijk tegen problemen dreigt aan te lopen en vooral niet eerder.

[Anoniem: 34929]

Victor schreef op woensdag 01 december 2010 @ 20:07:
[...]
...knip...
Je staat hier dus nu al complexiteit te introduceren om een probleem op te lossen waar de TS nog helemaal geen last van heeft. Ik blijf bij mijn eerdere standpunt, hanteer een eenvoudig pull model waarbij de clients gewoon bij de centrale server aankloppen (ontsluit de data eventueel via een eenvoudige REST-service, iets netter dan rechtstreeks de database induiken) en bewaar alle grote, omvangrijke oplossingen voor het moment dat je daadwerkelijk tegen problemen dreigt aan te lopen en vooral niet eerder.

Eigenlijk heb je helemaal gelijk. Waarom moeilijk als het ook eenvoudig kan. Op het moment dat schaalbaarheid een probleem wordt heb je ook genoeg budget / motivatie om 't echt goed aan te pakken.

[Anoniem: 384052]

je hebt inderdaad gelijk, tis op dit moment logischer om daarmee te beginnen.
een simpele api en client is veel efficienter

[Anoniem: 384052]

voor de client wil ik een simpele csharp applicatie schrijven dat communiceert met een api, is dit wel zo veilig over http?

[Victor]

Anoniem: 384052 schreef op woensdag 01 december 2010 @ 20:29:
voor de client wil ik een simpele csharp applicatie schrijven dat communiceert met een api, is dit wel zo veilig over http?

Net zo veilig als via ieder ander protocol, mits je je authenticatie en autorisatie op orde hebt (en gebruik gemakshalve SSL om je verbindingen in ieder geval te versleutelen). Hier is op het wereldwijde web talloze informatie over te vinden

[Anoniem: 384052]

ja precies, ik kan natuurlijk authenticatie versturen in de POST request

[Gomez12]

Hoeveel daadwerkelijke dataverzoeken verwacht je eigenlijk te krijgen?

Want je kan ook gewoon pushen naar een webservice met authenticatie oid.
De authenticatie kost je een klein beetje tijd, maar als je zeg maar 1000 dataverzoeken per uur krijgt dan gok ik dat de authenticatie (performancewijs) gigantisch veel goedkoper is dan 10 constant openstaande tcp-verbindingen.

Het klinkt heel leuk dat je 1000'en klanten krijgt per dag / uur oid. Maar zolang je geen redelijk constante datastromen hebt ( zoals bijv bij een game waar continu statusveranderingen over de lijn moeten ) is een open tcp verbinding relatief duur.
Als het iets van een winkel is en er enkel maar een daadwerkelijke order verzonden wordt dan schat ik dat er maar 1 op de 1000 bezoekers daadwerkelijk te transporteren data veroorzaakt.