Admin:tile server performance

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

Begin positie voor de test

Om tests te kunnen herhalen is het goed om steeds weer van eenzelfde positie te beginnen

Het OBK script kun je nu een OSM of Google url meegeven via de '#' button (die normaal voor zoeken op boomnummer is, vandaar de hash sign) De volgende url formats worden ondersteund

https://www.google.nl/maps/place/Zandvoort/@52.3810726,4.5362575,16z
https://www.openstreetmap.org/search?query=zandvoort#map=16/52.3596/4.5347
https://www.openstreetmap.org/#map=16/52.3596/4.5347

In de log verschijnt Go to pos [52.3596/4.5347], zoom 16, place Zandvoort

Door nu telkens m (voor move) in te tikken en te wachten tot het hele scherm gevuld is kun je een nieuwe meting doen

Go to pos [52.3596/4.5347], zoom 16, place Zandvoort
12:46:44 z=16.0, c=52.36/4.535, t=110, msec=2675
12:46:47 z=16.0, c=52.36/4.635, t=119, msec=2966
12:46:49 z=16.0, c=52.36/4.735, t=111, msec=128
12:46:59 z=16.0, c=52.36/4.835, t=111, msec=5310
12:47:16 z=16.0, c=52.36/4.935, t=118, msec=12451
12:47:17 z=20.0, c=52.159/4.493, t=58, msec=116
12:47:17 z=20.0, c=52.159/4.492, t=68, msec=71

Let op: de log ijlt altijd 1 regel n, m.a.w. pas als je weer 'm' toetst komt het resultaat van de vorige schermopbouw in de log. Om ook de laatste log regel toe te voegen kun je in het log scherm klikken. Dat scherm roep je trouwens op door de 'resize' button (dubbel pijlen) te dubbelklikken.

Test run

Hier de resultaten van een test run beginnend bij Hoek van Holland. Of eigenlijk drie runs

Bij eerste run moeten alle tiles nog gerenderd worden op de tile server
Bij tweede run staat alles klaar in de lokale cache
Bij derde run is de browser cache eerst leeggemaakt, moeten de tiles dus weer van de tile server komen, maar staan ze daar al wel klaar om verstuurd te worden.

3 runs vanuit het zelfde start punt, en waarom de resultaten geheel verschillend zijn

Zie test data tileserver 2022_12_03.xlsx test data tile server

Open vraag

Hoe zien we wanneer tiles gerenderd zijn?"""

In de client zie ik hoe een tile er uit ziet en hoe hij heet, maar waar vind ik de meta data (zoals timestamp?)
Op de tile server zie ik onder nl-custom 5 folder levels diep alleen .meta files (kijk ik op de verkeerde plek?)
- Ah, inmiddels begrijp ik via pagina over mod_tile dat renderd meerdere png tiles in 1 meta file opslaat, die later een voor een verstuurd kunnen worden

… "in a single .meta file. The PNG files are extracted from this on the fly by mod_tile. This is more efficient in disk space and inode usage"