Admin:tile server performance: verschil tussen versies
(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...') |
|||
| Regel 1: | Regel 1: | ||
'''Voldoet de huidige OBK tile-server die Piet beheert | '''Voldoet de huidige OBK tile-server (die Piet beheert) ook nog als we straks de kaart 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 1 scherm heeft geleverd aan de client. | |||
Hier een korte beschrijving van de huidige situatie | Er is 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 van de tiles, en het oversturen 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 1 keer. | ||
Hier een korte beschrijving van de huidige situatie: | |||
#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 ge''rendered'' (aangemaakt /getekend) moet worden alvorens de aanvraag te honoreren. | #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 ge''rendered'' (aangemaakt /getekend) moet worden alvorens de aanvraag te honoreren. | ||
| Regel 10: | Regel 12: | ||
#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. | #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. | ||
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. | 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. | ||
Versie van 3 dec 2022 13:14
Voldoet de huidige OBK tile-server (die Piet beheert) ook nog als we straks de kaart 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 1 scherm heeft geleverd aan de client.
Er is 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 van de tiles, en het oversturen 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 1 keer.
Hier een korte beschrijving van de huidige situatie:
- 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.
- 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.
- 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.
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.