MapCache: Disk vs. SQLite

Historisch betrachtet sind wir ein «Ein-Request-ein-Bild-WebGIS-Kanton». Was heisst das? Bei all unseren eingesetzten WebGIS-Klienten wurde nach einer Benutzer-Interaktion (also Zoomen, Pannen etc.) ein einziges Bild vom Server zurückgeliefert. Auch wenn das Bild aus mehreren Kartenlayern zusammengesetzt ist. Wie so alles im Leben hat das Vor- und Nachteile. State-of-the-art ist es gefühlt heute nicht mehr. Will man z.B. die Transparenz eines Kartenlayers ändern, löst das einen neuen Request aus und der Server muss ein neues Bild rendern. Er übernimmt eine Aufgabe, die heute locker ein Browser schafft.

Beim Einsatz von QGIS-Webclient kamen dann auch noch Performance-Probleme hinzu. Aus diesem Grund haben wir begonnen die Hintergrundkarten (wie Orthofoto, Basisplan, etc.) zu kacheln und diese Kacheln vorzuhalten (aka WMTS). Als WMTS-Server verwenden wir MapCache. MapCache unterstützt verschiedene Cache Types. Ohne gross zu studieren, haben wir dann das vermeintlich Einfachste gewählt: Disk caches. Dabei werden einfach alle Kacheln direkt auf dem Filesystem gespeichert. Die Projektdokumentation macht da eine relativ klare Ansage:

«The disk based cache is the simplest cache to configure, and the one with the the fastest access to existing tiles. It is ideal for small tile repositories, but will often cause trouble for sites hosting millions of tiles, as the number of files or directories may rapidly overcome the capabilities of the underlying filesystem.»

Und so ist es dann natürlich auch gekommen. Welches ist das sinnvollste Filesystem? Ok, Rücksprache mit der Informatik-Abteilung und speziell ein Laufwerk erstellen, formatieren und mounten…​

Als weiterer Cache type gibt es auch SQLite caches. Bei dieser Variante werden sämtliche Kacheln in einer SQLite-Datenbank gespeichert. Was jetzt natürlich auf einen Schlag die ganze Filesystem-Diskussion beendet plus das Deployment vereinfacht: Einfach irgendwo seeden und die SQLite-Datei an den passenden Ort kopieren. Die Kachel wird als Blob in der Datenbank-Tabelle gespeichert. Nachteilig sind gemäss Dokumentation:

«The SQLite based caches are a bit slower than the disk based caches, and may have write-locking issues at seed time if a high number of threads all try to insert new tiles concurrently.»

Nicht ganz klar sind mir die «write-locking issues at seed time». Heisst das, dass - falls sie auftreten - Kacheln «verloren» gehen oder die Seeding-Performance zusammenbricht? Um das zu klären, müsste man auf der Mailingliste nachfragen.

In erster Linie geht es mir um die Frage wie gross der Performance-Unterschied der beiden Cache types ist. Sind Disk caches so massiv schneller, dass SQLite caches ein No-go sind? Um diese Frage zu beantworten, habe ich auf meinen Testsystem eine WMS-Karte je einmal mit Disk caches und SQLite caches geseedet und anschliessend mit jmeter die Performance gemessen. Dabei habe ich wiederum WMS-Requests gemacht, die MapCache aber aus den vorher geseedeten Kacheln zusammensetzt. Das ist zwar ein Zusatzaufwand, der eigentlich nichts mit den Cache types zu tun hat, aber ich denke, das ist für unsere Anforderungen vernachlässigbar (und an absoluten Zahlen sind wir weniger interessiert).

Das Seeding selbst scheint bei beiden Typen gleich schnell zu sein.

Für die WMS-Requests gibt es wieder altbackene Charts:

Interessanterweise sind bei mir die SQLite caches sogar klein wenig schneller. Faszinierend ist der Vergleich zu den nicht-aus-geseedeten-Kacheln-zusammengesetzten Live-WMS-Requests. Als Vergleich habe ich neben dem wirklich direkten Zugriff auf den WMS-Server auch noch MapCache als Proxy (<full_wms>forward</full_wms>) dazwischengeschaltet: