[Talk-de] Overpass sehr langsam

[Andreas Neumann]

Am 29.12.2013 19:41, schrieb 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

Hallo Roland,

danke für das ausführliche Update.

Aus historischen und stilistischen Gründen verwende ich in meinem
Programm keine BBOX, sondern lade pauschal alle Daten einer Area
herunter. Da ich die Clients nicht überlasten will, sind meine Areas auf
admin-level>5 beschränkt (mit hardcodierter Ausnahme Berlin, Bremen und
Hamburg). Leider fiel mit dein Area-Problem damit auf die Füße.

Ich freue mich, wenn morgen wieder alles flüssiger läuft.

Guten Rutsch,
Andreas

-- 
Andreas Neumann
http://map4Jena.de
http://Stadtplan-Ilmenau.de


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 728 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20131230/20640c10/attachment.sig>