Admin:tile server performance

Uit wiki.openbomenkaart.org
Versie door Eazy (overleg | bijdragen) op 3 dec 2022 om 13:05 (Nieuwe pagina aangemaakt met ''''Voldoet de huidige OBK tile-server die Piet beheert, als we de kaart voor heel Nederland willen ondersteunen.''' Om daar wat over te kunnen zeggen kijken we hoel...')
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)
Naar navigatie springen Naar zoeken springen

Voldoet de huidige OBK tile-server die Piet beheert, als we de kaart voor heel Nederland willen ondersteunen. Om daar wat over te kunnen zeggen kijken we hoelang het duurt voor die OBK tile server om alle tiles die een client nodig heeft te leveren, per scherm dat opgevraagd wordt.

Er is nu code in de OBK scripts om de performance van de huidige server meetbaar te maken.

Hier een korte beschrijving van de huidige situatie (even checken):

  1. Elke dag haalt de OBK tile server de nieuwe data van de OSM server op, voor heel Nederland. Daarna kan de tile server bepalen wanneer een tile aangevraagd wordt, 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.
  2. tiles voor Leiden worden daarna elke nacht automatisch geprerendered. 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.
  3. 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.

Ik heb code gemaakt om het ophalen van de tiles van een client exact meetbaar te maken. Uiteraard is de total tijd een optelsom van het eventueel renderen van de tile, en het oversturen. Op een andere tijd van de dag, op bij een andere client, zullen er andere meetwaarden volgen. 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 in een snelle lokale verbinding heeft. Maar nu test je het hele trajekt in 1 keer.

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.

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.