Es gibt eine öffentliche Instanz, die größtmögliche Ressourcen bereitstellt, aber auch gegen Übernutzung verteidigt. Großnutzer können leicht eine eigene Instanz aufsetzen.
Ziel der öffentlichen Instanzen ist es, möglichst vielen Nutzern zur Verfügung zu stehen. Die Rechenleistung der Server muss zwischen den täglich etwa 30.000 Nutzern aufgeteilt werden.
Die typische Abfrage hat eine Laufzeit von unter 1 Sekunde, es gibt jedoch auch deutlich länger laufende Anfragen. Jeder Server der Overpass API kann davon etwa 1 Mio. Anfragen pro Tag beantworten, und es werden zwei Server im Rahmen von overpass-api.de betrieben.
Es ist praktisch ausgeschlossen, dass Sie mit manuell ausgelösten Abfragen jemals Schwierigkeiten bereiten. Leider kann die Ressourcenbegrenzung Sie trotzdem vereinzelt heimsuchen - der Algorithmus kann nicht perfekt arbeiten.
Beispiele für problematisches Verhalten sind:
Im ersten Fall muss das abfragende Skript repariert werden, in den Fällen 2 und 3 sollte anstatt der Overpass API lieber ein Planet-Dump verwendet werden. Im vierten Fall ist eine eigene Instanz die bessere Wahl; Hinweise zur Einrichtung geben die Installations-Instruktionen.
Tatsächlich stellen die meisten Nutzer aber nur jeweils wenige Anfragen. Die automatische Lastbegrenzung zielt also darauf ab, die ersten paar Abfragen pro Nutzer gegenüber massenhaften Abfragen einzelner Nutzer zu bevorzugen. Eine manuelle Lastbeschränkung wird also zuerst bei den intensivsten Nutzer orientieren, und die nachfolgenden Schätzungen zur Maximalnutzung halten von deren Nutzungsintensität einen sicheren Abstand.
Über die öffentlichen Instanzen lässt sich üblicherweise noch ein Abfrageaufkommen abwickeln, dass weder 10000 Abfragen pro Tag noch 1 GB Downloadvolumen pro Tag überschreitet.
Zu den Zielen gehört aber auch, den Betrieb einer eigenen Instanz möglichst einfach zu gestalten. Wer seinen Bedarf auf mehr als die obigen Nutzungsgrenzen schätzt, lese also bitte die Installations-Instruktionen.
Wer dagegen mehr über die automatische Lastbegrenzung wissen will oder muss, lese bitte den folgenden Absatz.
Die automatische Lastbegrenzung ordnet Abfragen (anonymen) Benutzern zu und stellt die Erreichbarkeit für Wenignutzer sicher, wenn das Abfragevolumen aller Nutzer die Serverkapazität übersteigt.
Die öffentliche Instanz wird von zwei Servern gebildet, die beide unter overpass-api.de erreicht werden können. Normalerweise sollten Sie nicht versuchen, sich davon zu einem spezifischen Server zu verbinden. Die einzige Ausnahme davon ist als Workaround, wenn die jeweils andere Instanz auf eine Weise gestört ist, die nicht durch DNS-Round-Robin bereits behoben wird. Die gegenwärtigen Namen der einzelnen Server sind gall.openstreetmap.de und lambert.openstreetmap.de. Beide Server pflegen ihre Lastbegrezung voneinander unabhängig.
Wir beginnen mit der Erläuterung dieser Status-Abfragen.
Die Zuordnung zu Benutzern erfolgt üblicherweise per IP-Adresse.
Ist ein Benutzerschlüssel gesetzt, so wird dieser vorrangig verwendet.
Bei IPv4-Adressen wird die volle IP-Adresse ausgewertet;
bei IPv6-Adressen die oberen 64 Bit der IP-Adresse.
Für IPv6-Adressen ist noch nicht klar,
welche Gepflogenheiten sich durchsetzen,
so dass eine Verkürzung auf weniger Bits vorbehalten bleibt.
Die vom Server ermittelte Benutzernummer steht in der ersten Zeile der Status-Abfrage hinter Connected as:.
Jede Ausführung einer Abfrage belegt einen Slot des Benutzers, und zwar für die Ausführungsdauer der Abfrage plus eine Beruhigungszeit. Der Zweck der Beruhigungszeit ist, anderen Benutzern die Chance zu Abfragen zu geben. Die Beruhigungszeit wächst mit der Auslastung des Servers und proportional zur Ausführungsdauer. Bei geringer Auslastung beträgt die Beruhigungszeit nur einen Bruchteil der Ausführungsdauer, bei hoher Auslastung auch durchaus ein Vielfaches.
Eine Slippy-Map würde nun viele kurzlaufende Abfragen in kurzer Zeit absetzen. Damit ein Benutzer alle diese Abfragen beantwortet bekommen kann, gibt es zwei Kulanzmechanismen:
Rate limit:.Benötigt eine solche Slippy-Map also z.B. 20 Abfragen zu 1 Sekunde Laufzeit, ist die Anzahl der Slots gleich 2 und das Verhältnis von Abfragedauer zu Beruhigungszeit 1:1, so würden
Wenn der Benutzer die Inhalte der Abfragen 17 bis 20 noch braucht, (und nicht bereits weggescrollt hat) dann sollte das Client-Framework die Abfragen 17 bis 20 nach Ablauf der 15 Sekunden erneut stellen. Im Abschnitt über OpenLayers und Leaflet gibt es eine Referenz-Implementierung.
Die Grund für diesen Mechanismus sind Skripte in Endlosschleife: viele führen je eine Abfrage parallel aus und werden dann sinnvoll verzögert, da ihre Abfragen entsprechend verzögert Antworten erhalten.
Falls langlaufende Abfragen in der Größenordnung von Minuten den Slot belegt haben, gibt die Status-Abfrage ab Zeile 6 Auskunft darüber, wann welcher Slot wieder verfügbar ist.
Wegen des Rate-Limits abgelehnte Abfragen werden mit dem HTTP-Statuscode 429 beantwortet.
Unabhängig von diesem Rate-Limit gibt es einen zweiten Mechanismus; er bevorzugt kleine Abfragen vor großen Abfragen, damit viele Nutzer mit kleinen Abfragen auch dann noch bedient werden können, wenn die Kapazität für die Nutzer mit den größten Abfragen zusammen nicht mehr reicht.
Es gibt zwei Kriterien dafür, pro Laufzeit und pro Speicherbedarf.
Jede Abfrage enthält eine Deklaration zu ihrer erwarteten Maximallaufzeit und zu ihrem erwarteten maximalen Speicherbedarf.
Die Deklaration der Maximallaufzeit kann explizit durch ein vorangestelltes [timeout:...] erfolgen;
die Deklaration des maximalen Speicherbedarfs durch ein vorangestelltes [maxsize:...].
Beides kann kombiniert werden.
Ist bei einer Abfrage keine Maximallaufzeit deklariert, so wird eine Maximallaufzeit von 180 Sekunden gesetzt. Für den maximalen Speicherbedarf ist der Defaultwert 536870912; dies entspricht 512 MiB.
Überschreitet eine Abfrage ihre deklarierte Maximallaufzeit oder ihren deklarierten maximalen Speicherbedarf, so wird sie vom Server abgebrochen. Dieses Beispiel bricht nach 3 Sekunden ab:
[timeout:3]; nwr[shop=supermarket]({{bbox}}); out center;
Das gleiche Beispiel mit mehr Zeit funktioniert:
[timeout:90]; nwr[shop=supermarket]({{bbox}}); out center;
Der Server lässt nun eine Abfrage genau dann zu, wenn sie in beiden Kriterien höchstens die Hälfte der noch verfügbaren Ressourcen belegt. Für den maximalen Speicherbedarf ist der Wert z.B. 12 GiB. Wenn also gerade 8 Abfragen zu 512 MiB laufen, so sind 4 GiB belegt. Eine weitere Abfrage würde also genau dann zugelassen, wenn sie weniger als 4 GiB anfordert. Mit dieser neunten Abfrage zusammen wäre dann noch 4 GiB frei, so dass dann nur noch eine weitere Abfrage zu weniger als 2 GiB akzeptiert würde.
Bei der Laufzeit verhält es sich entsprechend. Der übliche Gesamtwert für zulässige Zeiteinheiten sind 262144. Es wird also eine Abfrage mit Maximallaufzeit 1 Tag recht bequem zugelassen, aber jede weitere parallele Abfrage mit einer so langen Maximallaufzeit dann abgelehnt. Der Rate-Limit-Mechanismus sorgt dann mit der anschließenden Beruhigungszeit in der Größenordnung von Tagen dafür, dass nicht immer derselbe Nutzer von einer so langen Maximallaufzeit profitiert.
Die Last aus Sicht des Servers wird per Munin angezeigt, hier und hier.
Wie beim Rate-Limit lehnt der Server zu große Abfragen nicht sofort ab, sondern wartet 15 Sekunden, ob nicht in der Zwischenzeit genügend andere Abfragen beendet worden sind.
Wegen unzureichender Ressourcen abgelehnte Abfragen werden mit dem HTTP-Statuscode 504 beantwortet.
weiter: Verwendung