...
Script dat elke x seconden data ophaalt
Bij eens een script dat elke minuut runt voor een paar regels is zijn er geen probleemproblemen. Bij een seconde moeten we al gaan kijken of het elke keer volledig binnenkomt. Als we de data daadwerkelijk twintig keer per seconden op de website willen tonen, moeten we het script elke 50ms laten runnen. Als we deze keuze maken moeten er een aantal dingen bijkomen. Allereerst komt de data op de database binnen, dan moeten we een script hebben dat alleen die data ophaalt en geen andere data. Er zal dus moeten worden gekeken op ID of op tijd/timestamp. Ook deze data, de id of tijd die als laatste bekend is, moet ergens worden opgeslagen of onthouden worden door het systeem. Het kan ook nog zo zijn dat op het moment van ophalen het net iets langer duurt en duurt en er al andere data in te komen is staan en staan en je dus achterloopt of data overslaat. Tien regels in een table tabel zal binnen een milliseconde verwerkt worden (afhangend van de hardware), maar miljoenen regels in honderden tabellen loopt al snel op. Dit zijn dingen die makkelijker zijn te voorkomen en te verwerken met gebruik van andere technieken. Het voordeel dat dit systeem heeft is dat het snel en makkelijk te implementeren is en wij allemaal de benodigdheden hebben om dit te doen. Een verbetering zou kunnen zijn om een stuk code te laten uitvoeren op het moment dat er een insert is op 1 table een tabel, die de data ophaalt, alleen . Dit zal ook dit weer effect hebben op de snelheid van het systeem.
Gebruik van transactielogboek
De techniek van Herrera, dat gebruik maken maakt van het transactielogboek, is een techniek die alles al directer meer direct doet. De data wordt opgeslagen , De en de Java applicatie weet dat gelijk en via . Via de pusher channel staat het bijna direct op de website. Eén Een van de voordelen dat deze techniek heeft, is dat er nooit data op wordt gehaald als deze niet wordt opgeslagen. Herrera geeft zelf al aan dat het systeem dat hij gebruikt het proces niet vertraagd wordt door bijvoorbeeld triggers. Zo snel als er een update is in de database, weet ook de Java API dit. Vervolgens kan de API dit aan de pusher doorgeven die het dan weer op de website zet. Al deze stappen lijken misschien meer dan het ophalen van data maar is al een stuk efficiënter en sneller. Het gebruikt meerdere elementen die ook los van elkaar bestaanbe staan. Zo lijkt het ophalen van data enigszins op long polling (wachten tot er data is in plaats van vragen of het er al is).
Polling
Polling lijk lijkt op de eerste techniek, een script dat elke x seconden data ophaalt. Er wordt een request verstuurd met, in dit geval, de vraag of er al data binnen is gekomen. De server (DB/API) zal reageren met of de opgevraagde data, of dat er geen nieuwe data is. Als de client de reactie heeft. , ongeacht van wat deze reactie is, dan zal deze de client direct weer een nieuwe aanvraag sturen. Dit is een systeem dat sneller zal werken dan bijvoorbeeld een script dat elke keer aangeroepen wordt, maar zal door de snelheid (als een request sneller verwerkt wordt dan het eerder aangegeven script) ook meer resources in gebruik nemen.
...
Long polling is een soort van opvolger en in dit geval een betere , opvolger van polling. Long polling begint op dezelfde manier. Er wordt een request gestuurd naar de server vanaf de client. Hier is ook gelijk al te zien wat er beter is aan long polling ten opzichte van 'gewoon' polling. Bij polling wordt er een response gestuurd. Deze response is zo snel mogelijk, dus of met data, of er is geen nieuwe data. Long polling wacht tot er nieuwe data is. Is er nog geen data, dan ook geen response. Is er wel nieuwe data, dan krijg je ook de response. Zo snel als de response binnenkomt wordt er ook weer een nieuwe request gestuurd ,zodat de mogelijk nieuwe data weer zo snel mogelijk binnenkomt. Bij long polling is het echter wel zo dat een server of client soms denkt , of juist de client, dat de connection te lang open heeft gestaan en dat deze connection na een tijd gesloten wordt. Het gebruikt meer middelen dan bijvoorbeeld een websocket. Ook kan het zijn dat er meerdere poll requests open staan naar een server en server en de volgorde van de berichten niet klopt.
...
Server Sent Events en Websockets lijken veel op elkaar. Ook , ook is er in dit geval één kopje voor de twee samen. Een aantal verschillen tussen de twee is dat SSE over HTTP gebruikt kan worden terwijl websockets hun eigen protocol hebben. Een verschil tussen de twee die echt een verschil maakt, is wie requests en responses kan sturen. Bij SSE wordt er één keer een request gestuurd naar de server. Dit Deze request is een aanvraag om te verbinden. Daarna kan alleen de server berichten terug sturen. De client kan geen berichten naar de server sturen. Dit is ook waar SSE voor gemaakt is. Websockets, die wel berichten kunnen sturen naar de server als er eenmaal een connectie is geopend, zouden in dit geval dan een overkill zijn. Er zijn nog wel andere voor en nadelen te benoemen, zoals dat SSE maar een maximaal open connecties mag hebben, maar ook hiervoor zijn oplossingen te bedenken. Echter is dit ook geen probleem voor deze applicatie.
...