Seit der letzten großen Umstellung von OpenBib in eine REST-basierte Infrastrukturlösung sind bereits etwas mehr als 2 Jahre ins Land gegangen in denen sich in der Perl-Welt – und darüber hinaus – einiges getan hat.

Mehr Möglickeiten mit PSGI

Eine der Entwicklungen betrifft das in die Jahre gekommene Common Gateway Interface (CGI) für Web-Anwendungen. Dieses wird in der Perl-Welt nun mehr und mehr durch ein moderneres Verfahren abgelöst: PSGI, die Perl Web Server Gateway Interface Specification. Inspiriert von WSGI aus der Python-Welt wird durch die Verwendung der PSGI-Spezifikation eine Abstraktionsebene in die Web-Anwendung eingeführt, so daß diese fortan unabhängig vom verwendeten Webserver wird.

Das führt unmittelbar zu deutlich mehr Auswahl an Betriebsmöglichkeiten mit Web- oder besser gesagt PSGI-Servern unter denen die Anwendung ohne Code-Anpassungen betrieben werden kann – egal ob mit Apache2 unter mod_perl oder mod_psgi, FastCGI, uWSGI-basierten Servern, neuen Perl-Servern wie starman oder das mitgelieferte Plack, nginx mit embedded perl und insbesondere auch stand-alone Perl-Programme, mit denen die Anwendung aufgerufen werden kann. Gerade durch letzteres eröffnen sich deutlich verbesserte Debugging- und Testmöglichkeiten, da ein Web/PSGI-Server dazu gar nicht benötigt wird. Die Requests werden einfach an die PSGI-Schicht der Anwendung selbst geschickt.

Zusätzliche Flexibilität geben sogenannte Middlewares, dass sind Verarbeitungsschichten, die in den Abarbeitungsfluss – ähnlich den Request-Cycles in mod_perl – eingreifen und Inhalte on-the-fly verändern können. Beispiele sind z.B. Debugger, Profiler, Umleitung statischer Inhalte (css,images) in Verzeichnisse, SizeLimits als Gegenmaßnahme zu sich aufblähende Server-Prozesse usw.

Bei der Umstellung auf PSGI haben wir den alten CGI-Modulen vollständig den Rücken gekehrt. Dementsprechend sind in OpenBib auch nicht die Perl-Module CGI::PSGI oder CGI::Emulate::PSGI im Einsatz, mit denen wir Ballast von CGI (und speziell CGI.pm) dann doch weiterhin mit uns herumgeschleppt hätten. Stattdessen haben wir auf Grundlage von Plack::Request ein eigenes Request-Modul OpenBib::Request erstellt, das von Plack::Request erbt.

Für den Einsatz haben wir verschiedene PSGI-Server getestet und gebenchmarkt. Informationen dazu finden sich im Wiki-Artikel „Umstellung auf PSGI„. Unsere Wahl fiel auf den PSGI-Server starman. Dieser beinhaltete den besten Mix aus Performance und Zuverlässigkeit. Wie schon mit Apache2/mod_perl ist ihm ein lighttpd und haproxy vorgeschaltet.

Interessant sind in dieser Hinsicht unsere Benchmarks mit Apache Bench, um die optimale Zahl an Workern für die beste Performance zu bestimmen. Die Benchmarks sagen aus, dass das Optimum bei 4 Workern liegt. Die Realität sieht hier leider vollkommen anders aus. Mit 4 Workern hält der KUG im Produktionsbetrieb gerade einmal 30 Sekunden aus, bevor er keine Anfragen mehr beantwortet. Daher betreiben wir ihn jetzt zuverlässig mit 20 Workern ohne jegliches Problem. Zum Vergleich: Vorher unter Apache2/mod_perl hatten wir 50 Worker (preforked processes) im Einsatz…

Insgesamt bedeutet PSGI für OpenBib mehr Flexibilität, Einsatzmöglichkeiten (z.B. Web-Spaces mit FastCGI-Support) sowie eine erhöhte Zukunftsfähigkeit als die bisher von OpenBib verwendete konventionelle Web-Serverarchitektur aus Apache2 und mod_perl. Der Preis hierfür war ein sehr umfangreicher Umbau des Programmcodes von OpenBib.

Responsive Webdesign statt eigene Mobil-Version

Ein weiterer Trend bei Webanwendungen ist die einheitliche Bereitstellung der Inhalte über alle Aufruf-Plattformen wie Smartphone, Tablet oder PC hinweg. Komplett separate „Mobil-Versionen“ sind out. Stattdessen wird das von der Web-Anwendung gelieferte HTML je nach Aufruf-Plattform durch CSS3 mit Media-Queries und gegebenenfalls JavaScript so aufbereitet, dass eine an die vorhandenen Gegebenheiten (Bildschirmgröße) optimierte Darstellung und Nutzbarkeit gewährleistet ist. Gerade hier hatte OpenBib deutlichen Nachholbedarf, da die Web-Version sich nur mühsam auf Smartphones und Tablets nutzen ließ und die anvisierte „Mobil-Variante“ nie zum Einsatz kam. Daher wurden die CSS im Rahmen von Responsive Webdesign für den Kölner UniversitätsgesamtKatalog KUG komplett überarbeitet.

In den folgenden Screenshots ist die Darstellung des KUG für verschiedene Bildschirmbreiten aufgeführt.

 

 

 

 

Ausgehend von der vollständigen Darstellung wurden für immer kleiner werdende Bildschirmauflösungen sukzessiv Änderungen vorgenommen:

• Anpassung der Suchschlitzbreite und der Logos im Banner-Bereich
• Reduktion erweiterter Suchmöglichkeiten
• Entfernung der Icons für andere Repräsentationen der Seite
• Einklappen zusätzlicher Inhalte für mehr Übersichtlichkeit
• Entfernung der Breadcrumb-Navigation, weil schlicht die Bildschirmbreite nicht mehr ausreicht
• Vergrößerte Schrift zur besseren Selektion auf Touch-Displays

Nicht alles hiervon ist optimal, in der Regel immer dann, wenn Informationen oder Bedienelemente entfernt wurden, wie bei der Breadcrumb-Navigation. Hier wird es sicherlich zukünftig weitere Verbesserungen geben. Andererseits erhöht eine solche Reduktion auf das Wesentliche häufig die Übersichtlichkeit und damit die Usability. Insofern stellen wir uns auch die Frage, ob an einigen Stellen überhaupt Handlungsbedarf besteht. Verglichen mit der bisherigen Version führen die Änderungen aber zu einer deutlich erhöhten Nutzbarkeit.

Weitere Optimierungen

Über PSGI und Responsive Webdesign hinaus wurden viele Bereiche im Programmcode optimiert. Dazu gehört insbesondere die Nutzung von Datenbankverbindungen. Hier gab es in den letzten zwei Jahren drei Mal ein „Aufschaukeln“ der Verbindungen zur zentralen Systemdatenbank, so dass der KUG für einige Stunden nicht erreichbar war. Beteiligt waren hierbei der Connection Spooler pgbouncer, der übermäßig Verbindungen im Idle-Zustand beließ anstelle sie zu schliessen, und einige Singleton-Objekte im Code, die ebenfalls bereits bestehende Verbindungen nicht immer wiederverwendeten, sondern zum Teil neu aufbauten.

Bereits der Verzicht auf pgbouncer hatte deutliche Verbesserungen gebracht und auch die Performance hatte darunter nicht spürbar gelitten. Für die neue Version wurden alle Singleton-Objekte mit Datenbankverbindungen eliminiert und durch „normale Objekte“ ersetzt. Die Folge war eine nun nötig gewordene umfassende Umstrukturierung des Programmcodes.

Sehr schön demonstriert die Grafik des Verlaufs der PostgreSQL-Verbindungen über die letzten 12 Monate. Die grün eingekreisten Stellen zeigen die Zahl der Datenbankverbindungen mit der neuen OpenBib Version 3.1, die seit einigen Wochen beim KUG im Einsatz ist.

Zahlen

Wieviel hat sich nun konkrete in Zahlen von OpenBib 3.1 zur letzten Version 3.0 getan. Git ist unser Freund:

git diff –stat origin/master origin/stable-3_0-mod_perl-branch — ‚*’|tail -1
1108 files changed, 70801 insertions(+), 50292 deletions(-)