[Talk-de] (Nicht nur) T at H (ist) furchtbar langsam(!)

[Johann H. Addicks]

Jens Frank schrieb:

>     (DS 3000) bei Hetzner für T at H zur Verfügung zu stellen.
[..]
>     Moment im Leerlauf, es stehen also fast 2 GB Ram, 180 % CPU und eine 100
>     MBit Anbindung mit 1 TB/Monat Limit.

> etwas weniger Traffic, aber mit 1TB/Monat kommt man da auch nicht weit.
> Von solchen kleinen Rechner stehen bei OSM schon einige rum. Damit kommt 
> man aber inzwischen nicht mehr recht weiter, 

Man kann keine kleinen Rechner mit anderen kleinen Rechnern ersetzen. 
Und selbst mit Lastverteilung wird's schwierig, wenn diese nicht im 
gleichen Rack/Cage zusammen stehen.

Wenn wir für einen Renderer von 2TB Traffic/Monat durch Clients 
(Tile-Abrufe) ausgehen, gleichzeitig aber sehen, dass der Planet derzeit 
(ebenfalls pro Renderer) aus rund 500GB Tiles besteht, von denen 
(Schätzwert konservativ) 30% pro Monat einmal aktualisiert werden 
möchten und 20% vier mal, dann hätte man schon 500GB an Traffic allein 
für das Synchronhalten der Tiles auf der Uhr. (Man könnte auch die 
Datenbank spiegeln und selbst rendern, dann käme aber noch die Last fürs 
Rendern und das ständige Spiegeln der Datenbank dazu)
Aber egal wie man es anstellt, die Daten (Datenbank oder PNGs) müssen ja 
auch erstmal irgendwo herkommen von den bisherigen zentralen Servern.

Das einzige, was ich mir aus einem Flickenteppich von Rootservern 
vorstellen könnte wäre ein Proxy-Array, welches mit entsprechend 
aggressiv eingestellten Source-Squids sich untereinander als 
parent/multicast kennt.
Zusätzlich müssten dann die "üblichen" Clients 
(openstreetmap.org/informationfreeway) noch einen round-robin verordnet 
bekommen, dass sie eben die Squids befragen, die gerade "lebendig" sind.

So oder so würde das bedeuten, dass die Performance "für die Kunden" 
sinkt. Sei es, dass auch mal veraltete Kacheln ausgeliefert werden, oder 
dass eben die Antworten noch ein paar ms länger brauchen, weil erst 
nachgeschaut wird, ob die lokale Kopie denn noch aktuell ist und ggf. 
wieder ein Timeout abgewartet werden will.

Will sagen: Ein performantes Speichersubsystem und ein paar Webserver 
daran lokal angeschlossen sind sicher einfacher zu handhaben.

-jha-