Effiziente Distribution dynamischer Inhalte im Web; Efficient distribution of dynamic Web content;

1 Einleitung

Die ersten Web-Server sind mit der Zielset-zung entwickelt worden, Web-Browsernplattformunabhangig uber ein einheitlichesProtokoll den Zugriff auf Hypermedia-Dokumente zu ermoglichen [W3C92a].Der damalige Forschungs- und Entwick-lungsfokus lag primar auf der Spezifikationder Beschreibungssprachen und der Ent-wicklung geeigneter Browser [W3C92b].Web-Server waren einfache Systemdienste,um die jeweiligen Dateisysteme, auf denendie relevanten Dokumente abgelegt wur-den, plattformunabhangig fur Web-Browser abzubilden [NCSAoJ].

Mit der zunehmenden Leistungsfahigkeitund Verbreitung der Web-Browser ent-stand verstarkt die Anforderung, uber sienicht nur statische Dokumente abzurufen,sondern direkt auf datenbankbasierte An-wendungen zuzugreifen. Die Applika-tionslogik zur Verarbeitung der Daten-bankinhalte wurde uber standardisierteSchnittstellen externalisiert [CGIoJ].

Erfahrungsgemaß werden bei Web-An-wendungen nur Antwortzeiten im zwei-stelligen Millisekundenbereich von An-wendern als angenehm schnell empfunden.Jedoch dauern einzelne komplexe Daten-bankprozesse haufig langer. Wenn daruberhinaus in Hochlast-Web-Anwendungenbei Nachfragespitzen Engpasse bei der Da-tenbank auftreten, erhohen sich die mitt-leren Systemantwortzeiten noch weiter.Die Warteschlange der Abfragen wachstaufgrund von Datenbankengpassen schnel-ler, als Abfragen abgearbeitet werden kon-

nen. Im Extremfall bricht das System we-gen Administrationsuberlast zusammen,d. h. die Anwender erhalten zeitweise kei-ne Antwort mehr auf Systemabfragen.

Um dieser Problematik zu begegnen, wer-den bei Hochlast-Web-AnwendungenCaching-Mechanismen mit dem Ziel einge-setzt, die Anzahl der zur Laufzeit erforder-lichen Datenbankzugriffe um mehr als90% zu reduzieren. Die Skalierung kanndann unter Umgehung der Datenbank – alsteuerstem Engpassfaktor – durch das Hin-zufugen weiterer Web- bzw. Applikations-server erfolgen.

Aus diesem Ansatz resultiert die heutzuta-ge dominierende Systemarchitektur moder-ner Content-Management-Systeme (CMS),in der Applikationsserver im Hintergrunddie oft komplexen Dokumente (vor)pro-duzieren und schnelle Web-Server den Zu-griff auf diese vorproduzierten statischenDokumente ermoglichen.

Im Wesentlichen werden zwei Verfahreneingesetzt.

Zunachst zum bekannten und vielfach ver-wendeten Staging. So nennt man Verfah-ren, die Neuberechnungen durch Anwen-derabfragen bzw. die daraus resultierendenDatenbankzugriffe eliminieren, indem derkomplette Inhalt des Web-Servers in regel-maßigen Abstanden vorproduziert wird.Multigranulares Caching bezeichnet eineVerfeinerung des Staging, bei der die ein-zelnen Web-Seiten entlang einer Baum-struktur in kleinere Objekte (Clips) zerlegtund im Cache zwischengespeichert wer-den. Diese Clips werden dann nach Mog-

WIRTSCHAFTSINFORMATIK 44 (2002) 3, S. 249–259

Die Autoren

Kurt CotoagaAchim MullerRalf Muller

Dipl.-Kfm. Kurt Cotoaga,Dipl.-Inform. Achim Muller,Dipl.-Inform. Ralf Muller,IS Innovative Software AG,D-60316 Frankfurt am Main,E-Mail: {Kurt.Cotoaga | amueller |mueller}@isg.de

Effiziente Distributiondynamischer Inhalte im Web

WI – Schwerpunktaufsatz

lichkeit einzeln, in Gruppen oder als ganzeWeb-Seiten wiederverwendet. Da die Neu-berechnung bei Bedarf und fur die jeweilsveranderten Clips angestoßen werden kann,ist dieses Verfahren im Vergleich zum Sta-ging aufwandiger in der Entwicklung, aberflexibler und effizienter im Betrieb. DieVorteile des Caching konnen nur dann rea-lisiert werden, wenn die Clips haufig wie-derverwendet werden und der zusatzlicheAufwand der Cache-Verwaltung damituberkompensiert wird. Hierzu muss dieVerweil- und Gultigkeitsdauer der Objekteim Cache ausreichend lang sein.

Auf der Client-Seite verwenden auchBrowser Caching-Mechanismen. So wer-den die dargestellten Web-Seiten und diedarin enthaltenen graphischen Objekte imHauptspeicher und auf der lokalen Fest-platte zwischengespeichert, um bei neuerli-chen Anzeigen diese Objekte nicht noch-mals uber das Netz nachladen zu mussen.Die Nutzung dieser Caches kann ebenfallszu einer Reduktion der Datenbanklast bei-tragen.

Neben den kurzen Antwortzeiten fordernAnwender heutzutage hochaktuelle Daten(z. B. unverzogerte Wiedergabe von Ak-tienkursen, die sich in jeder Sekunde an-dern konnen) und personalisierte Dienste(etwa Zusammenstellung von Nachrichtenentsprechend eines Nutzerprofils). SolcheAngebote sind sowohl durch Staging alsauch durch multigranulares Caching nurbedingt realisierbar. Aufgrund der �nde-rungsfrequenz und der Aktualitatsanforde-rung greift das Caching nicht, da der Anteilder zur Laufzeit neu zu erzeugenden Seitensehr hoch ist.

Gegenstand des vorliegenden Beitrags sindspezialisierte Web-Applikationsplattfor-men und die darin verkapselten Mechanis-men. Diese tragen zu einer verbessertenSkalierbarkeit von Online-Dienste bei, oh-ne signifikante Abstriche an Aktualitat,Personalisierbarkeit und damit Kunden-nutzen hinnehmen zu mussen. Gleichzeitigtragt das resultierende Einsparungspoten-tial bei Hochlastdatenbanken zum wirt-schaftlichen Betrieb der Losungen bei.

Anwendungshintergrund der folgendenAusfuhrungen ist die Distribution vonBorseninformationen im Web mit Zugriffs-zahlen jenseits der Eine-Million-Page-Im-pressions-Grenze pro Monat [IVWoJ],konkret Aufbau und Betrieb umfassenderAktienmarkt-Informationssysteme. Diese

Anwendungen stellen hochste Anforde-rungen an Aktualitat, interaktive Applika-tionslogik sowie Personalisierbarkeit. Die�nderungsrate der in diesen Systemen ver-wendeten Information ist so hoch, dassStaging oder multigranulares Caching ohneweitere Vorkehrungen nicht sinnvoll einge-setzt werden kann. Die Autoren stellenhier als neues, zweites Verfahren das ActiveCaching als einen geeigneten anwendungs-domanenspezifischenden Losungsweg vor.Active Caching ist ein erweiterter Caching-Mechanismus der in der IS.Foundation-Web-Applikationsplattform der Firma ISInnovative Software AG verwendet wird.

Dieser Beitrag zeigt anhand der Erfahrungaus Entwicklung und Betrieb von Hoch-last-Marktinformationssystemen, wie mitgeeigneter Anwendungsgestaltung, einerspezialisierten Web-Applikationsplattformund der Beachtung von anwendungsspezi-fischen Leistungskennzahlen Applikatio-nen soweit optimiert werden konnen, dassneben einer hohen Aktualitat der Datenund Personalisierung der Dienste eine effi-ziente und damit wirtschaftliche Skalier-barkeit gewahrleistet wird.

Der Beitrag ist wie folgt gegliedert: In Ab-schnitt 2.1 wird ein Teil der Benutzer-schnittstelle eines Web-basierten Markt-informationssystems als Anwendungsfalldefiniert. Fur diesen Anwendungsfall wirdin 2.2 eine multigranulare Cache-Hierar-chie als Ansatz zur effizienten Implemen-tierung vorgestellt. Die hierfur eingesetztespezialisierte Plattform wird in Abschnitt2.3 skizziert. Im Hauptteil (Kap. 3) werdennach der Einfuhrung geeigneter Kennzah-len diverse allgemeine und anwendungs-spezifische Verfahren vorgestellt, mittelsderer die im Anwendungsfall beschriebeneBenutzerschnittstelle effizient realisiertund betrieben werden kann. Den Ab-schluss bildet eine Zusammenfassung.

2 Herausforderung:Benutzerschnittstelle undidealtypische Caching-Hierarchie Web-basierterMarktinformationssysteme

2.1 Benutzerschnittstelle

Die mit Abstand am haufigsten verwendeteFunktion innerhalb von Web-basiertenAktienmarkt-Informationssystemen ist die

Einzelkursabfrage. Schon in den ersten On-line-Auftritten von Brokern und Bankenwar sie ein zentraler, wenngleich damalsnoch isolierter Bereich fur aktuelle Kurse.Weitergehende Informationen musstenAnwender in Form eines Drill-down uberzahlreiche Verknupfungen abrufen. DieBenutzerschnittstellen wurden von derverfugbaren Technologie diktiert. Ins-besondere unerfahrene Anwender konntenrelevante Informationen nicht finden, was(z. T. heute immer noch) durch personal-kostenintensive Hotlines kompensiert wer-den musste oder zum Verlust der Attrakti-vitat des Online-Angebots fuhrte.

Eine typische Anforderung modernerWeb-basierter Aktienmarktinformations-systeme ist die Unterstutzung einer per-sonalisierten schnellen Navigation, die ge-eignet ist, mit einem Mausklick allerelevanten Informationen zu den beobach-teten Wertpapieren abzurufen. Damit ru-cken Objekte wie das personliche Muster-depot oder die Watchlist als Zentrum desInvestitionsprozesses in den Vordergrund.Auf Grundlage dieser Instrumente kannder Anwender die Wertentwicklung seinesPortfolios verfolgen, weitergehende Datenzu einzelnen Papieren erheben (Researchbetreiben), die Soll-Zusammensetzung sei-nes Depots verandern (Asset Allocation)und auch die dazu notwendigen Transaktio-nen durchfuhren (Kaufe, Verkaufe). Es wirdim Weiteren also angenommen, dass derAnwender bereits im System angemeldet istund damit allgemeine Marktinformationen,kundenspezifische Informationen und auchpersonliche Daten des Anwenders inner-halb der Session verfugbar sind. In diesemKontext sollen folgende Informationen mitBlick auf eine exemplarische Einzelkurs-abfrage verwendet werden:

& Aktuelle Borsenkurse(Quotes, allgemeine Information)Hierzu zahlen nicht nur die aktuellenKurse und Transaktionsvolumina vonunterschiedlichen Wertpapieren undWertpapierarten nationaler und interna-tionaler Borsenplatze, sondern auch da-raus abgeleitete aktuelle Leistungskenn-zahlen. Unabhangig davon, ob hierbeiverzogerte Kurse (15–20 Minuten) oderRealtime-Kurse dargestellt werden, sinddie Aktualitatsanforderungen bei dieserInformation hoch.

& Historische und sog. Intra-day-Kursver-laufe (Charts, allgemeine Information)Hierzu zahlen detaillierte Listen mitZeiten, Kursen und Transaktionsvolu-


250 Kurt Cotoaga, Achim Muller, Ralf Muller

mina (im Fachjargon: Times & Sales),ebenso Listen, die langfristige Open-,High-, Low-, Close- and Volume-Wertesowie dazugehorige Informationen uberHandlungen der Kapitalgesellschaften(Corporate Actions), z. B. Dividendenund Aktien-Splits, beinhalten. Fur beideBetrachtungszeitraume konnen Listenmit mehreren zehntausend Werten ent-stehen.

& Personliches Musterdepot(Watchlist, personalisiert)Diese Werkzeuge erfassen Wertpapiere,die der Anwender besitzt oder intensivbeobachtet, und ermoglichen die Ver-mogensubersicht und diverse Berech-nungen sowie Simulationen zum Ge-samtwert der Investition.

& Unternehmensdaten (Profile, allgemein)Hierzu zahlen neben Logos (Multi-media-Objekte) und dem beschreiben-den Profil (unstrukturierte Textinforma-tion) insbesondere aktuelle Kennzahlenzur Erfolgsbewertung, die aus der Ver-edelung von Bilanz und Gewinn- undVerlustrechnung in Kombination mitKursinformationen abgeleitet werden(formatierte Daten in Tabellenform).

& Wirtschaftsnachrichten(News, allgemein)Diese setzen sich aus Textbeitragen un-terschiedlicher Nachrichtenagenturenzusammen, die in Beziehung zu einerListe von Wertpapieren stehen konnenund durch unterschiedliche Rubri-zierungssysteme strukturiert sind. ImIdealfall werden die aktuellen Kurse derin den Nachrichten referenzierten Un-ternehmen und Indizes direkt in dieTexte integriert (diese Layout-Kom-ponente nennt man Life Quotes).

& Benutzerforum(Forum, kundenspezifisch)In einem solchen Forum diskutieren ak-tive Gleichgesinnte Vor- und Nachteilevon Investitionen bzw. Spekulationen.Passive Konsumenten versuchen, ausder Erfahrung anderer Investoren(Street Gossip) eigene Schlussfolgerun-gen zu ziehen.

Bild 1 skizziert den moglichen Aufbau ei-ner solchen Web-Seite und beschreibt dieverwendeten Informationen. Der gestri-chelt umrandete Bereich zeigt den auf demBildschirm sichtbaren Teil der Web-Site an.Der gepunktet umrandete Bereich (Canvas)zeigt einen abstrakten Clip an. Dieser istaus zahlreichen kleineren Clips zusammen-gesetzt, die selbst aus atomaren Clips beste-hen konnten. Da die Wiederverwendungs-

wahrscheinlichkeit des zusammengesetztenClips (Canvas) sehr hoch ist, ebenso wie beiden kleineren Clips, lohnt sich das Zwi-schenspeichern im Cache. Die einzelnen In-formationsblocke bzw. Layout-Kom-ponenten (Clips) konnen in allgemeineMarktinformationen (grau, gultig fur alleKunden und Anwender), kundenspezi-fische Informationen (punktiert, z. B. einDiskussionsforum oder spezielle Angebo-te) und personalisierte Informationen(schraffiert) unterteilt werden.

Die Erfahrung belegt, dass diese Art derBenutzerschnittstelle mit zahlreichen un-terschiedlichen Informationen zu einemWertpapier auf einer Webseite positiv vonKunden aufgenommen wird. Sie unter-stutzt durch die integrierte Darstellung ei-ne ganzheitliche Bewertung eines Wert-papiers und fuhrt dadurch indirekt zueiner Senkung des Betreuungsaufwands inder Hotline.

Die Verfugbarkeit der Anwendung und dieAktualitat der Informationen sind wichtigeVoraussetzungen fur die Abwicklung kun-deneigener Geschaftsprozesse (und damitauch zentrale preisbestimmende Faktorender Gesamtlosung; diese Frage werden wirjedoch an dieser Stelle nicht weiterverfol-gen). Die Moglichkeit, Losungen mit mini-

malen Antwortzeiten und maximaler In-formationsaktualitat anzubieten und dieseVorgaben innerhalb der vereinbarten Ser-vice Level Agreements (SLAs) in der Pro-duktion einzuhalten, sind daher wichtigeWettbewerbsvorteile der Anbieter vonWeb-basierten Marktinformationssystemen.

2.2 Idealtypische multigranulareCache-Hierarchieder Benutzerschnittstelle

Eine effiziente Umsetzung der vorge-nannten Benutzerbedienung erfordert denEinsatz von ausgefeilten Caching-Mecha-nismen, um die Datenbankzugriffe zu mi-nimieren. Das nachfolgende Diagrammveranschaulicht eine Cache-Hierarchie furdas Anwendungsbeispiel, das wiederver-wendbare atomare Informationsobjekte zuzusammengesetzten Clips, bis hin zu kom-pletten Webseiten assembliert.

Die durch die Baumstruktur der Cache-Hierarchie definierte Zusammensetzungeinfacher Clips zu immer komplexerenClips, die jeweils auf ihrer Ebene in einzel-nen unterschiedlich abstrakten Cacheszwischengespeichert werden, wird als mul-tigranulares Caching bezeichnet. Dieser


Kernpunkte fur das Management

Anwendungs- und Systemarchitekturen fur Web-basierte Marktinformationssysteme mussengeeignet sein, auch bei steilem Lastanstieg Nutzerabfragen in akzeptabler Zeit zu beantwor-ten. Um dies ohne hohe Infrastrukturinvestitionen zu gewahrleisten, muss der uberwiegendeTeil der verhaltnismaßig viel Durchlaufzeit verbrauchenden Datenbankabfragen bereits aufder Applikationsserver-Ebene abgefangen werden. Ein dergestalt optimiertes System er-moglicht eine hohe Parallelisierbarkeit der Nutzung und eroffnet dadurch kostengunstigeSkalierungspfade.

& Staging und multigranulares Caching sind gangige Verfahren, die auf unterschiedlichenPlattformen mit Erfolg bei General-interest-Angeboten eingesetzt werden konnen.

& Bei anspruchsvollen personalisierten Anwendungen mit zahlreichen sich haufig andern-den Informationen versagen diese Verfahren jedoch.

& Wir stellen das Active Caching als neuartiges Caching-Verfahren vor, das uns in die Lageversetzt, die vorgenannte Gegenlaufigkeit von Leistungseigenschaften zu uberwindenund Anwendungen mit hohem Nutzwert zur Verfugung zu stellen. Durch den Einsatz spe-zialisierter Web-Applikationsplattformen, die diese Technik anbieten, kann die Entwick-lung entsprechender Informationssysteme rationalisiert werden.

Stichworte: dynamische Inhalte, Realtime-Daten, personalisierte Inhalte, Hochlast-Web-An-wendungen, Leistungsmessung, Caching-Mechanismen, Leistungsoptimierung

Effiziente Distribution dynamischer Inhalte im Web 251

Ansatz ermoglicht die Wiederverwendungsowohl großer als auch kleiner Clips undreduziert den Aufwand der Neuberechungauf den veranderten Zweig des Dekom-positionsbaums.

Ein Clip ist uber die Applikationslogikund die zur Erstellung notwendigen Datendefiniert. Diese Daten konnen direkt ausder Datenbank ausgelesen oder indirektdurch die Verwendung vorgefertigter Clips

benutzt werden. Die in der nachfolgendenGraphik bei den Clips angedeuteten stili-sierten Zifferblatter verdeutlichen, dass sieje nach Inhalt unterschiedlich lang zwi-schengespeichert werden konnen. NachAblauf dieses Zeitintervalls wird derCache-Inhalt ungultig, sodass eine nachfol-gende Anfrage zur Ausfuhrung der Appli-kationslogik und der damit verbundenenDatenbankoperationen fuhrt, um denCache mit neuen Werten zu fullen.

Die Gultigkeitsdauer des Caches wird uberden verfugbaren Speicher und die �nde-rungshaufigkeit der zugrundeliegenden In-formationen definiert. Kann innerhalb derGultigkeitsdauer eine �nderung statt-gefunden haben und ist diese zu beruck-sichtigen, ist ein Datenbankzugriff uner-lasslich, um zu verifizieren, ob derCache-Inhalt noch aktuell ist, wodurch derEffizienzvorteil des Cache zunichte ge-macht wird.

Die hier vorgestellte neuartige Alternative,bei der die Cache-Gultigkeit durch die Da-tenbank zuruckgesetzt oder der Cache-In-halt durch die Datenbank aufgefrischt wer-den kann, bezeichnen wir als ActiveCaching. Die Funktionen Active Invalidateund Active Update sind noch vorzustellen-de Varianten des Active Caching.

Die Quotes-, Chart-, Figures- und News-Datenbanken erhalten durch sog. Feed-Handler fur die unterschiedlichen Formateund Quellen permanent Informationenund werden aktualisiert. Im Hintergrundoperieren zusatzlich verschiedene Serveran der Veredelung bereits erfasster Daten.

Auch wenn jede Webseite insgesamt ein-zigartig und damit nur fur identischeFolgeaufrufe gespeichert werden kann,sind elementare und zusammengesetzteClips an vielen Stellen und fur verschiedeneBenutzer wiederverwendbar. Die Gultig-keitsdauer zusammengesetzter Objektewird durch die kurzeste Cache-Dauer sei-ner Bauteile, also des jeweiligen Zweigesseines Dekompositionsbaums bestimmt.Wir wollen nun fur wichtige Clips die Gul-tigkeitsdauer der zugehorigen Caches ein-ordnen:

& ChartUm Charts darzustellen, sind lange His-torien aus der Datenbank abzurufen.Umgekehrt gilt aber auch, dass dieErgebnisse bis zur Feststellung desnachsten Schlusskurses ihre Gultigkeit



behalten. Sind anwenderseitige Manipu-lationen der Charts erforderlich, wie dieBerechnung von Technischen Indikato-ren, kann zumindest auf die bereitsabgerufenen Datenbankinhalte zuruck-gegriffen werden. Selbst bei kurzfristi-gen Intraday Charts ist aufgrund der amBildschirm verfugbaren Pixel-Auflosungeine Cache-Gultigkeit von etwa 10 Mi-nuten gewahrleistet. Bei der ublichenBreite von ca. 100 Pixel fur Charts sindbei der Betrachtung der gesamten Han-delsperiode Zeitraume von unter 10 Mi-nuten nicht mehr darstellbar.

& Watchlist�nderungen in der Zusammensetzungder Musterdepots und Watchlisten mus-sen unmittelbar in die Datenbank ge-schrieben werden (man nennt sie nichtabwendbare �nderungsanforderungen).Dafur ist diese Zusammensetzung ubli-cherweise sehr lange stabil (uber dieDauer der Session hinaus).

& Unternehmensportraits und Kennzahlen(Figures)Aus dem Research gewonnene Unter-nehmenskennzahlen gehoren zu den inWeb-Marktinformationssystemen leichtzu verarbeitenden Informationen, weilder Inhalt uber lange Zeitraume unver-andert bleibt.

& Forum (Community Support)Die Inhalte des Forums sind bei neuenBeitragen zu aktualisieren. Da die Dis-kussionsthemen uber viele Subforen ver-teilt sind, bleiben die Inhalte der meistenSubforen lange stabil.

& Nachrichten (News)Im Allgemeinen konnen Nachrichtenohne signifikante Beeintrachtigung desKundennutzens leicht im halbstundigenoder sogar stundlichem Rhythmus gene-riert werden (Staging). Aber bei Markt-informationssystemen ist dies nur sehrbedingt moglich, da zwischen zwei auf-einanderfolgenden Staging-Prozessenkeine Aktualisierungen erfolgen. Even-tuell erscheinende marktrelevante Nach-richten (z. B. Ad-hoc-Publizierungen)wurden ignoriert werden. Das Cachingist daher maximal auf funf Minuten zubegrenzen, wenn nicht gar zu vermei-den. Der Nachrichtentext selbst ist je-doch lange stabil. Werden innerhalb desTextes Life Quotes verwendet, mussendiese uber Clips eingebettet werden.

& QuotesAktuelle Kursinformationen und dieClips, in denen diese verwendet werden,sind Objekte, bei denen das KlassischeCaching nicht eingesetzt werden sollte,

da die verwendeten Kursinformationensich permanent andern konnen. Benut-zerschnittstellen wie im Anwendungsfalllassen sich nur dann realisieren, wenndie Anforderung minimaler Informa-tionsverzogerung aufgegeben wird. An-wender werden bei Marktinformations-systemen kaum bereit sein, mit veraltetenKursinformationen zu arbeiten. Da dersog. Quote Clip bzw. die zugrundelie-gende Kursinformation in fast allenubergeordneten Clips verwendet werdenkann (und sollte), bricht im Falle einerAktualisierung die gesamte darauf auf-bauende Caching-Hierarchie zusammen.Im Ergebnis mussen diese wichtigen In-formationen isoliert werden, wodurchder Nutzen der Benutzerschnittstellesinkt, da permanent zwischen unter-schiedlichen Seiten gesprungen werdenmuss und die relevanten Informationennicht langer ubersichtlich auf einer Web-Seite uberwacht werden konnen.Wie in Abschnitt 2.3 Web-Applikations-plattformen gezeigt wird, lost das ActiveCaching diese Problematik und eroffnetdadurch den zunachst als unmoglich er-achteten Einsatz des multigranularenCaching zur Effizienzsteigerung. OhneActive Caching muss aufgrund der hau-figen Verwendung des Quote Clips beinahezu jeder neuen Anfrage eine kom-plette Neuberechnung inklusive allerDatenbankzugriffe angestoßen werden.

Die gewahlte Benutzerschnittstelle zeigt,dass bei Anwendungsdomanen mit sichhaufig andernden Inhalten durch dieTrennung zwischen Applikations- undDatenbankschicht immer eine Spannungzwischen der Notwendigkeit, Datenbank-zugriffe durch Staging oder multigranula-res Caching zu minimieren, und den Ak-tualitatsanforderungen der Anwenderbesteht. Die Benutzerschnittstellen lassensich dann ohne den Einsatz spezieller Ver-fahren, wie z. B. Active Caching, nichtwirtschaftlich realisieren.

2.3 Web-Applikationsplattformen

Die Applikationsplattform kann Entwick-ler durch komfortable Caching-Mechanis-men unterstutzen, die Staging oder eineeinfache Umsetzung von multigranularenCache-Hierarchien ermoglichen.

Gangige Web-Applikationsplattformen,z. B.

& MS Internet Information Server plusActive Server Pages, MS Access, Intel/W2K; Apache plus Vignette, Oracle,Sun/Solaris,

& IBM HTTP plus WebSphere, DB2,IBM/AIX und

& die im eigenen Hause entwickelteIS.Foundation-Plattform

unterstutzen Caching-Mechanismen, mitdenen multigranulare Caching-Hierarchienaufgebaut werden konnen.

Das in Abschnitt 2.2 geforderte ActiveCaching mit bidirektionaler Kommunika-tion zwischen Applikationsserver und Da-tenbank wird jedoch nur durch die IS.-Foundation-Plattform unterstutzt, die hiernaher beschrieben werden soll. Sie basiertauf Linux und besteht im Wesentlichenaus:

& einem kombinierten Web- und Applika-tionsserver (IS.SecureFTS),

& der auf TcL/Tk basierenden Script-Spra-che (IS.SecureFTL)

& einer umfangreichen Bibliothek, welchezahlreiche Standardgeschaftsprozesseund Methoden der Kapitalmarkttheorieverkapselt (IS.Foundation – Library),und

& einer Reihe von speziell auf die jeweili-gen Inhalte abgestimmten Datenbanken(IS.ContentStore – Quotes, – Charts, –Figures, – News, – Text und – User).

Der anspruchvollere Teil der Optimierungbesteht darin, die Anzahl der notwendigenDatenbankanfragen auf das absolute Mini-mum zu reduzieren. Datenbankstrukturund Abfragen sind so zu gestalten, dassAbfragen wiederverwendbar sind undmoglichst viele Informationen mit einereinzigen Datenbankabfrage abgerufen wer-den konnen.

Typische Datenbankabfragen fur persona-lisierte Web-Anwendungen lauten:

& Lese „Anwendereinstellungen“ (z. B.fur die Daten des individuellen Seiten-aufbaus) im Pfad \\Anwender\Muster-mann\Anwendereinstellungen. Als Er-gebnis erhalt die Anwendung alledarunter enthaltenen Informationen inForm eines sog. Infocontainer.

& Lese „Transaktionen“ (fur alle Wert-papiere) eines Depots im Pfad \\Anwen-der\Mustermann\Portfolio\My Portfo-lio\*\. Als Ergebnis erhalt die Anwen-dung alle Transaktionen fur alle Instru-mente in Form eines Infocontainer.



Da die uberwiegende Mehrzahl der Abfra-gen gradlinig und in der Struktur vor-hersehbar sind, werden in der IS.Founda-tion-Applikationsplattform hierarchischeDatenbanken eingesetzt. Fur die oben be-schriebene Form von Abfragen konnen ei-nerseits sehr kurze Zugriffszeiten realisiertwerden und andererseits ergeben die Ab-fragen komplette sog. Infocontainer. Diesesemantisch zusammenhangenden, oft mo-nolithischen Container lassen sich effizien-ter zwischenspeichern, als die fragmen-

tierten Abfragen, bei denen relationaleDatenbanken ihre Starken ausspielen. Eineauf einem normalen Intel-basierten Serverbetriebene IS.ContentStore-Datenbankverarbeitet in der Spitze ca. 50.000 Schreib/Lese-Operationen pro Minute.

Das wirksamste Verfahren innerhalb derIS.Foundation-Applikations-Plattform istjedoch das Active Caching. Der Web- undApplikationsserver IS.SecureFTS kom-muniziert bidirektional mit der IS.Con-

tentStore-Quotes-Datenbank, in welcheraktuelle Kursinformationen zu ca. 500.000Wertpapieren vorgehalten werden, die anverschiedenen Borsenplatzen der Welt ge-handelt werden. IS.SecureFTS „abboniert“jedes Wertpapier, fur das eine Kursabfragedurchgefuhrt wird, und wird daraufkommt es an bei spateren Kursanderungendirekt von der Datenbank mit dem neuenWert versorgt (Active Update). �blicher-weise abonniert ein aktiver IS.SecureFTSKurse fur ca. 20.000 Wertpapiere. Da sichdas Interesse von Anwendern im Normal-fall auf einige tausend Wertpapiere konzen-triert (dieser Fokus ist jedoch nie uber lan-gere Zeitraume stabil), muss fur diese sehrhaufig verwendete Information nur in we-niger als 5% der Abrufe ein Datenbank-zugriff erfolgen.

Bild 3 visualisiert die zeitliche Abfolgebeim Active Update fur Informationen, diesehr haufigen �nderungen unterliegen.Der Zeitstrahl verlauft von links nachrechts. Die senkrechten Pfeile symbolisie-ren Benutzerabfragen (oben) und Aktivita-ten der Datenbank (Auslesen von Wertenund Active Updates; diese sind zwischender Quotes-Datenbank und dem QuoteClip Cache aufgezeichnet). Nach dem erst-maligen lesenden Abruf des KursesDCX.NYS (durchgezogener Pfeil) wirdder Quote Clip ereignisgesteuert auto-matisch durch die Datenbank aktualisiert.Solange der Kurs abboniert bleibt, erfolgenfur die Folgenachfragen seitens der Benut-zer keine weiteren Zugriffe durch den Ap-plikationsserver auf die Datenbank.

Da die abonnierten Informationen umGroßenordnungen haufiger abgerufen wer-den als sie durch Marktbewegungen veran-dert werden, wird dadurch der uberwie-gende Teil der Datenbankabfragen obsoletund es entsteht kein Flaschenhals. Die ubli-che blinde Holschuld des Applikationsser-vers gegenuber der Datenbank wird in eineintelligente Bringschuld der Datenbank anden Applikationsserver umgekehrt. Dabeiwerden die am seltensten genutzten abon-nierten Kurse aus dem Cache entfernt, umPlatz zu schaffen fur haufiger genutzte In-formationen.

Die ubrigen IS.ContentStore-Datenbankensind in der Lage, zwischengespeicherte Ab-fragen, die aufgrund veranderter Informa-tionen nicht langer gultig sind, zu invali-dieren (Active Invalidate). Dies ermoglichtden Entwicklern von Web-Anwendungen,fur zahlreiche Clips lange Cache-Zeiten


Quote Clip (Cache)

Quotes

Read (Pull)

Active Update (Push)

Abfrage (Nutzung) eines Clips

$41,51!$41,45!

$41,42!$41,55!

$41,53!

DCX.NYS?

t0 Zeit

Quote Clip (Cache)

Quotes

Read (Pull)

Active Update (Push)


$41,51!$41,45!

$41,42!$41,55!

$41,53!

DCX.NYS?

t0 Zeit

Bild 3 Active Update

News Clip (Cache)

News

Read (Pull)

Active Invalidate (Push)


27.02.2002, 09:28 DaimlerChrysler an Übernahme der Formel 1interessiert

27.02.2002, 17:04 JP Morgan hält DaimlerChrysler weiter auf"Buy“

Daimler*?

t0 Zeit

News Clip (Cache)

News

Read (Pull)

Active Invalidate (Push)


27.02.2002, 09:28 DaimlerChrysler an Übernahme der Formel 1interessiert

27.02.2002, 17:04 JP Morgan hält DaimlerChrysler weiter auf"Buy“

Daimler*?

t0 Zeit

Bild 4 Active Invalidate


vorzugeben, da die Neuberechnungen au-tomatisch angestoßen werden, wenn diezugrundeliegenden Informationen veran-dert wurden. Die Neuberechnung bleibtfur die Entwickler transparent.

Bild 4 visualisiert die zeitliche Abfolgebeim Active Invalidate. Nach dem erst-maligen lesenden Abruf von Nachrichten(hier im Bereich der Nachrichtenversor-gung) speichert die Datenbank, dass einZugriff darauf erfolgte. Der Applikations-server speichert gleichzeitig das Ergebnisder Abfrage. Bei der zweiten Verwendungdes Clips wird das Ergebnis, das bis dahinnoch nicht als ungultig markiert wurde,nochmals verwendet. Dann jedoch wirdnach der zweiten Abfrage eine neue Nach-richt erganzt. Die Datenbank markiert da-raufhin samtliche Abfragen in den Appli-kationsservern als ungultig. Bei deranschließenden dritten Abfrage seitens ei-nes Benutzers kann daher der Cache-Inhaltnicht nochmals verwendet werden. Statt-dessen erfolgt nun ein Zugriff auf die Da-tenbank, dessen Ergebnis nach dem glei-chen Schema gespeichert wird.

In Kombination erlauben Active Cachingund hierarchische Datenbanken die effi-ziente Umsetzung der skizzierten Benut-zerschnittstelle, ohne Abstriche bei der In-formationsqualitat oder unverhaltnismaßighohe Hardware-Aufwendungen in Kaufzu nehmen.

3 Optimierungsansatzezur Effizienzsteigerung

Wir betrachten zunachst Benchmark-Ver-fahren zur Einschatzung der Leistungs-fahigkeit von Web-Applikationsplattfor-men und -Anwendungen. Danach zeigenwir systemseitige Optimierungspotenzialein der Produktion sowie vier anwendungs-spezifische Verbesserungsmoglichkeiten(Nachrichtenversorgung, Benutzerforen,Personalisierung und Real-time-Kursver-sorgung) auf, wobei die vorgenanntenTechniken gezielt zum Einsatz kommen.

3.1 Benchmarkingvon Web-Anwendungen

Erfolgreiche Web-basierte Anwendungenwaren und sind immer einer hohen Lastausgesetzt, die zu durchdachten Optimie-

rungsverfahren zwangen, um die verfug-baren Ressourcen optimal auszunutzen[MGYC95]. Erste Benchmarks wurden da-her schon bald nach der offentlichen Ver-fugbarkeit erster Web Server [McGr96]diskutiert.

Heutzutage erfolgt das Benchmarking vonkommerziellen Web-Applikationsplattfor-men uber standardisierte Testverfahren.Die derzeit bekanntesten Verfahren sind:

& SPECweb99 von der SPEC Organisa-tion(http://www.specbench.org/osg/web99)

& WebBench 4.1 von ZiffDavis Net(http://www.etestinglabs.com/benchmarks/webbench/webbench.asp)

& WebStone 2.5 von Mindcraft (ursprung-lich SGI)(http://www.mindcraft.com/webstone)

& WebStress von Paessler(http://www.server-monitor.com/WebStress/webstress.htm)

Die oben aufgefuhrten Verfahren erzeugeneine standardisiere Arbeitslast und messenden Durchsatz der Web-Applikationsplatt-form. Die Arbeitslast wird uber ein Profilvon unterschiedlichen Abfragen statischerund dynamischer Inhalte definiert, wobeizwei Kategorien von Werten erhoben wer-den:

& Maßzahlen fur die vom Anwenderwahrgenommene Leistungsfahigkeit& Mittlere Antwortzeit& Wie effizient werden Applikations-

schnittstellen wie CGI, NSAPI oderASP bedient?

& Wie effizient werden Benutzerver-waltung, Sessions, Cookies und per-sistente Verbindungen verwaltet?

& Wie effizient konnen sichere SSL-Verbindungen verwaltet und bedientwerden?

& Maßzahlen bezuglich der Anzahl paral-leler Anwender& Mittlere Anzahl paralleler Nutzer& Wie viele gleichzeitige Nutzer mit

unterschiedlichen Geschwindigkeitensind moglich?

& Wie viele HTTP-Operationen unter-schiedlicher Art (GET/POST) kon-nen pro Zeiteinheit ausgefuhrt wer-den?

& Wie effizient werden HTTP1.0- undHTTP1.1-Operationen ausgefuhrt?

Samtliche Benchmark-Verfahren fokussie-ren auf Web-Server-spezifische Aspekte.Die uber Applikationsschnittstellen auf-gerufenen Operationen sind nur einfache

Berechnungen (z. B. von Zufallszahlen)oder identische Datenbankzugriffe, da nurdie Effizienz der Interprozesskommunika-tion betrachtet wird. Rechenintensive Ope-rationen oder anwendungsspezifische indi-viduelle Datenbankzugriffe werden nichtbetrachtet. Im Ergebnis sind diese Verfah-ren also nur geeignet, die Web-Applika-tionsplattformen ohne realitatsnahe An-wendungen hinsichtlich ihres allgemeinenLeistungspotenzials zu evaluieren. Die Be-muhungen gehen heutzutage soweit, dassstatische Informationen sogar in das Be-triebssystem-Kernel gelinkt werden, umdie Umschaltzeiten beim Task Switchingzwischen Kernel und User Mode zu mini-mieren (etwa bei den neuen IVW-Boxenzur Erfassung von Page Impressions).

Bei der Entwicklung und Optimierungvon Web-Anwendungen im Bereich derMarktinformationssysteme konnen dieseBenchmark-Verfahren jedoch nicht einge-setzt werden, um die Eignung bzw. die zuerwartende Leistungsfahigkeit im taglichenBetrieb zu testen. Erfahrungsgemaß sugge-rieren Anwendungen bei solchen Tests ak-zeptables Antwortzeitverhalten, aber dieLeistungskennzahlen brechen dann unterrealen Lastbedingungen aufgrund der War-teschlangen an der Datenbank ein. Die Kri-terien Aktualitat der Information und dieAufbauzeiten der Seiten im Browser wer-den von solchen Benchmarks ignoriert.

Ausschlaggebend ist letztlich – und dies istdie in der taglichen Arbeit verwendeteMessgroße – die Bedienung einer maximalgroßen Anzahl von Benutzeranfragen furkomplette Web-Seiten pro Zeiteinheit.Hierzu sollte jede relevante Web-Seite sooptimiert sein, dass sie zur Laufzeit imDurchschnitt in weniger als 100 Milli-sekunden erstellt werden kann. Vor demHintergrund, dass eine minimale Generie-rungszeit fur viele Abrufe das Zielkriteri-um darstellt, muss versucht werden, dieGenerierungszeit pro Seite zu minimieren.Das bedeutet nicht, dass Seiten mit 500oder mehr Millisekunden Erstellungszeitgenerell unzulassig sind. Die Bedienung ei-ner solch komplexen und seltenen Abfrageist auch fur den einzelnen Anwender ak-zeptabel und wurde in einer Testumgebungals ausreichend schnell empfunden werden.Wenn aber in der Produktionsumgebunginnerhalb einer Minute tausend derartkomplexe Anfragen bearbeitet werdenmussen, dauert die lineare Abarbeitung je-des einzelnen Aufrufs mit 0,5 Sekundenauf einem Server zu lang. Ist diese komple-



xe Anfrage aber haufig zu erwarten, so istzu uberlegen, wie diese durch Caching zubewaltigen ist. Entscheidend ist hierbei,wie wirksam sich das Caching beim realenLastprofil erweist. Die Verteilung der Lastist zudem ungleichmaßig uber den Tag ver-teilt. Das Ziel der Optimierung ist einakzeptables Antwortzeitenverhalten ins-besondere zu den Spitzenlastzeiten wah-rend der Handelseroffnungen und kurzvor dem Handelsschluss.

Nach dem Absetzen einer Abfrage mittelseines Mausklicks verbleiben 0,1 Sekunden.Innerhalb dieser Zeitspanne muss die Ver-bindung, eventuell uber SSL gesichert, auf-gebaut, die Web-Seite generiert und der In-halt zum Browser des Anwenders uber dasNetz ubertragen werden, um abschließend,dies wird haufig vernachlassigt, imBrowser dargestellt zu werden. Man kanngrundsatzlich drei Phasen unterscheiden,die im nachfolgenden Diagramm visuali-siert sind:

& Phase 1Im Zuge des Verbindungsaufbaus mus-sen eventuell Daten fur Verschlusse-lungsverfahren (HTTPS, SSL) aus-getauscht und eine Reihe von Firewallsund Proxy-Servern uberwunden wer-den. Zur Beschleunigung dieser Phaselassen sich die meisten Server so kon-figurieren, dass sie eine Verbindung zueinem Client fur kurze Zeit aufrechterhalten, um nachfolgende Anfragenund Leistungen sofort abwickeln zukonnen (persistente Verbindung[Apac02; Micr02]).

& Phase 2Beim dynamischen Zusammenbau derWeb-Seiten muss Information aus derDatenbanken verarbeitet werden. DieseApplikationslogik erfordert, wenn dienotwendige Information bereits vor-liegt, oft nur wenig Systemzeit und kannhaufig parallel zu der dritten Phase ab-gearbeitet werden.

& Phase 3Im Vergleich zu den Phasen eins undzwei sind die Datenbankabfragen derdritten Phase die teuersten Verarbei-tungsschritte. In der Regel konnen Ap-plikationsserver, die auf eine Antwortdes Datenbanksystems warten, andereAnfragen bearbeiten, die eventuell keineweiteren Datenbankabfragen erfordern,sodass die Bearbeitungszeit einer Mengevon Benutzern minimiert werden kann,wenngleich es zahlreiche Beispiele furAbfragen gibt, die aufgrund der um-



fangreichen Datenbankoperationen sehrlange dauern konnen (mehr als eine Se-kunde pro Abfrage).

Wird davon ausgegangen, dass die Serveruber ausreichend Hauptspeicher verfugenund ordnungsgemaß konfiguriert sind,Verschlusselungen nur dann erfolgen,wenn sie notwendig sind, und schnelleRAID-Systeme zum Einsatz kommen,wird schnell erkennbar, dass die Phase 3das großte Optimierungspotenzial bietet.

Weitere oft vernachlassigte Optimierungs-potenziale erschließen sich durch eine effi-ziente Nutzung der Browser. GuterHTML-Code kann schnell im Browserdargestellt werden und erleichtert die Pa-rallelisierung der Anfragen. Komplex ver-schachtelte Tabellenkonstruktionen, wie siehaufig durch WYSIWYG-HTML-Edito-ren generiert werden, konnen die Ge-schwindigkeit mehr einschranken als lang-same Dienste oder knappe Bandbreiten.

Die korrekte Benutzung der Caches imBrowser eroffnet weitere wichtige Opti-mierungspotenziale. Hierzu ist eine detail-lierte Betrachtung von langfristig statischenGraphiken notwendig. Werden fur solcheObjekte keine langfristigen Ablaufdatenvorgegeben, wird auf den vom Server vor-gegebenen Default-Wert zuruckgegriffen,der erfahrungsgemaß mit wenigen Minutensogar unterhalb der Dauer einer mittlerenSession liegt. Dadurch werden vomBrowser sehr viele unnotige Abfragen aufstatische bzw. konstante Objekte ausgelost,die ansonsten komplett aus dem Browser-Cache bedient werden konnten.

3.2 Systemseitige Optimierungder Anwendungin der Produktion

Die anwendungsseitige Optimierung ist ei-ne notwendige, aber nicht hinreichendeBedingung fur einen performanten Betrieb.Wirkliche Hochlast-Web-Anwendungenerfordern zusatzlich eine systemseitigeOptimierung im Produktionsbetrieb. Diehierbei betrachtete Zielgroße ist die bereitseingefuhrte „Anzahl der Anfragen proZeiteinheit“. Dabei ist die absolute Zahlweniger ausschlaggebend, da sie stark vonder Gestaltung der Benutzerschnittstelleabhangt.

Da die eigentliche Applikationslogik seltenden Engpass bildet, gilt es ineffiziente

Datenbankabfragen zu identifizieren unddurch geeignete Aggregation zu eliminie-ren.

Der IS.SecureFTS halt nach dem Start dievor-compilierte Applikationslogik, samt-liche statischen Daten und die Templatesder Benutzerschnittstelle im Hauptspeichervor. Zur Parallelisierung wird ein ebenfallsstatisches „pre-forking Modell“ benutzt,das ca. 20 identische Child-Prozesse zurBedienung des HTTP-Ports abspaltet. DerAufwand zur Prozessverwaltung wird mi-nimiert. Zur Laufzeit steht dadurch derAnwendung die komplette Rechenzeit furdie Beantwortung der Anfragen zur Ver-fugung. Die Steuerung erfolgt dann durchhohere Parallelisierung (mehr Child-Pro-zesse mit weniger MemCache) oder mach-tigere Prozesse (mehr MemCache fur we-niger Child-Prozesse).

Die generelle Caching-Effizienz wirddurch die Cache-Miss-Rate und das durch-schnittliche Alter der verworfenen Objektebestimmt. Das durchschnittliche Alter derverworfenen Objekte sollte hoher sein alsdie durchschnittliche Verweilzeit der An-wender.

3.3 AnwendungsspezifischeOptimierung derNachrichtenversorgung

Die primare Informationsquelle einesNachrichtensystems sind die publizieren-den Redakteure, die ihre Beitrage in einerDatenbank zur Freigabe ablegen. Sekunda-re Informationen konnen Multimedia-Ob-jekte oder aktuelle Kursinformationen sein.Ist eine Nachricht erst einmal freigegeben,erfolgt nur in seltenen Fallen eine nachtrag-liche �nderung. Fur den Anwender ist die-ser Redaktionsprozess jedoch transparent.

Aufgrund des normalen Nutzungsverhal-tens bei General-interest-Angeboten stellteine Verzogerung bis hin zu einer Stundekeinen signifikanten Mangel dar. Weitwichtiger ist, die in einer Liste oder als An-riss sichtbare Nachricht schnell in Ganzeabrufen zu konnen.

Fur dieses Anwendungsszenario kann mitvielen Applikationsplattformen eine flacheCache-Hierarchie entworfen werden, dieeine nahezu optimale Skalierbarkeit derAnwendung sicherstellt. Der Applikations-server kann alle Inhalte vorproduzieren

und als statische HTML-Seiten auf demDateisystem des Web-Servers ablegen. Erstwenn neue Nachrichten freigegeben wer-den, besteht Handlungsbedarf und es wirduber den Batch-Prozess des Staging einneuer Satz statischer Dokumente vorpro-duziert. Dadurch, dass zwischen den Sta-ging-Prozessen keine Datenbankabfragennotwendig sind, da alle Web-Seiten vor-produziert wurden und auf dem Dateisys-tem des Web-Servers zum Abruf bereitste-hen, kann eine solche Web-Anwendungeiner sehr hohe Anzahl von Seitenabrufenpro Zeiteinheit standhalten. Dies wird je-doch durch ein Verzicht auf eine per-manente Aktualisierung der Daten erkauft.

Das Staging versagt, wenn personalisierteNachrichtenlisten, individuelle Suchanfra-gen (z. B. tolerante Volltextsuche im Nach-richtenarchiv) oder eine hohe Aktualitatder Nachrichten (bzw. integrierter LifeQuotes) gewahrleistet sein muss. DieseProblematik wird im Abschnitt 3.5 behan-delt.

3.4 AnwendungsspezifischeOptimierungvon Benutzerforen

Der Redaktionsprozess fur Benutzerforenist dem der Nachrichtenversorgung rechtahnlich. Es gibt eine �bersichtsseite, aufder die Themenschwerpunkte dargestelltwerden. Generell kann man diese �ber-sicht als statische Seite implementieren, dasich die Themenschwerpunkte selten an-dern. Innerhalb der Themenschwerpunktemussen jedoch nach der Erstellung neuerBeitrage alle abhangigen Seiten zur Lauf-zeit neu generiert werden. Je nach der Be-nutzerschnittstelle betrifft dies den Beitrag,die ubergeordnete Themenliste oder sogardie Gesamtubersicht, wenn diese Hinweiseauf das Datum des letzten Beitrags in denjeweiligen Themen enthalt.

Unter den moglichen Mitgliedern einerCommunitiy, die uber Foren kommunizie-ren, sind zwei Verhaltensmuster zu unter-scheiden:

& Die uberwiegende Mehrzahl (>90%)sind „Reader“, also Mitglieder, die nurkonsumieren.

& Der Rest wird durch den harten, aberrelativ kleinen Kern (<10%) der „Pos-ter“ gebildet, die mit eigenen Beitragenaktiv teilnehmen.



Fur einen „Reader“ ist erfahrungsgemaßdie Aktualitat eines Beitrags innerhalb einesgewissen Rahmens von einigen Minutennachrangig. Der „Reader“ ist zwar an aktu-ellen Beitragen interessiert, aber nicht unbe-dingt in Real-time. Er benutzt eine Com-munity wie eine Nachrichtenversorgung.

Die „Poster“ haben hohere Anforderungenan eine Community. Nach dem Erstelleneines Beitrags muss das Ergebnis sofortsichtbar sein. Dieses Feedback der offent-lichen Meinungsaußerung ist ein wichtigespsychologisches Erfolgserlebnis und be-lohnt die aktiven Teilnehmer. Bei neuenBeitragen ist die unmittelbare Aktualisie-rung der Web-Seiten notwendig, von derwiederum auch die passiven Mitgliederprofitieren. Das einfache Staging kann da-her nicht eingesetzt werden. Es ist aberdenkbar, einen Staging-Prozess zu imple-mentieren, der die Neugenerierung nachder Erstellung neuer Beitrage anstoßt.

Communities konnen daher vergleichbarzur Nachrichtenversorgung implementiertwerden. Aufgrund der Verteilung von akti-ven und passiven Teilnehmern und der aufdiverse Foren verteilten Beitrage kann einesolche Web-Anwendung durch ereignis-gesteuertes (im Gegensatz zum fixen zeit-gesteuerten) Staging ausreichend optimiertwerden.

Bei der Optimierung von Benutzerforenversagt das Staging jedoch, wenn zusatz-liche Feedback-Mechanismen realisiertwerden sollen oder direkt Kursinformatio-nen einzubinden sind. Beispiele fur weitereFeedback-Mechanismen sind:

& Darstellung, wie oft ein Beitrag gelesenwurde (dies erhebt alle Mitglieder in ei-nen „aktiven Status“)

& Auswertungen zur Laufzeit (die belieb-testen Foren, die beliebtesten Beitrageoder die aktivsten Mitglieder)

& integrierte Abstimmungen zu bestimm-ten Themen mit kontinuierlicher Aus-wertung zur Laufzeit

Solche Mechanismen erhohen signifikantden Gebrauchswert einer Community undkonnen wiederum durch Actives Cachingeffizient fur ein großes Auditorium umge-setzt werden.

3.5 AnwendungsspezifischeOptimierungvon personalisiertenAnwendungen

Personalisierte Web-Anwendungen werfendas Problem auf, dass alle Seiten so indivi-duell sind, dass es aufgrund des Speicher-bedarfs und der Anzahl moglicher Kom-binationen nicht sinnvoll erscheint, alleWeb-Seiten statisch abzulegen.

Bei genauerer Analyse der Benutzer-schnittstelle konnen jedoch oft Clips iden-tifiziert werden, die in identischer Form anzahlreichen Stellen verwendet werden kon-nen (ob eine Nachrichtenliste innerhalbder vom Anwender definierten Marktuber-sicht oder auf der allgemeinen Startseiteverwendet wird, andert nichts an den Da-teninhalten).

Somit sollten solche Clips ebenfalls nachder erstmaligen Generierung im Cache ge-speichert werden, um auch im anderenKontext ohne weitere Datenbankabfragenverwendet werden zu konnen.

Beim Aufruf von solchen zusammenge-setzten Web-Seiten mussen dann nur dieKonfigurationsdaten der Anwender ausder Datenbank gelesen werden, um die ein-zelnen Clips im entsprechenden Layoutzusammenzufuhren. Da diese mit hoherWahrscheinlichkeit bereits im Cache vor-liegen, entfallen teuere Datenbankabfragen.Selbst Zugriffe auf die Konfiguration kon-nen vermieden werden, wenn die Daten ineinem Session Cache (ein vom Browservon URL zu URL weitergereichter Spei-cherblock, der neben der obligatorischenSession-ID beliebige weitere Binardatenenthalten kann) oder in Client-seitigenCookies verwaltet werden.

3.6 AnwendungsspezifischeOptimierung derReal-time-Kursversorgung

Wahrend bei den bisherigen Szenarien mit-tels Staging oder multigranularem Cachingdie Anwendungen optimiert werden konn-ten, versagen diese Ansatze bei der Verfug-barmachung aktueller Kursinformationen.

Durch die hohe Dynamik der Daten (einWertpapier kann mitunter dutzende Preis-feststellungen pro Sekunde (z. B. an ver-

schiedenen Borsenplatzen) haben) ist einnormaler Cache wertlos, da die Gultigkeitder Information nicht ohne die zu vermei-denden Datenbankzugriffe uberpruft wer-den kann. Und weil sich Aktienmarkt-In-formationssysteme hauptsachlich mitKursinformationen beschaftigen, werdengerade diese Informationen an viele Stellenverwendet. Die durch Cache-Hierarchienerzielbaren Effizienzsteigerungen werdendadurch zunichte gemacht.

An dieser zentralen Stelle ist das ActiveCaching zwischen IS.SecureFTS undIS.ContentStore besonders effizienzstei-gernd. Fur Entwickler bleibt das ActiveCaching transparent. Da nach ca. 10 Minu-ten im Betrieb die Server uber 90% der re-levanten Kursinformationen auf der Daten-bank abboniert haben, fallen nur nochselten Datenbankzugriffe an und erfah-rungsgemaß konnen uber 95% der Abfra-gen ohne Datenbankzugriff abgearbeitetwerden.

4 Zusammenfassungund Ausblick

Die behandelten Szenarien haben am Bei-spiel von Aktienmarkt-Informationssyste-men gezeigt, wie anspruchsvolle Web-An-wendungen, in welchen sowohl eine sehrgroße Anzahl von Zugriffen pro Sekundestattfinden als auch eine hohe Aktualisie-rungsrate der anzuzeigenden Informatio-nen zu bewaltigen ist, effizient durch (er-eignisgesteuertes) Staging, multigranulareCaching-Hierarchien und Active Cachingoptimiert werden konnen.

Wenn Plattformen verwendet werden, diefur die jeweiligen Anwendungsgebiete ge-eignet sind, wird die Optimierung vom Sys-tem unterstutzt, wodurch Entwicklungs-und Infrastrukturkosten niedrig gehaltenwerden konnen. Die vorgestellten Mecha-nismen konnen zwar (mit hohemAufwand)nachimplementiert werden, sollten jedochbereits in der verwendeten Plattform inte-griert sein, da sie erst das Potenzial zur Op-timierung von Hochlast-Web-Anwen-dungen eroffnen. Sind diese Grundlagengegeben, gilt es folgende Gebote der anwen-dungsseitigen Optimierung zu befolgen:

& Datenbankoperationen sind auf ein ab-solutes Minimum zu reduzierenInformationen, die unter großem Zeit-aufwand aus Datenbanken gelesen wer-



den, sollten nach Moglichkeit vermiedenwerden. Wenn es unumganglich ist, Da-tenbanken zu benutzen, so mussen dieDatenbankzugriffe durch einen Cachegepuffert werden. Hierbei gilt, dass imBetrieb weit uber 90% der Web-Seiten-abfragen ohne Durchgriff auf die Daten-bankschicht auskommen mussen.

& Statische Anteile maximieren, dyna-mische Anteile minimierenAuch wenn die reine Lehre der Infor-matik sich an Modellen weidet, diekomplexe Abfragen uber zahlreicheSchichten abstrahiert und dynamischkonstruiert, sind die Anwendungen, dienach solchen Richtlinien gebaut werden,aufgrund der mangelnden Effizienz imBetrieb nicht wirtschaftlich.

& Gesamtdurchsatz optimierenBei Beachtung der oberen Regeln undder Maßgabe, dass Web-Seiten, die sehrhaufig abgerufen werden, auch entspre-chend schnell abrufbar sein mussen,schafft man durch multigranularesCaching und Active Caching Freiraumfur seltene und zeitintensive Abfragen.Dabei ist durch den Einsatz von Cachesein singularer Aufruf einer Web-Seitesogar geringfugig zeitaufwandiger (unddamit teuerer) als ohne Caches. Aber al-le darauf folgenden Aufrufe auf dieseSeite sind wesentlich schneller, da dieCaches bereits mit den richtigen Infor-mationen gefullt sind, wodurch sich dieSumme aller Ausfuhrungszeiten mini-miert. Um solche erstmaligen Abfragenohne signifikante Verzogerungen fur pa-rallele oder nachfolgende Abfragen zuermoglichen, muss die Datenbank abervon Routineabfragen weitgehend entlas-tet sein.

Diese Gebote (und die geeignete Plattform)haben den Autoren in der Vergangenheitgeholfen, anspruchsvolle Web-basierteMarktinformationssysteme zu konzipierenund zugig zu implementieren. Die Opti-mierung ermoglicht den wirtschaftlichenBetrieb von Web-Applikationen mit vielenMillionen Page Impressions auf wenigenIntel-basierten Server-Systemen.

Durch spezialisierte Plattformen lassen sichheutzutage im offenen Internet Funktionen

realisieren, die vor einigen Jahren wenigenProfis vorbehalten waren. Der Wett-bewerbsdruck und die hohen Anforderun-gen bei Web-Systemen im Finanzumfeldhaben gewissermaßen zwangslaufig zurEntwicklung des Active Caching gefuhrt.Dieser Mechanismen kann auch in vielenanderen verwandten Anwendungsdoma-nen eingesetzt werden. Die daraus resultie-renden Kostenreduktionen sind wichtigeWettbewerbsvorteile, die nicht nur Finanz-dienstleister in Anspruch nehmen sollten.

Literatur

[Apac02] Apache Software Foundation (Hrsg.):Apache Core Features. http://httpd.apache.org/docs-2.0/mod/core.html, Abruf am 2002-01-20.

[CGIoJ] The Common Gateway Interface NCSAhttp://hoohoo.ncsa.uiuc.edu/cgi/overview.html,Abruf am 2002-01-20.

[McGr95] Grath, Robert E.: Performance of Sev-eral HTTP Demons on an HP 735 Workstation:

Computing & Communications, NCSA 25April 1995.

[McGr96] McGrath, Robert E.: Measuring the Per-formance of HTTP Daemons, Computing &Communications NCSA, 5 February 1996.

[MGYC95] McGrath, Robert E.; Yeager, Nancy;Cain, Adam: World Wide Web servers at NCSA,NCSA access, Spring 1995.

[IVWoJ] Informationsgemeinschaft fur die Feststel-lung der Verbreitung von Werbetragern e.V.http://www.ivw.de/, Abruf am 2002-01-20.

[Micr02] Microsoft Corp. (Hrsg.): Persistent Con-nections. http://www.microsoft.com/WINDOWS2000/en/server/help/sag_WINS_und_PersistentConnections.htm,Abruf am 2002-01-20.

[NCSAoJ] NCSA HTTPd. http://hoohoo.ncsa.uiuc.edu/docs/Overview.html, Abruf am2002-01-20.

[W3C92a] Basic HTTP as defined in 1992.http://www.w3.org/Protocols/HTTP/HTTP2.html, Abruf am 2002-01-20.

[W3C92b]World Wide Web (A Summary)http://www.w3.org/History/19921103-hypertext/hypertext/WWW/Summary.html,Abruf am 2002-01-20.


Abstract

Efficient distribution of dynamic Web content

Methods for efficient distribution of dynamic content are required to run high capacity Webapplications economical. Those applications can be found especially around market infor-mation systems.The application and system architecture must be suited to respond user requests even duringsteep load peaks. To achieve this without inappropriate infrastructure investments, most ofthe database requests must be captured and processed on the application server layer. Suchmassively parallel systems are opening scaling paths along the more cost effective applica-tion server layer.Staging and multi-granular caching are cache based optimisation strategies that are used incertain application domains. However caching is always in conflict towards personalisationand real-time information.This conflict can be resolved by the Active Caching mechanism that is integrated in the pre-sented IS.Foundation platform. This is shown by analysing the methods and mechanisms onseveral aspects of the use case.

Keywords: dynamic content, real-time data, personalized content, high performance webapplications, performance measuring, caching mechanisms, performance optimization


Documents

Effiziente Distribution dynamischer Inhalte im Web; Efficient distribution of dynamic Web content;