{"action":"created","issue":{"url":"https://api.github.com/repos/OParl/spec/issues/315","labels_url":"https://api.github.com/repos/OParl/spec/issues/315/labels{/name}","comments_url":"https://api.github.com/repos/OParl/spec/issues/315/comments","events_url":"https://api.github.com/repos/OParl/spec/issues/315/events","html_url":"https://github.com/OParl/spec/issues/315","id":107788168,"number":315,"title":"Kapitel zum Thema \"Rate Limits\"","user":{"login":"konstin","id":6826232,"avatar_url":"https://avatars.githubusercontent.com/u/6826232?v=3","gravatar_id":"","url":"https://api.github.com/users/konstin","html_url":"https://github.com/konstin","followers_url":"https://api.github.com/users/konstin/followers","following_url":"https://api.github.com/users/konstin/following{/other_user}","gists_url":"https://api.github.com/users/konstin/gists{/gist_id}","starred_url":"https://api.github.com/users/konstin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/konstin/subscriptions","organizations_url":"https://api.github.com/users/konstin/orgs","repos_url":"https://api.github.com/users/konstin/repos","events_url":"https://api.github.com/users/konstin/events{/privacy}","received_events_url":"https://api.github.com/users/konstin/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-09-22T19:50:53Z","updated_at":"2015-09-23T15:42:41Z","closed_at":null,"body":"Das Stellen vieler komplexer Anfragen kann dazu führen, dass ein Server überlastet wird, und im schlimmsten Fall für einige Zeit nicht erreichbar. Diese Problematik sollte in einem eigenen Kapitel erläutert werden, in dem auch erklärt werden sollte, wie server-Betreiber das verhindern können und wie server clients mitteilen, dass sie eine Anfrage wegen der Gefahr von Überlastung bzw. wegen rate limits nicht beantworten."},"comment":{"url":"https://api.github.com/repos/OParl/spec/issues/comments/142643435","html_url":"https://github.com/OParl/spec/issues/315#issuecomment-142643435","issue_url":"https://api.github.com/repos/OParl/spec/issues/315","id":142643435,"user":{"login":"lu-j","id":12373319,"avatar_url":"https://avatars.githubusercontent.com/u/12373319?v=3","gravatar_id":"","url":"https://api.github.com/users/lu-j","html_url":"https://github.com/lu-j","followers_url":"https://api.github.com/users/lu-j/followers","following_url":"https://api.github.com/users/lu-j/following{/other_user}","gists_url":"https://api.github.com/users/lu-j/gists{/gist_id}","starred_url":"https://api.github.com/users/lu-j/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lu-j/subscriptions","organizations_url":"https://api.github.com/users/lu-j/orgs","repos_url":"https://api.github.com/users/lu-j/repos","events_url":"https://api.github.com/users/lu-j/events{/privacy}","received_events_url":"https://api.github.com/users/lu-j/received_events","type":"User","site_admin":false},"created_at":"2015-09-23T15:42:41Z","updated_at":"2015-09-23T15:42:41Z","body":"So wie ich das bis jetzt beobachtet habe, sind die RIS-Server in den meisten Fällen hinter einem Webserver, der dann auch die Fehlermeldung inkl. Statuscode ausgibt, wenn das RIS nicht innerhalb eines Timeouts (z.B. 90 Sekunden) geantwortet hat. Ich denke das wird dann auch passieren, wenn das RIS wegen zu vielen Anfragen überlastet wird. Die RIS-Software wird also vermutlich sowieso nicht immer selbst entscheiden können welche Fehlermeldung und welcher Statuscode ausgegeben wird. Ich vermute rate limiting würde man auch eher über den Webserver oder den Reverse Proxy machen und es nicht im RIS-Server implementieren.\r\n\r\nIch denke Tipps zur Vermeidung von Überlastung speziell für OParl können wir nicht geben. Was wir von unserer Seite tun könnten ist, dass wir festlegen, dass man nur die Änderungen seit einem bestimmten Tag abrufen kann, ohne Angabe einer Uhrzeit. Damit würde die täglich synchronisierenden Clients die selben Anfragen stellen und man könnte die Antwort auf der Serverseite cachen. Ich denke das wird aber nicht notwendig sein. Wenn man täglich synchronisiert dauert es nur wenige Sekunden und sollte weniger Last verursachen als ein durchschnittlicher Besucher der RIS-Weboberfläche. Das erste Synchronisieren wird natürlich viel Last verursachen, aber das ist ja auch nur einmal nötig. Clients müssen immer auf die Antwort vom Server warten um über \"nextPage\" den Link zur nächsten Seite zu bekommen, daher werden sie nicht viele parallele Anfragen machen und ein rate limiting wird nicht notwendig sein.\r\n\r\nÜber den Spiegelserver wollen wir auch Dumps anbieten. Ich denke es werden sich viele, die OParl kennenlernen wollen, erst mal einen Dump von unserem Server laden, was dann auch die RIS-Server entlastet. Ich denke die Anzahl der OParl-Anwendungen wird sowieso überschaubar bleiben, sodass wir uns wegen Überlastung keine Gedanken machen müssen.\r\n\r\nWenn es beim Synchronisieren zu einem Fehler kommt, sollte ein Client am Besten den Fehler ausgeben, dann kurz warten und das Synchronisieren erneut starten. Sollte es wiederholt zu Fehlern kommen, sollte er abbrechen. Der Client wird ja in der Regel zum nächsten eingeplanten Synchroniserungszeitpunkt erneut gestartet. Ich denke das ist als Fehlerbehandlung erst mal ausreichend."}}