Optimierung einer 4 Jahre alten Java Web-Anwendung

Die CRM Software FOXCRM wurde in den Jahren 2004 – 2005 entwickelt. Zusammen mit meinem Geschäftspartner Thomas Küspert von catosero IT-Consulting habe ich damals die Software für unseren gemeinsamen Kunden entwickelt. Weiter beteiligt war eine Mitarbeitern des Kunden.

Als Technologie war vom Kunden Java vorgegeben. Die Software wurde mit Apache Tomcat 4.x als Web-Container, MySQL 4.x mit Hibernate 2.x / 3.x als Datenbank-Schicht und Struts als MVC realisiert. Inzwischen wird die Software ohne Änderungen unter Tomcat 5.0 und MySQL 5.0 betrieben.

Nach mehr als 4 Jahren im produktiven Einsatz war es 2009 an der Zeit eine Überarbeitung der Software bzgl. der Performance vorzunehmen.

Ausgangspunkt für die Optimierung

Im Laufe der Jahre waren vom Kunden mehr als 3.000 Unternehmen in das System eingepflegt worden. Zu jedem Unternehmen waren mindestens 1 meistens aber 2 – 3 Kontakte eingetragen / zugeordnet. Da die Hauptaufgabe eines CRM Systems die Pflege der Kontakte des Kunden beinhaltet, waren zu jedem Kontakt fleißig Gesprächsnotizen, Termine, eMails und Dokumente eingetragen.

Von den Anwendern wurde die Reaktionszeit des Systems insgesamt bemängelt. Nach einigen Befragungen kristallisierten sich allerdings die folgenden konkreten Funktionen heraus, die optimiert werden müssen:

• Ermittlung und Darstellung der noch nicht abgeschlossenen Wiedervorlagen

• Zuordnung von neu eingetroffenen E-Mails zu den Kontakten mit der entsprechenden E-Mail Adresse im CRM Bereich

• Beschleunigung des Zugriffs auf nicht zugeordnete E-Mails

• schnelleres Login durch beschleunigten Aufbau der Startseite nach Eingabe von Benutzername und Kennwort

Dürfte ich ein derartiges System heute noch einmal erstellen, würde ich die zugrundeliegende Architektur anders aufbauen. Damals haben wir neben einer relativ schlanken Service-Schicht für den Zugriffe auf die Datenbank die gesamte Logik in die Controller (Actions) von Struts gesteckt.

Ansätze zur Optimierung der Service-Schicht

Nach einigen Messung stellte sich heraus, dass der Großteil der Zeit in der Service-Schicht benötigt wird. Mit den Arbeiten an der Optimierung der Services konnte ich aber noch nicht sofort beginnen. Erst mussten – zumindest für die zu ändernden Methoden – Unit-Tests geschrieben werden. Damit war es mir in den nun folgenden Optimierungsschritten immer möglich, die Korrektheit der Implementierung nach verschiedenen Änderungen zu überprüfen.

Die Optimierungen selbst konnten größtenteils durch geänderte Zugriffe auf die Datenbank und die bessere Formulierung der HQL Statements durchgeführt werden:

• Nutzung der Möglichkeit von Joins in HQL, statt der Ausführung von mehreren HQL Anweisungen, deren Ergebnisse aufeinander aufbauen.

• Nutzung der Filter beim Zugriff auf IMAP Ordner mittels JavaMail: Es werden nur die zu prüfenden E-Mails ermittelt. Die Inhalte aller anderen E-Mails werden nicht angefordert bzw. geprüft.

• Sortierung mittels entsprechender compareTo Überschreibungen und der Nutzung von SortedSets.

Die aufgeführten Optimierungen sind aus heutiger Sicht nichts besonderes. Einige wundern sich vielleicht, warum die Möglichkeiten von HQL und JavaMail nicht von Anfang an genutzt worden sind.

Die eingesetzten Techniken waren für alle damals Beteiligten relativ neu. Es fehlte die Erfahrung sowohl beim Design / der Architektur als auch beim Einsatz von Hibernate und JavaMail. Dieses Wissen wurde nach gut 4 Jahren in die Software “eingebracht”.

Ergebnis - zufriedene Kunden

Was für den Kunden einzig und allein zählt ist das Ergebnis. Und das kann sich durchaus sehen lassen. Die Reaktionszeiten wurden an allen aufgeführten Punkten erheblich verbessert. Alle Anwender arbeiten jetzt wieder gerne mit dem System.

Vor der Optimierung konnte man z.B. nicht davon ausgehen, dass alle Kontakte mit einem Kunden auch in das System eingegeben wurden. Aufgrund der langsamen Reaktion wurden die eigentlich notwendigen Eingaben nicht vorgenommen. Jetzt werden wieder alle Kontakte in das System eingegeben. Das System "`bremst"` die Mitarbeiter nicht mehr bei ihren Tätigkeiten aus.

Fazit

Für mich als Entwickler bleibt als Ergebnis, dass das eigene Wissen, das Know-How und die Erfahrung in 4 Jahren erstaunlich zunehmen. Damals eingesetzte Techniken sehe ich jetzt aus einem anderen Blickwinkel. Viele “Fehler” aus meinem damaligen Code mache ich heute nicht mehr. Aus heutiger Sicht “umständlichen” Code kann ich einfacher, übersichtlicher und “schöner” formulieren.

Dank eclipse waren auch umfangreichere Refactoring kein Problem und so wurde neben der Performance des Systems auch die Qualität des Codes ein klein wenig verbessert. Dank Unit-Tests hatte ich keine Angst, durch meine Änderungen Fehler an anderen Stellen der Software zu verursachen. Ein schöne Beispiel dafür, dass sich der Aufwand zur Erstellung von Unit-Tests mehr als rechnet.