Maximale snelheid halen

[tom_swinkels]

Dag allen,

Op dit moment ben ik bezig met het ontwikkelen van een online p2000 monitor.
Wat ik wil doen is een realtime monitor maken, hiervoor gebruik ik ook wel een chatbox script.

Als allereerste zal ik voor de vorming even uitleggen hoe het in zijn geheel werkt.

- Melding komt binnen via een pieper, aangesloten op een PC
- .exe file ontvangt de melding en stuurt de melding via de API door naar de webserver
- Vervolgens wordt de melding opgeslagen in de database en volgt de rest

In de huidige situatie wordt er via ajax/javascript gekeken of ik data terug krijg van het PHP script, wanneer ik dat krijg dan krijgt de gebruiker de input direct terug. Het PHP bestand in continue aan het kijken of er een nieuwe melding in de database is gekomen. Wanneer er dus 20 gebruikers de pagina open hebben zijn het nogal wat requesten naar de database terwijl de database een 1.552550 records aan meldingen heeft. Dit gaat dus niet super snel en belast de database ontzettend. Zie -> http://112pers.nl/meldingennew/.

Aangezien ik weet wanneer er een nieuwe melding binnenkomt denk ik dat ik dit beter anders op kan lossen.
Als ik cache (APC) ga gebruiken en de cache elke keer update wanneer er een nieuwe melding komt hoef ik in het PHP script alleen te kijken of er nieuwe data in de cache file staat wanneer er nieuwe data in de cache staat krijgt de gebruiker de output te zien.

Ik zou dit dan bijvoorbeeld door aparte services kunnen laten doen, aangezien er meerdere monitors zijn en je toch alle monitors zo actueel mogelijk wil houden. Ik weet welke meldingen op welke monitor te zien moeten zijn dus hoef de cache alleen geupdate te worden wanneer er voor die bepaalde monitor een nieuwe melding binnen is gekomen.

Een aantal vragen:

- Is dit een goede oplossing, of zijn er betere?
- Hoe ga ik om met bijvoorbeeld een pagina navigatie, de volgende opties zat ik aan te denken
> Gewoon alle records in de cache file en daar gaan filter?
> Als de pagina navigatie gebruikt word de cache file pas aanmaken?
> Hiervoor geen cache gebruiken?

[Megamind]

Websockets gebruiken dan kan dat lompe pollen de deur uit en ben je al van een hoop gezeik af.

[tom_swinkels]

Megamind schreef op maandag 30 december 2013 @ 02:35:
Websockets gebruiken dan kan dat lompe pollen de deur uit en ben je al van een hoop gezeik af.

Dan geld nog steeds de vraag, hoe los ik dan een pagina navigatie op? En neem aan dat ik voor elke monitor dan maar een websocket open heb staan. Er zijn ook verschillende monitors per monitor staat er dan een websocket open, is het een probleem als er straks 100 verschillende sockets open staan?

[DXaroth]

Websockets lijkt het meest zinnige, maar mocht je het hardware matig aan willen pakken, kan je bijvoorbeeld ook gebruik maken van iets a-la Varnish .. die staat toe dat je varnish meld wanneer bepaalde gecachede data niet meer 'vers' is.. en qua snelheid is er niet veel op niveau van php wat in de buurt kan komen van een varnish cache er voor.

[Megamind]

tom_swinkels schreef op maandag 30 december 2013 @ 02:45:
[...]


Dan geld nog steeds de vraag, hoe los ik dan een pagina navigatie op? En neem aan dat ik voor elke monitor dan maar een websocket open heb staan. Er zijn ook verschillende monitors per monitor staat er dan een websocket open, is het een probleem als er straks 100 verschillende sockets open staan?

Zo werkt het niet helemaal. Je hebt gewoon 1 websocket, daarachter zitten hubs of channels, dit zijn dus je "servers". Een client kan zich aanmelden voor zo'n channel, als er dan een bericht is dan wordt dit gepushed naar alle clients van die channel.

[Ramon]

Op zich hoeft file cache niet eens sneller te zijn dan database toegang, dus dat zal je goed moeten testen voordat je het implementeert. Polling in die zin is slecht dat je dus het "pollen" van de database verplaatst naar het "pollen" van je cache file, terwijl je dat hele pollen eigenlijk niet meer wil.

Ik neem verder aan dat je wel de juiste indexen op de database hebt aangebracht?

[kwaakvaak_v2]

precies... je probleem zit hem in het pollen, niet in de opslag laag. Als je van je poll een push maakt ben je aardig eindje op de goede weg.

Aangezien je domein PHP is, zou je eens kunnen kijken naar Ratchet

[Armageddon_2k]

Is het zozeer nodig dat er elke keer in de gehele database gezocht wordt?
Het lijkt me veel handiger om bijvoorbeeld elke maand een nieuwe tabel aan te maken. Mochten mensen hier info uit willen halen, kan je daar prima een slimme query voor bouwen.
maar zo voorkom je dat je elke keer in zo'n enorme bak data gaat lopen grasduinen.

Waarschijnlijk is 90% van je bezoekers alleen geïnteresseerd in de actuele berichten.

[kwaakvaak_v2]

Armageddon_2k schreef op maandag 30 december 2013 @ 12:02:
Is het zozeer nodig dat er elke keer in de gehele database gezocht wordt?
Het lijkt me veel handiger om bijvoorbeeld elke maand een nieuwe tabel aan te maken.
... knip ...
Waarschijnlijk is 90% van je bezoekers alleen geïnteresseerd in de actuele berichten.

Ja.... wat een ontzettend goed idee lekker de data fragmenteren per maand en het een probleem van je applicatie logica maken!......


Als een database in 1 ding goed is, is het wel opslaan en doorzoeken van gegevens en om voor elke maand een losse tabel te maken is ongeveer net zo 'handig' als de asbak van je auto vervangen als deze vol is ipv te legen

Als het om de ruimte gaat, zou je eerder berichten als 'oud' kunnen markeren en gewoon verwijderen, want ik denk idd ook dat 90% van de bezoekers gewoon recente meldingen willen zien dus het vrij nutteloos is om een archief van jaren aan te leggen. Mocht je dat wel moeten doen, is het eerder slim om daar een losse tabel van te maken ipv er voor elke maand 1 te maken. Dat geeft veel te veel gepruts aan de applicatie kant.

[Voutloos]

Gokken is natuurlijk leuk en pollen is meestal stom, maar hier is een helemaal radicaal idee:
Meet uberhaupt waar de bottleneck zit. Dan zou je daarna ook zomaar een idee kunnen hebben wat je doet en of t ook een verbetering is.

[francoski]

Sockets werken prima in browsers, maar zodra mensen gebruik maken van krengen als IE etc wordt het lastig en heb je (vaak betaalde) tools nodig om via vaak alsnog polling toch de data binnen te krijgen.

Ik heb een poosje geleden een systeem opgezet met long-polling. Eigenlijk hetzelfde wat jij al doet, dat php dus steeds checkt. Je laat de verbinding openstaan, totdat er data is. Het probleem is alleen data PHP dat absoluut niet goed kan. Het is er gewoon niet voor gemaakt.

Ik heb het uitgewerkt met de HTTP Push Module in een NginX webserver. Dus gewoon naast de apache server (neem ik aan dat je die draait op een linux server) een nginx-webserver. Hierin kan je channels maken. Enige minpunt is dat het niet echt te beveiligen is. Maar lijkt me voor een P2000 monitor ook niet nodig.

Het idee is: je laadt de pagina met alle info tot NU. Daarna stuur je gelijk een AJAX call naar de push module. Deze call blijft openstaan, totdat je via PHP via CURL een request doet naar het pusch kanaal. Daarin zet je bijvoorbeeld JSON data met 1 of meerdere nieuwe meldingen. Gelijk sluit de push module alle AJAX calls door die data terug te sturen. In je javascript moet je dan deze data weer weergeven, en gelijk een nieuwe connectie openen.

In combinatie met Jquery werkt het zelfs in IE. En het is nog eens razendsnel ook.

Hier kun je de push module downloaden: https://pushmodule.slact.net. Ik wil je eventueel helpen ermee, als je daar interesse in hebt DM me dan even.

[Armageddon_2k]

kwaakvaak_v2 schreef op maandag 30 december 2013 @ 12:11:
[...]
Ja.... wat een ontzettend goed idee lekker de data fragmenteren per maand en het een probleem van je applicatie logica maken!......


Als een database in 1 ding goed is, is het wel opslaan en doorzoeken van gegevens en om voor elke maand een losse tabel te maken is ongeveer net zo 'handig' als de asbak van je auto vervangen als deze vol is ipv te legen

Ik begrijp waar je gedachtegang vandaan komt, en als het gaat om relationele data ben ik dat zeker met je eens. Maar het gaat hier om data dat veel meer overeenkomsten heeft met een Time Series database.
Alle zichzelf respecterende historical databases segmenteren data in blokken.

Laat ik ook maar een stomme analogie maken:
Jij wilt een telefoonnummer van je buurman opzoeken. Dan weet je al dat hij in nederland woont. Dan ga je toch niet de telefoongidsen van de hele wereld openen en doorzoeken?

Dat geeft veel te veel gepruts aan de applicatie kant.

Dit kan je prima (en bij voorkeur) aan de database kant oplossen.
Kan je aan je applicatiekant volledig hetzelfde houden.

[ Voor 21% gewijzigd door Armageddon_2k op 30-12-2013 13:25 ]

[ACM]

Je kan natuurlijk allerlei moeilijke oplossingen gaan uitwerken, zoals het compleet omgooien van je huidige werkmethode...

Maar als je je vooral druk maakt om het aantal queries dat op je database veroorzaakt wordt door het herhaaldelijk pollen zijn er een aantal eenvoudige methodes om dat te reduceren:

- Moet het echt "continu" pollen? Is een keer in de 1, 2, 5, 10 seconden of zelfs nog langer echt niet goed genoeg?

- Voor het pollen lijkt me dat je heel specifieke data nodig hebt, waarmee je vervolgens kunt bepalen of er meer werk/queries gedaan moeten worden. Simpelweg een timestamp van de laatste wijziging voor per specifieke monitor kan al genoeg zijn. Vanuit je client geef je dan mee welk laatste tijdstip je wist voor iedere relevante monitor (of een gezamelijke timestamp voor allemaal) en kan je in je php-code die timestamp vergelijken met die simpele timestamp die je intern weet.
Als er niets veranderd is, stuur je dat terug en heb je nauwelijks of geen queries op je database gedaan.
Die timestamp-cache kan in APC of memcached, maar ook domweg in je database zitten.

Uiteraard kan je je architectuur helemaal omgooien en ervoor zorgen dat browsers helemaal niet meer een polling-request doen. Maar dat is veel meer werk om goed te krijgen terwijl je bovenstaande twee punten relatief eenvoudig en snel kunt doorvoeren.
Sterker nog, daarrna kan je alsnog eventueel je hele architectuur omgooien als dat niet blijkt te voldoen

[ Voor 5% gewijzigd door ACM op 30-12-2013 16:56 ]

[drm]

Je kunt er ook over nadenken of het niet handiger is om de logica aan de input-kant te stoppen, dus als er een nieuwe melding is gewoon een statische file met de juiste data opnieuw wegschrijven en elke client die file uit te laten lezen. Dat hoeft niet eens een PHP file te zijn.

[ Voor 1% gewijzigd door drm op 31-12-2013 00:33 . Reden: iets duidelijker ]

[tom_swinkels]

Bedankt allemaal voor de vele en goede reacties.

Meerdere databases bijvoorbeeld per maand is een optie die ik liever niet gebruik.

Veel reacties gaan over websockets alleen daar zijn de meningen vaak ook over verdeeld.

Op de vraag van ACM, ja elke seconden.. Er bestaan namelijk een hoop p2000 monitors dus wil het graag net wat anders doen dan de rest

Het idee van de timestamps vind ik bijvoorbeeld ook een heel goed idee.

Wat ik nu bijvoorbeeld doe in de while

code:

<?
$countMessage = $this->_messageMapper->getCountMessages( 'WHERE date_recieved > "' . $lasttime . '"' ); 
?>

Zou dan naar een tekst bestand gaan, dat bespaart natuurlijk een hoop snelheid. Alleen probleem is dat de data ophalen ook een hele zware query is. Mij lijkt het beste om toch ook iets met cache te gaan doen.

code:

SELECT
                      id,
                      body,
                      DATE_FORMAT(date_recieved,'%d-%m-%Y') AS date,
                      DATE_FORMAT(date_recieved,'%H:%i:%s') AS time
                FROM
                      p2000_messagesnew
                ORDER BY
                      date_recieved
                DESC LIMIT 20 OFFSET 1

Volgende week ga ik alle reacties nog eens goed doorlezen en verder kijken wat de beste oplossing is.

[Megamind]

Ik zou toch maar eens naar websockets kijken aangezien je probleem blijft en niet schaalbaar is. Wat francoski is niet waar, er zijn genoeg open source of gratis websockets providers die support bieden voor oudere browsers.

[kwaakvaak_v2]

Dat tekst bestand is je cache tomo-dj.. Je laat dat namelijk niet on request van de user wegschrijven, maar on recieve van je scanner ding.

Megamind schreef op dinsdag 31 december 2013 @ 04:16:
Ik zou toch maar eens naar websockets kijken aangezien je probleem blijft en niet schaalbaar is. Wat francoski is niet waar, er zijn genoeg open source of gratis websockets providers die support bieden voor oudere browsers.

Die doen alleen geen websocket, maar emuleren het met een long-pull

[ Voor 60% gewijzigd door kwaakvaak_v2 op 31-12-2013 08:49 . Reden: long pull ]

[Caelorum]

kwaakvaak_v2 schreef op dinsdag 31 december 2013 @ 08:48:
[...]
Die doen alleen geen websocket, maar emuleren het met een long-pull

Daar heb je dan toch iets als SignalR of Socket.IO voor? Die gebruiken in principe websockets, maar met fallback naar bijv. flash, long-polling of zelfs polling.

[Voutloos]

tom_swinkels schreef op dinsdag 31 december 2013 @ 04:04:
Alleen probleem is dat de data ophalen ook een hele zware query is.

Neehee, veel eenvoudiger dan een order by limit op 1 tabel gaan queries niet worden. Dus meet (*$&%^@^ nou eens. Dit topic is echt te veel gelulgegok, te weinig onderbouwing.