Starker Performance (& Usability)-Verlust bei vielen Einträgen

fodinabor

Halli hallo,

Wir sind momentan dabei unsere Liederdatenbank zu importieren... sind so 5000 Lieder.

Ich sags mal so macht grad nicht mehr soo viel Spaß die Liederseite aufzurufen (lädt erstmal die 4,5MB Songdaten).
Das ist prinzipiell ja kein Problem, wenn man nicht grad so ne miese Leitung hat, wie ich momentan... Die Motivation die Seite mobil aufzurufen, sinkt aber auf jeden Fall rapide.. (davon abgesehen scheint die Anfrageverarbeitung dafür auch gerne mal ein Weilchen zu brauchen... Der Import läuft über die CT API von einem externen Server aus, mit 1 Gbit/s Leitung nicht unbedingt über Bandbreitenprobleme klagen sollte. Für den Import muss auf Grund des API Designs - und eventuell Faulheit des Entwicklers des Importers hust, sorry - die Songliste relativ häufig neu laden... da sind knapp 3 Sekunden bis zu 15 Sekunden normal. Andere API Calls laufen in unter 0.1sek, was eher meinen Erwartungen entspricht...)

Wenn ich mir jetzt vorstelle, dass die Benutzerliste bei 10.000 Mitgliedern in einer Gemeinde (oder Besuchern bei einem Event) ebenfalls komplett geladen wird, stelle ich mir doch recht schnell die Frage, ob das wirklich sinnvoll ist, die gesamte Filterung und co. auf den Client (Browser) auszulagern und dafür alle Benutzerdaten zu transferieren...
Ich kenne das von anderen Systemen eher, dass die Filterung auf Serverseite vorgenommen wird (prominentes Beispiel: Google, oder was eher in die Richtung von CT geht und meiner Meinung nach eine wunderbare Performance bietet: EspoCRM)

Ich weiß, dass das nichts ist, was man von heute auf morgen ändern kann, würde euch aber dennoch bitten, euch zu überlegen, ob ihr das nicht ändern könnt.. Dafür muss natürlich auch die API angepasst werden, die dann mehr Parameter zulassen muss, die einem Filterung erlauben (z.b. Ranges).
In dem Zuge könnte man auch so Funktionen wie getSong brauchen, was ich bei dem Importer schmerzlich vermisst habe, und ihr hoffentlich nicht am Netzwerktraffic gemerkt habt...

Viele Grüße im Namen von zwei Gemeinden
Joachim

P.S.: mir ist gerade aufgefallen, dass die Daten für den Browser mit gzip encoded sind -> keine 5MB - nur 700kB, aber Ladezeit ist trotzdem noch bei >10sek.

Marcel

@fodinabor laut Gerüchten ist eine neue API in Entwicklung & teilweise auch bereits genutzt (bspw. für die Token)

Vielleicht werden so auch Schritt für Schritt diese Entpunkte ersetzt / ergänzt. Hoffentlich wird dann auch auf Pagination gesetzt & diese implementiert.

hbuerger

Hallo @fodinabor,

danke für deinen Input. Du sprichst da einen wichtigen Punkt an und Ihr seid auch nicht einzigen, die sich daran aufreiben. Aber wie @Marcel schon richtig sagte, wir arbeiten gerade daran eine neue RESTful API zu entwickeln. Durch die Komplexität von ChurchTools dauert das aber noch einige Zeit bis wir alles komplett umgestellt haben.

Zum Thema Performance: Vielen ist das nicht bewusst, aber ChurchTools ist über 10 Jahre alt und wurde damals entwickelt, als viele Best Practices noch gar kein Thema waren. Wir arbeiten kontinuierlich dran alten Code in neuen besseren Code zu verwandeln, aber das ist eine riesen Aufgabe.

Wir behalten die Performance immer im Blick gerade wenn es um die neue API geht und Pagination ist da nur einer von vielen Faktoren.

Wann die neue API fertig bzw. wenn wir die Song API anpassen kann ich dir leider nicht sagen. Aber mit Sicherheit steht fest, wenn wir die Song API anpassen, wird sie performanter.

Ich hoffe ich konnte dir ein wenige weiterhelfen, zumindest zu verstehen warum CT gerade so ist wie es ist.

fodinabor

Vielen Dank @hbuerger für die Antwort.
Joa.. das mit dem 10 Jahre alten Code kenne ich ganz gut..

Dann auf jeden Fall mal viel Erfolg bei dem Umbau und ich bin gespannt auf das Ergebnis. Bin hoffentlich bald fertig mit den API Imports... (wird aber wohl immer mal was geben... :D)

Btw.. so biiisschen mehr doku wäre fantastisch.. so.. was mögliche Parameter sind... nur die liste davon würde mir persönlich vollkommen reichen... so muss man sich das alles seeehr mühsam zusammen testen...

hbuerger

Die alte API Dokumentation ist ein kraus. ^^ Aber die Arbeit diese zu überarbeiten wäre vergeudete Liebesmühe. Da entwicklen wir doch lieber an der neuen API weiter und an deren Dokumentation. Die neue Doku wird auf jeden Fall verständlicher, was Request Types, Parameter angeht.

fodinabor

Ja, das ist sie

Das stimmt - war primär als Bitte gemeint da bei der neuen API wirklich drauf zu achten
(ich weiß dokumentieren macht keinen Spaß... ist bei APIs aber wirklich hilfreich :P)

davidschilling

@fodinabor Mit der nächsten Version wird jetzt die neue Song-Api rauskommen.