Admin:tile server performance: verschil tussen versies

Versie van 3 dec 2022 13:32

Begrippen

Een client is het apparaat dat een kaart presenteert aan een gebruiker. Dat kan een desktop PC zijn, of een tablet, of een smartphone.
De server is het apparaat die de kaart in stukjes (tiles) opstuurt naar de client.

Vraagstelling

Voldoet de huidige OBK tile-server (die Piet beheert) ook nog als we straks kaarten voor heel Nederland willen ondersteunen?

Om daar wat over te kunnen zeggen kijken we hoelang het duurt voor de tile server alle gevraagde tiles voor het opbouwen van een scherm heeft geleverd aan de client.

Daartoe is er nu een voorziening in de OBK scripts om die performance van de server meetbaar te maken. Uiteraard is de totale tijd om een scherm te vullen op de client een optelsom van het eventueel renderen (aanmaken) van de tiles, en het oversturen van de tiles als pakketjes via internet. Op een andere tijd van de dag, of op een andere client (met bijv een snellere verbinding) zullen er andere meetwaarden uitrollen. Voor het puur meten hoe lang de server nodig heeft om de tiles beschikbaar te maken, kan de test het best lokaal uitgevoerd worden: een client PC die met de server een snelle lokale verbinding heeft. Maar nu test je het hele trajekt in één keer.

Een korte beschrijving van de huidige situatie

Elke dag haalt de OBK tile server (aka Piet's server) de nieuwe data van de OSM server op, voor heel Nederland. Daarna kan de tile server bepalen, op het moment dat een tile opgevraagd wordt door een client, of de data zijn gewijzigd t.o.v. de vorige dag (m.a.w. of de tile dirty is), en dus of deze tile opnieuw gerendered (aangemaakt /getekend) moet worden, alvorens de aanvraag te honoreren.
Tiles voor Leiden worden daarna elke nacht automatisch geprerendered. Met andere woorden: alle tiles voor dat deel van de kaart, zelfs tot zoom 20 worden dus elke nacht al klaargezet, zodat ze ook voor de eerste bezoeker alleen maar overgestuurd hoeven te worden.
Voor de rest van het land worden de tiles on-demand gerendered. De eerste bezoeker van een locatie buiten Leiden ziet een merkbare vertraging, de volgende bezoeker van die locatie hoeft alleen de tiles van de server te laden, die staan inmiddels klaar. Beide krijgen bij een refresh de tiles uit hun lokale cache.

Performance test

De performance test werkt als volgt: met een toetsaanslag (m voor move) kunnen we de kaart opschuiven (telkens met 0.1 lengtegraad naar het oosten). Bij hogere zoomnivo's is er dan geen overlap in tiles met de vorige positie, en moet dus elke tile (bij een lege cache, of soewieso een nieuwe dag (?)) opnieuw van de server opgevraagd worden. Voor elke tile die binnenkomt krijgt de client een event binnen, en kan zo na de laatste event loggen hoeveel tiles geladen werden en hoelang dit alles tesamen duurde.

Door nu een flink aantal verschuivingen te doen, en telkens het resultaat naar een log te schrijven, kunnen in Excel de gemiddelde laadtijd voor een schermvol tiles berekenen. Uiteraard is dit zeer afhankelijk van hoeveel tiles in de window passen en dus mede van de grootte van het scherm. Op een mobiel zal dit allemaal nooit een bottleneck worden. Bij een 4K scherm (3840x2160 pixels), en de OBK in een full screen window, is het aantal tiles zeer groot en dus ook de tijd om alles te laden.

Zoom nivo

Het zoom nivo zal ook een rol spelen: Bij zoom 20 zijn er zo weinig elementen die gerendered moeten worden, dat kan de tile server sneller. Bij zoom 15 zit een tile vol details. Dat duurt langer

@@ Regel 1: / Regel 1: @@
-'''Begrippen''' Een ''client'' is het apparaat dat een kaart presenteert aan een gebruiker. Dat kan een desktop PC zijn, of een tablet, of een smartphone.
+===Begrippen===
+Een ''client'' is het apparaat dat een kaart presenteert aan een gebruiker. Dat kan een desktop PC zijn, of een tablet, of een smartphone.
 <br>De ''server'' is het apparaat die de kaart in stukjes (''tiles'') opstuurt naar de client.
+===Vraagstelling===
 '''Voldoet de huidige OBK tile-server (die Piet beheert) ook nog als we straks kaarten voor heel Nederland willen ondersteunen?'''
@@ Regel 8: / Regel 10: @@
 Daartoe is er nu een voorziening in de OBK scripts om die performance van de server meetbaar te maken. Uiteraard is de totale tijd om een scherm te vullen op de client een optelsom van het eventueel ''renderen'' (aanmaken) van de tiles, en het oversturen van de tiles als pakketjes via internet. Op een andere tijd van de dag, of op een andere client (met bijv een snellere verbinding) zullen er andere meetwaarden uitrollen. Voor het puur meten hoe lang de server nodig heeft om de tiles beschikbaar te maken, kan de test het best lokaal uitgevoerd worden: een client PC die met de server een snelle lokale verbinding heeft. Maar nu test je het hele trajekt in één keer.
+===Een korte beschrijving van de huidige situatie===
-Hier een korte beschrijving van de huidige situatie:
+#Elke dag haalt de OBK tile server (aka ''Piet's server'')  de nieuwe data van de OSM server op, voor heel Nederland. Daarna kan de tile server bepalen, op het moment dat een tile opgevraagd wordt door een client, of de data zijn gewijzigd t.o.v. de vorige dag (m.a.w. of de tile ''dirty'' is), en dus of deze tile opnieuw ge''rendered'' (aangemaakt /getekend) moet worden, alvorens de aanvraag te honoreren.
+#Tiles voor Leiden worden daarna elke nacht automatisch ge''prerendered''. Met andere woorden: alle tiles voor dat deel van de kaart, zelfs tot zoom 20 worden dus elke nacht al klaargezet, zodat ze ook voor de eerste bezoeker alleen maar overgestuurd hoeven te worden.
+#Voor de rest van het land worden de tiles ''on-demand'' gerendered. De eerste bezoeker van een locatie buiten Leiden ziet een merkbare vertraging, de volgende bezoeker van die locatie hoeft alleen de tiles van de server te laden, die staan inmiddels klaar. Beide krijgen bij een ''refresh'' de tiles uit hun lokale cache.
-#Elke dag haalt de OBK tile server (aka ''Piet's server'')  de nieuwe data van de OSM server op, voor heel Nederland. Daarna kan de tile server bepalen op het moment dat een tile opgevraagd wordt door een client, of de data zijn gewijzigd t.o.v. de vorige dag (m.a.w. of de tile ''dirty'' is), en dus of deze tile opnieuw ge''rendered'' (aangemaakt /getekend) moet worden alvorens de aanvraag te honoreren.
+===Performance test===
-#tiles voor Leiden worden daarna elke nacht automatisch ge''prerendered''. In andere woorden: alle tiles voor dat deel van de kaart, zelfs tot zoom 20 worden dus elke nacht al klaargezet, zodat ze ook voor de eerste bezoeker alleen maar overgestuurd hoeven te worden.
+De performance test werkt als volgt: met een toetsaanslag (m voor move) kunnen we de kaart opschuiven (telkens met 0.1 lengtegraad naar het oosten). Bij hogere zoomnivo's is er dan geen overlap in tiles met de vorige positie, en moet dus elke tile (bij een lege cache, of soewieso een nieuwe dag (?)) opnieuw van de server opgevraagd worden. Voor elke tile die binnenkomt krijgt de client een ''event'' binnen, en kan zo na de laatste event loggen hoeveel tiles geladen werden en hoelang dit alles tesamen duurde.
-#Voor de rest van het land worden de tiles ''on-demand'' gerendered. De eerste bezoeker van een locatie buiten Leiden ziet een merkbare vertraging, de volgende bezoeker van die locatie hoeft weer alleen de tiles van de server te laden, die staan inmiddels weer klaar. Beide krijgen bij een refresh de tiles uit hun lokale cache.
+Door nu een flink aantal verschuivingen te doen, en telkens het resultaat naar een log te schrijven, kunnen in Excel de gemiddelde laadtijd voor een schermvol tiles berekenen. Uiteraard is dit zeer afhankelijk van hoeveel tiles in de window passen en dus mede van de grootte van het scherm. Op een mobiel zal dit allemaal nooit een bottleneck worden. Bij een 4K scherm (3840x2160 pixels), en de OBK in een ''full screen'' window, is het aantal tiles zeer groot en dus ook de tijd om alles te laden.
-De test werkt als volgt: ik kan met een toetsaanslag de kaart opschuiven (telkens met 0.1 lengtegraad). Bij hogere zoomnivo's is er dan geen overlap in tiles met de vorige positie, en moet dus elke tile (bij een lege cache, of soewieso een nieuwe dag (?)) opnieuw van de server opgevraagd worden. Voor elke tile die binnenkomt krijg ik op de client een event binnen, en kan zo na de laatste event loggen hoeveel tiles geladen werden en hoelang dit alles tesamen duurde.
+===Zoom nivo===
+Het zoom nivo zal ook een rol spelen: Bij zoom 20 zijn er zo weinig elementen die gerendered moeten worden, dat kan de tile server sneller. Bij zoom 15 zit een tile vol details. Dat duurt langer
-Door nu een flink aantal verschuivingen te doen, en telkens het resultaat naar een log te schrijven, kan ik daarna in Excel de gemiddelde laadtijd voor een schermvol tiles berekenen. Uiteraard is dit zeer afhankelijk van hoeveel tiles in de window passen en dus mede van de grootte van het scherm. Op een mobiel zal dit allemaal nooit een bottleneck worden. Bij mijn 3840x2160 (4K) scherm (en OBK full screen) is het aantal tiles zeer groot en dus ook de tijd om alles te laden. Ik veracht ook dat het zoom nivo een grote rol speelt.
-Bij zoom 20 zijn er zo weinig elementen die gerendered moeten worden, dat gaat sneller. Bij zoom 15 zit een tile vol details.