Alternativer vollständiger Export für mehr Performanz

[j3nsch]

Größere Exports können den Server überlasten. Das hat verschiedene Gründe. Es soll ein alternativer Export implementiert werden, der eine deutliche Verbesserung der Performanz bringt. Im ersten Schritt sollen alle veröffentlichten Dokumente exportiert werden. Gelingt das, können die Verbesserungen auch auf andere Exports übertragen werden.

Ein vollständiger Export erlaubt es die Suche aus der Implementation heraus zu nehmen. Die Suche instanziiert sämtliche Dokumente. Das ist für einen effizienten Export ein Problem. In der aktuellen Implementation sind der Code für die Ermittlung der zu exportierenden Dokumente, die Suche, und der eigentlich Export-Code, fest mit einander verdrahtet. Das sollten in Zukunft zwei unabhängige Komponenten werden.

Beim eigentlichen Export wird ein XML Dokument mit sämtlichen zu exportierenden Metadaten gebaut und dann mit XSLT in das Export-Format umgewandelt. Dadurch wird es immer eine Obergrenze geben, bei der Speicher oder Festplatte nicht mehr ausreichen, um die Anzahl an Dokumenten zu bewältigen. Der Speicherverbrauch von Dokumenten kann reduziert werden und das ist eine weitere Optimierung, die mit einer neuen Implementation der Datenbankanbindung erreichbar sein wird. Das wird die Obergrenze erhöhen, aber nicht beseitigen.

Um beliebig große Exports bewältigen zu können muss die Transformation ins Export-Format für jedes Dokument einzeln stattfinden und die Ergebnisse müssen kontinuierlich an den Client übertragen werden, ohne das der gesamte Export lokal zwischengespeichert werden muss.

Beim BibTeX-Format gibt es z.B. keinen Wrapper, der die Dokumente umschließt. Ein BibTeX-Eintrag nach dem anderen kann in die Ausgabe geschrieben werden. Bei anderen Formaten muss unter Umständen zuerst ein Header und am Ende ein Footer übertragen werden.

Der Schlüssel, damit das funktionieren kann, ist herauszufinden wie ein Ergebnis mit Zend bzw. Laminas an den Client übermittelt werden kann. Im Normalfall werden Antworten in den Frameworks vollständig generiert bevor eine Übermittlung stattfindet. Es gibt Hinweise, dass ein Streaming möglich ist, aber bisher habe ich noch keine gute Dokumentation dazu gefunden. Das ist das erste technische Problem, das gelöst werden muss für einen unbegrenzten Export.

[j3nsch]

Im Rahmen der Entwicklung sollten Export-Kommandos implementiert werden, die mit dem alten Verfahren und dem neuen funktionieren, um Vergleiche anstellen zu können. Vollexports über den Server sind mit der alten Implementation häufig nicht möglich.

@sigwei, @alw-bsz Nutzen Instanzen Vollexports? Wie sind die Erfahrungen?

[j3nsch]

Nach der Proof-of-Concept Implementation macht es Sinn, die alten Formaten schrittweise zu übertragen und ein vollständiges neues Export-System aufzubauen. Idealerweise gleich mit dem Code auf verschiedene Packages für die einzelnen Formate verteilt, so dass neue Formate später als separate Packages umgesetzt und hinzugefügt werden können.

[alw-bsz]

Nutzen Instanzen Vollexports? Wie sind die Erfahrungen?

Ja, hin und wieder benötigen die Anwender einen Export aller Datensätze.