ich hatte die letzten Tage mal wieder angefangen in unserer Region mehr details in die Karte zu bringen. Leider wird das nur sehr bruchstückhaft in den einzelnen Zoomstufen aktualisiert.
Das war vorher aber nur bei überlasteten Caches der Fall. Seit der Umstellung auf kommerzielles Caching von fastly.com ist es jetzt immer so, dass pro Kartenaufruf die einzelnen Tile-Anfragen auf mehrere Server verteilt werden.
Ich sehe vier Server ¹, mit ganz grob dieser Verteilung im Schnitt (bei 12 Tiles):
5* odin + 5* ysera + 1* rhaegal + 1* necrosan
Genau diese vier Server sind vermutlich seit dem letzten Carto Release vor einigen Wochen tagsüber komplett am Anschlag. Das sieht man in dieser neuen Übersicht z.B. an der “Queue Length”:
Bei einer Länge über 1000 Metatiles pro Server ist die “dirty queue” voll. In dieser Warteschlange landen Tiles, die nicht sofort neu gerendert werden konnten (weil die anderen Warteschlangen voll sind) und später abgearbeitet werden (z.B. abends). Alle darüber hinaus werden erst mal nicht neu gerendert (dropped).
Insgesamt habe ich den Eindruck, dass die Hauptprobleme vom letzten Jahr durch die Fastly Umstellung weitgehend behoben sind. Jetzt sind halt wieder die Render Server der Flaschenhals. Ich weiß nur nicht, ob es so optimal ist, wenn nach einem Carto Release alle Tiles neu gerendert werden müssen, das dann bei einem einzelnen Kartenaufruf auf bis zu vier Servern gleichzeitig für die selben Metatiles zu machen.
¹ Tile-Server anzeigen (auch schon im Graue Kacheln Faden beschrieben):
Im Netzwerkanalyse/Network Tab in den Entwickler-Werkzeugen (F12) gibt es in den Details zu einer Tile-Anfrage (Zeile klicken) unter “Antwortkopfzeilen”/“Response Headers” zwei Einträge, die Auskunft über den verwendeten Cache- und Render-Server geben:
“x-tilerender” = Render Server
“x-served-by” = Fastly Cache Server (vorher “x-cache”)
In Chrome kann man diese Custom Header per Rechtsklick auf die Kopfzeile auch direkt zur Anfrage-Tabelle hinzufügen (siehe Chrome Referenz).