[Talk-de] Overpass sehr langsam

[Roland Olbricht]

Hallo zusammen,

> Kommt es mir nur so vor, oder ist Overpass seit Beginn der
> Weihnachtsfeiertage extrem langsam geworden? Anfragen, die vorher
> 1-30sec dauerten laufen nun oftmals 3min oder länger. Zeitgleiche
> Requests gehen fast gar nicht (http 429: too many requests)...

Es gibt auf overpass-api.de eine Reihe von Ereignissen, die gerade in der Tat 
für Verlangsamung sorgen. Verbesserung auf das alte Niveau ist ab Silvester zu 
erwarten, Verbesserung auf ein besseres Niveau ab Ende Januar. Im Detail:

Zunächst einmal hat seit Einführung des Export-Links von osm.org aus (siehe 
unter "Export", dann unter dem "Export"-Button) für vermehrte übergroße Map-
Abfragen gesorgt - zum Teil bis zu dem halben Planeten. Da die Abfrage aber 
auch eine Reihe von Export-Anliegen sinnvoll löst, möchte ich den Link nicht 
wieder entfernen. Um zu verhindern, dass die Map-Calls zu sehr auf den Server 
insgesamt durchschlagen, habe ich den Parameter für parallel von der gleichen 
IP-Adresse mögliche Abfragen von 2 auf 1 gesenkt. 

Damit richten insbesondere die beiden häufigsten problematischen Verhalten nur 
noch halb so viel Schaden an: Vermeidbare Last erzeugt es, eine große Anfrage 
zu stellen, nach einigen Sekunden abzubrechen und dann sofort die gleiche 
Anfrage erneut zu stellen.

Generell kann man eine laufende Abfrage mit
http://overpass-api.de/api/kill_my_queries
abbrechen und Platz für eine alternative Query schaffen.

Ein anderes problematisches Verhalten ist es, dutzendweise Anfragen ohne 
Rückmeldung parallel zu stellen. Das erzeugt Lastspitzen bzw. würde 
Lastspitzen erzeugen und die Zeit bis zum Abschluss der letzten Abfrage ist 
genauso lang wie bei einer sequentiellen Abarbeitung. In manchen 
Einsatzszenarien, z.B. einer Slippy Map mit Ereignissteuerung, lässt es sich 
aber nur schwer Client-seitig vollständig verhindern.

Daher behält der Server bei mehreren parallelen Anfragen alle weiteren 
Anfragen für bis zu 15 Sekunden im Wartezustand und beendet sie erst dann, 
wenn bis dahin durchgehend Anfragen von der gleichen IP-Adresse diese Abfrage 
blockieren, sonst werden diese Anfragen nacheinander abgearbeitet.

Der zweite große Komplex sind Areas. Um Ärger mit nicht orientierten-Wegen und 
mehr oder weniger falschen Relationen-Rollen gleich im Ansatz zu vermeiden, 
benutzt die Overpass API ein sehr einfaches Flächen-Modell

- der Südpol ist außen
- alle übrigen Punkte sind genau dann innen, wenn sie vom Südpol durch eine 
ungerade Zahl Kanten getrennt sind
- Area-Beschreibungen, bei denen in irgendeinem Punkt eine ungerade Zahl 
Kanten zusammenkommt, werden als ungültig verworfen.

Das führt nur dann zu einem Fehler, wenn Gebiete hinzugefügt werden, die den 
Südpol umschließen; bei diesen verwendet der Algorithmus irrtümlich den Rest 
der Erdkugel statt des beabsichtigen Gebiets als inneres Gebiet, und jede 
Area-Abfrage ist dann mehr oder weniger relevant für dieses Gebiet.

Das ist nicht passiert bis
http://overpass-turbo.eu/s/1T6
bzw.
http://overpass-turbo.eu/s/1T5

Provisorisch nehme ich Gebiete mit admin_level=2 aus der Area-Erzeugung 
heraus. Danach gilt es, den Fehler in der Software zu beseitigen.

Das wird mit der nächsten Version v0.7.50 passieren und leitet über zum 
dritten Ereignis: v0.7.50 hat eine deutlich andere Datenbank-Struktur, um 
einerseits Abfragen mit großen Bounding-Boxen zu beschleunigen, andererseits 
alte Datenbestände abfragen zu können und so z.B. bequem beliebige Undo-
Operationen ausführen oder Änderungen verfolgen zu können. Intern verringert 
es drastisch den Aufwand, Änderungen nachzuverfolgen, was bisher mit den 
Augmented Diffs, die in Echtzeit erzeugt werden müssen, sehr mühsam ist. 
Augmented Diffs werden dann zur Abfragezeit für den exakt passenden Zeitraum 
erzeugt statt in Echtzeit jede Minute.

Dafür berechne ich gerade die notwendige Datenbank neu und verarbeite dafür 
alle Daten seit dem Lizenzwechsel im September 2012. Da das mit niedrigster 
Priorität passiert, wird es voraussichtlich einen Monat bis Ende Januar 
dauern, die 1,5 Jahre Änderungen zu durchlaufen.

Theoretisch darf sich diese Neuberechnung nicht auf die laufende Datenbank 
auswirken. Praktisch lässt sich nicht ausschließen, dass nicht allein das oben 
geschilderte Große-Map-Exporte-Phänomen die Last auslöst, sondern auch die 
neue Datenbank.

In jedem Fall ist daher ab Ende Januar mit einer generellen Verbesserung zu 
rechnen, und spätestens schon Silvester sollte das Problem mit der Area-
Neuberechnung keine Last mehr verursachen.

Ich werde versuchen, einen Blogbeitrag auf blog.openstreetmap.de zu verfassen, 
wenn die aktuellen Area-Probleme geklärt sind.

Viele Grüße,

Roland