Katalogsysteme im Test

Paul Dachtler ist Vorstand (CTO) bei der Heiler
Software AG in Stuttgart
NET 12/03
Im IT-Umfeld werden Leistungsmessungen
seit vielen Jahren dazu verwendet,
um die Performance von Rechensystemen
zu bewerten. Unterschiedliche
und oft sehr individuelle
Ansprüche an die Verfahren machten
es dabei schon immer schwer, die passende
Methode zu finden. Denn sie
soll zuverlässige Aussagen über die
Leistung eines Systems unter genau
der Last treffen, die für einen Anwender
wichtig ist. Daher ist es naheliegend,
nicht eine Sammlung synthetischer
Programme zur Leistungsbewertung
zu verwenden, sondern die Leistungsfähigkeit
von Anwendungen
vor dem Hintergrund tatsächlicher
Abläufe im Unternehmen zu testen.
Dies gilt insbesondere für Tests, die
sich mit der Leistungsfähigkeit von
Beschaffungslösungen befassen. Gefragt
ist daher ein Verfahren, das relevante
Business-Aspekte auf Basis eines
realistischen Szenarios überprüft.
Anforderungen auf der
Buy Side
Bereits seit geraumer Zeit nehmen die
Benutzerzahl und die Menge des Produktdaten-Contents
in den Katalogen
der beschaffenden Unternehmen stetig
zu. Daraus ergeben sich hohe Per-
KOMMUNIKATIONSMANAGEMENT
Katalogsysteme im Test
Simulation eines realistischen Beschaffungsszenarios
Paul Dachtler
Bislang gab es für
Beschaffungslösungen keine
allgemein anerkannten Prozeduren
oder Benchmarks, mit denen
Aussagen über die Leistungsfähigkeit
eines Katalogsystems auf einer
bestimmten Serverplattform gemacht
werden konnten. Synthetische und
damit rein theoretische Werte, die auf
Verfahren des Transaction Processing
Performance Councils (TPC) beruhen,
führen zu keinen sinnvollen
Aussagen. Gefragt sind daher
praxisorientierte Tests, wie in diesem
Beitrag beschrieben, die es
ermöglichen, nachprüfbare Werte für
die Performance und die
Skalierbarkeit von elektronischen
Katalogsystemen zu ermitteln.
Das Thema in Kürze
Die elektronische Beschaffung und
das Bereitstellen elektronischer Kataloge
erhalten in den Unternehmen
eine Schlüsselfunktion – Katalogmanagementlösungen
und die Lieferantenintegration
werden zu zentralen
Komponenten. Da es im Beschaffungsumfeld
noch keine Testverfahren
für Katalogsysteme gibt,
entwickelte man bei der Heiler Software
AG gemeinsam mit Sun Microsystems
den im Beitrag beschriebenen
speziellen Leistungstest.
formance- und Lastanforderungen an
das Katalogsystem. Behäbige Lösungen
mit langen Antwortzeiten senken
die Akzeptanz der Benutzer.
Höhere Beschaffungsvolumina über
die Procurement-Plattform lassen sich
nur durch die Einbeziehung zusätzlicher
aktueller Produktsortimente abwickeln.
Notwendig sind daher neben
einer Optimierung der Prozesse auch
schnelle Updatezyklen des Contents.
Anforderungen auf der
Sell Side
Der Bedarf der Einkäufer an hochwertigen
Informationen und standardisierten
Formaten nimmt zu. Hersteller
und Distributoren müssen aktuellen
elektronischen Content schnell liefern.
Als Hürde einer raschen und
kontinuierlichen Bereitstellung von
elektronischem Catalog Content an
die Kunden erweisen sich häufig fehlende
oder falsche Produktinformationen,
die beispielsweise im Vertrieb
oder in Niederlassungen entstehen.
Daraus resultiert dann oft ein unbrauchbarer
Datenbestand. Veraltete
und redundante Informationen ergeben
sich auch dann, wenn Produktstammdaten
in unterschiedlichen Anwendungen
und in verteilten Systemen
gehalten werden. Als Lösung
wird deshalb in vielen Fällen ein zentralesProduktdatenmanagementsystem
angestrebt, das Benutzern die
Möglichkeit bietet, Produktdaten und
Kataloginhalte schnell zu erstellen, zu
pflegen und zu verteilen.
Leistungstest von Katalogsystemen
Im Beschaffungsumfeld gibt es noch
keine allgemein anerkannten Testverfahren,
die Aussagen über die Performance
eines Katalogsystems auf einer
bestimmten Hardware ermöglichen
würden. TPC-C-Werte führen hier zu
15

Katalogsysteme im Test
keinerlei verwertbaren Aussagen und
müssen durch entsprechende Application-Tests
(Benchmarks) ersetzt werden.
Daher entwickelte die Heiler
Software AG gemeinsam mit Sun
Microsystems in deren Testcenter in
Langen einen Leistungstest mit dem
Heiler Premium Business Catalog (PBC
in der Version 2.5.2). Er widmet sich
speziell dem Thema Performance in
einer gegebenen Hardwareumgebung
und der Frage, wie zusätzliche
Prozessoren in den Servern die Leistungsfähigkeit
beeinflussen (Skalierbarkeit).
Der Premium Business Catalog
(PBC) ist das führende elektronische
Katalogsystem, mit dem große
Unternehmen ihre Beschaffung organisieren.
Eine hohe Benutzerfreundlichkeit,
effiziente Suchstrategien sowie
die optimale Integration in unterschiedliche
Beschaffungssysteme sind
wesentliche Merkmale des PBC. Er bildet
damit das Kernstück einer E-Procurement-Lösung.
Auf Basis der Sun Fire-Server mit Ultra-Sparc-III-Architektur
und Solaris 8
wurden in umfangreichen Testläufen
sowohl die Stärke der Sun-Technik als
auch die hohe Qualität der Heiler-
Software in Verbindung mit Oracle 9i
als Datenbankmanagementsystem
und BEA Weblogic als Applikationsserver-Infrastruktur
untersucht.
Das Anforderungsszenario des Application
Benchmarks geht von einem
internationalen Großunternehmen
mit rund 25.000 Named Usern aus.
Sie wickeln gemeinsam im indirekten
Bereich ein Beschaffungsvolumen von
mehr als 1 Mrd. € pro Jahr über die
Katalogplattform ab. Dies entspricht
etwa 100.000 Bestellvorgängen pro
Monat und ca. 50 parallelen Bestellvorgängen.
Aufgrund der globalen
Ausrichtung des potentiellen Anwenders
wird ein „internationaler“ Arbeitstag
von 18 h vorausgesetzt (Zeitzonen
Nordamerika bis Europa).
Die Tests bestanden aus komplexen
Abläufen, wie sie heute in produktiven
Beschaffungssystemen vom
Frontend bis zur Datenbank realisiert
sind. Die Antwortzeiten zwischen
dem Auslösen einer Aktion am Frontend
(Webbrowser) und der Präsentation
des entsprechenden Ergebnisses
durfte durchschnittlich 2 s nicht über-
Bild 1: Einzelne Komponenten des Anwendungsszenarios
wie Datenbank und Web-Applikationsserver
wurden auf mehrere Systeme
verteilt
schreiten. Als Datenbasis wurde ein
Katalog mit 5 Mio. Produkteinträgen
gewählt. Dieses Sortiment entspricht
dem Beschaffungsvolumen eines international
tätigen Konzerns. Da Kataloglösungen
in der Regel hochverfügbar
sein müssen, wurden Messungen
mit gleichmäßiger Lastverteilung
über einen Zeitraum von mindestens
12 h durchgeführt.
Die Simulation des realistischen Szenarios
basiert auf dem PBC von Heiler
Software in der Version 2.5.2. Auf Basis
der Messungen lassen sich auch
Empfehlungen für ein richtiges Sizing
ableiten, die jedoch im einzelnen Fall
je nach Datenqualität und bei jeder
Abweichung durch individuelle Anpassungen
genauestens geprüft werden
müssen. Anders als bei einem
Feature-Benchmark, der insbesondere
während der Produktentwicklung genutzt
wird, überprüft ein Applications-Test
ein System hinsichtlich der
Kriterien Performance, Skalierbarkeit,
Durchsatz, Antwortzeitverhalten und
Verhalten unter hoher Last.
Entsprechend den Einsatzmöglichkeiten
und Anforderungen wurden verschiedene
Installationsszenarien geprüft.
Hierfür waren als wesentliche
Komponenten der Lösung zu berücksichtigen:
Datenbank sowie Webserver/Webadapter-Lastverteilung
für die
HTTP-Zugriffe und für die Abarbeitung
der Business-Objekte.
Diese Komponenten können auf ein
einzelnes Serversystem oder auf mehrere
Systeme verteilt sein. Teile des
Szenarios führten zu einer sehr hohen
Belastung auf dem Datenbankserver
(Suchanfragen), andere auf den Applikationsservern
(Auswählen von Artikeln,
Warenkorbaktionen).
Durchführung des
Applikationstests
Für die Definition entsprechender Benutzertypen,
die Zusammensetzung
einzelner Transaktionen, die Lastgenerierung
und für die Zeitmessungen
kam ein marktüblicher Lastgenerator
zum Einsatz. Die einzelnen PBC-Komponenten
wurden auf insgesamt drei
Sun Fire-Server installiert. Das auf Dialogschritten
basierende Lastszenario
lief auf bis zu drei Web- und Applikationsservern.
Der Test simulierte ein Userload zwischen
100 und 600 parallelen Benutzern
auf ein bis drei Applikationsservern.
Variiert wurde darüber hinaus
die Anzahl der Prozessoren des Datenbank-
und der Applikationsserver.
Teile des Szenarios erzeugten eine
sehr hohe Belastung auf dem Datenbankserver
(Suchanfragen), andere
auf den Applikationsservern (Auswählen
von Artikeln, Warenkorbaktionen).
Um eine praxisnahe maximale
Auslastung zu simulieren, wurde eine
Testreihe mit drei Applikationsservern
und mit 500 aktiven Usern durchgeführt.
In diesem Härtetest waren die
Applikationsserver im Durchschnitt zu
90 % ausgelastet; es kam dabei zu
keinen Verbindungsfehlern. Die Last
der Datenbank betrug im Durchschnitt
60 %; bei einer großen Anzahl
von Anfragen lag sie sogar bei nahe
100 %.
Skalierbarkeit des
Katalogsystems
Beginnend mit einem und einer
schrittweisen Erhöhung auf drei Applikationsserver
wurde die Leistungsfähigkeit
des PBC im Detail untersucht.
Bereits auf der ersten Stufe verarbeitete
der PBC 340.000 Warenkörbe
pro Monat. Hierbei wird eine nahezu
lineare Skalierung erreicht. Die Per-
16 NET 12/03

formance ist einzig durch den Umfang
der eingesetzten Hardware begrenzt,
eine Steigerung durch weitere
Server ist möglich.
Durch eine Skalierung auf drei Applikationsserver
und 500 parallele User
werden rund 1,1 Mio. Warenkörbe
pro Monat erreicht; dies entspricht bei
etwa 25.000 Named Usern einer Bestellrate
von ca. 44 Bestellungen mit
352 Produkten pro Monat und jedem
einzelnen Benutzer. Insgesamt werden
dabei rund 44,3 Mio. Dialogschritte
pro Monat erreicht; dies entspricht
bei 25.000 Named Usern etwa
1.770 Dialogen pro User und Monat.
Damit verbringt jeder der 25.000 Benutzer
pro Arbeitstag bis zu einer halben
Stunde im Katalog und setzt dabei
etwa 2,1 Bestellungen mit insgesamt
17 Produkten ab.
Ableitungen aus den
Testergebnissen
Auf Basis der Benchmark-Messungen
lassen sich auch Empfehlungen für ein
richtiges Sizing ableiten, die im Einzelfall
nach Datenqualität und bei Abweichungen
der Konfiguration im
Vorfeld geprüft werden müssen. Die
wichtigsten Regeln lauten:
Pro Applikationsserver-Instanz können
etwa 150 bis 200 parallele Benutzer
bedient werden.
Die Applikation skaliert nahezu linear
über mehrere Applikationsserver.
Beim Hinzufügen von Applikationsservern
muß parallel dazu der Datenbankserver
weiter ausgebaut
werden.
Die Applikation reagiert sensitiv auf
unterschiedliche Prozessortaktraten.
Eine Steigerung der Taktrate beispielsweise
von 400 auf 480 MHz
führt zu einer 20prozentigen Leistungssteigerung.
Das Hinzufügen von Prozessoren im
Datenbankserver bringt sehr gute,
nahezu lineare Performance-Zuwächse.
Somit kann der Datenbankserver
bei steigenden Benutzerzahlen
mitwachsen.
Ein schnelles Plattensystem beschleunigt
die Suchvorgänge um bis
zu 20 % bei Verteilung der Datenbank-Logdateien
und Datenbankdateien.
NET 12/03
Bild 2: Die Hardwarekonfiguration
des Applikationstests:
ein Datenbankserver Sun
Fire mit 8 x 900 MHz
Ultra Sparc III mit je
8 Mbyte Level-2-Cache
und 16 Gbyte RAM, Stor-
Edge A5200 und Stor-
Edge T3 sowie drei Applikationsserver
Sun Enterprise
mit Ultra-Sparc-Prozessoren
und jeweils
4 Gbyte RAM
Resümee
Simuliert wurde eine Benutzerlast zwischen
100 und 500 parallel arbeitenden
Anwendern. Dabei entsprechen
500 aktive Benutzer in einem internationalen
Großunternehmen rund
25.000 Named Usern. Die Vorgabe
war, mehr als 100.000 Bestellvorgänge
pro Monat auszulösen. In der Sum-
me ergibt dies ein indirektes Beschaffungsvolumen
von mehr als 1 Mrd. €
pro Jahr, das über die Katalogplattform
abgewickelt wird.
Die Simulation erfolgte auf Basis eines
realistischen Benutzerszenarios, basierend
auf dem Heiler Premium Business
Catalog in der aktuell verfügbaren
Version 2.5.2. Die Antwortzeiten zwischen
dem Auslösen einer Aktion am
Webbrowser und der Präsentation des
Katalogsysteme im Test
entsprechenden Ergebnisses durften
hierbei im Schnitt 2 s nicht überschreiten.
Als Datenbasis wurde ein Katalog
mit 5 Mio. Produkteinträgen gewählt,
die in dem komplexen relationalen
Datenbankmodell des PBC mit 119
Entitäten abgelegt wurden. Dieses Beschaffungssortiment
entspricht dem
Beschaffungsvolumen eines internationalen
Großkonzerns.
Die Testergebnisse – bei der Berechnung der Anzahl paralleler User werden etwa 2 % bezogen auf
die Named User unterstellt; die Zeitumrechnung berücksichtigt das internationale Anforderungsszenario
Von den umfangreichen Ergebnissen
sind folgende Resultate besonders zu
erwähnen:
mehr als 44,3 Mio. Dialogschritte/Monat;
mehr als 8,8 Mio. bestellte Produkte/Monat;
mehr als 1,1 Mio. OCI-Warenkörbe/Monat;
nahezu lineare Skalierung auf Sun
Fire-Server. (we)
17