41

Ich bin mir nicht sicher ob das die Ideale Loesung ist. Das rendering benoetigt (abgesehen von den DB zugriffen) hauptsaechlich CPU leistung, jedoch kein disk I/O und nur relativ wenig RAM. Der Datenbank Zugriff hingegen benoetigt verhaeltnissmaessig wenig CPU, aber jede menge RAM und noch mehr IO-performance. Insofern koennen die beiden Prozesse relativ gut auf dem gleichen Server laufen. Abgesehen davon verliert man moeglicherweise wohl eine Menge Performance, da die Latency zwischen Renderer und DB deutlich ansteigt wenn es ueber das Netz laeuft und selbst bandwidth wird wohl zum Teil zu einem Problem da relative grosse Mengen an Daten zwischen Mapnik und Postgres ausgetauscht werden.

Wenn man tatsaechlich nicht mehr genug CPU Leistung fuer das rendering hat, kann man schon auf verteiltes Rendering umsteigen. Dafuer hatte ich mal vor einer Weile den Code geschrieben. Aber ich weis nicht ob der noch funktioniert und wie weit es Sinnvoll ist, denn er wurde nie eingesetzt da er nicht gebraucht wurde.

Wahrscheinlich geschickter ist eine Trennung von Rendering zu Auslieferung. Das reine Serving der Tiles benoetigt auch nicht zu vernachlaessingde IO-last wenn man viele gleichzeitigen Zugriffe hat (hunderte tiles/sekunde). Jede Ausgelieferte Kachel verursacht moeglicherweise einen zufaellig verstraeuten Festplattenzugriff. Hier hilft mehr Ram fuer Disk caching auch.