"availability" zu langsam in CommonsBooking API

[nelarsen]

Für unsere Karte auf friedafriedrich.de (und künftig Teilrad Sachsen) nutzen wir die CommonsBooking API. Leider ist die "availability"-Abfrage (Link) oft sehr langsam (bis über 5s - insbesondere wenn die Buchungslage sich seit dem letzten Aufruf verändert hat) und es verzögert die Anzeige der Lastenräder auf der Karte merklich. Unsere Karte verwendet daher nicht die "availability"-Abfrage von commonsbooking, sondern einen täglichen Cache davon (Link). Ich würde zur Karte gern einen "heute verfügbar"-Filter hinzufügen oder "Verfügbar am dd.mm.yyyy", aber bräuchte dann immer die aktuelle Buchungslage keinen stundenalten Cache.

Was macht die Verfügbarkeitstabelle anders? Sie enthält die gleichen Daten wie "availability", aber ist eine Größenordnung schneller.

Bei "availability" stört außerdem etwas, dass sie nur Daten für die nächsten 14 Tage zurückgibt (Wert nicht konfigurierbar) und ich erkenne im Code gar nicht, wo das so vorgegeben ist.

[datengraben]

@nelarsen

Das Problem der Performance ist ja schon an andere Stelle diskutiert worden. Die jüngste Diskussion mit konkretem Lösungsvorschlag liegt in diesem Issue und könnte eure bisherige Vorgehensweise mit dem Cache unterstützen. Diese Lösung ist von hans dort beschrieben. Kurz: Ihr könntet den Cache (unabhängig vom Aufrufer/Aufrufzeitpunkt) regelmäßig (z.B. alle 5 oder 10 Minuten) neu berechnen.

Bis zur Umsetzung des Vorschlags von Hans kannst du versuchen den Cache durch regelmäßigen Aufruf (von außen, z.B. per cronjob/Skript) selber zu erneuern. Dann brauchst du dich nicht auf die schnell veralteten Tages-Werte zu verlassen.

Der Code für die Einstellung der 14 Tage ist hier: https://github.com/wielebenwir/commonsbooking/blob/master/src/API/AvailabilityRoute.php#L49

[nelarsen]

Danke @datengraben! Ich habe der anderen Diskussion parallel gefolgt. Wir sind uns vermutlich einig, dass die regelmäßige Cache-Neuberechnung eigentlich eine schlechte Lösung ist. (Wenn es überhaupt eine Lösung ist, denn vermutlich häufig wird jemand die Karte mit den Lastenrädern aufrufen unmittelbar nachdem er ein Lastenrad gebucht bzw. storniert hat. Dann ist die Karte entweder veraltet oder der Aufruf langsam - bis zur Cache-Neuberechnung.) Ich würde mich freuen, wenn wir das Datenmodell perspektivisch angepasst bekommen, sodass performante Abfragen ohne Cache möglich sind.

Ich finde es nur interessant, dass die cb2-Verfügbarkeitstabelle dagegen schnell bereitgestellt wird. Die enthält genau die Infos, die ich von der API benötige, aber wird eine Größenordnung schneller generiert. Was macht die availability-API langsamer als die Verfügbarkeitstabelle?

Danke auch für den Hinweis mit den 14 Tagen. Ggf. erstelle ich ein PR, um es über die API-Abfrage parametrisierbar zu machen. Aber zuerst muss ich überlegen, wie ich mein konkretes Problem mit der nichtperformanten Karte eigentlich lösen möchte. Vielleicht bastele ich übergangsweise eine eigene Abfrage, die ggf. schneller ist.

[nelarsen]

Ich bin noch dran und melde mich noch. Ich stolperte zuerst über andere Issues und muss mir morgen dringend meiner richtigen Arbeit widmen. (-: