O'Reilly logo

Rails Kochbuch by Rob Orsini

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

First
|
399
Max.
Linie
Max.
Linie
Kapitel 12
KAPITEL 12
Performance
12.0 Einführung
Eine Betrachtung der Performance von Webanwendungen ist kompliziert. Performance
hat viele verschiedene Aspekte, nicht zuletzt die Frage, ob der Benutzer eine Anwendung
subjektiv als schnell oder langsam empfindet. Hält er sie für schnell, kümmert es ihn nicht
weiter, ob sich Ihre Server zu Tode schuften (auch wenn Sie das sehr wohl interessieren
dürfte). Andererseits wird ein Benutzer mit einer langsamen Internetverbindung Ihre
Anwendung als langsam empfinden, selbst wenn Ihre Server ihr Bestes geben. Natürlich
haben Sie keinen Einfluss auf die Internetverbindung des Benutzers bzw. auf subjektive
Wahrnehmungen. Unabhängig davon, werden Sie ein Ansprechverhalten Ihrer Anwen-
dung anstreben, das dem der populären Internet-Sites mit vergleichbarem Traffic ent-
spricht. Natürlich ist das ein sehr allgemeines Ziel und hat mehr mit den Erwartungen der
Benutzer zu tun als mit dem, was Ihre Anwendung durchlaufen muss, um die Inhalte zu
generieren.
Nehmen wir beispielsweise an, Ihre Anwendung führt ein sehr komplexes Reporting über
eine sehr große Datenmenge aus. Die dynamische Generierung dieser Reports kann recht
lange dauern. Die Anwender erwarten hingegen, dass Sie das Problem irgendwie gelöst
haben, und wollen die meisten Seiten des Reports in der gleichen Zeitspanne sehen wie
statisches HTML.
Denken Sie einen Augenblick über die schnellste Webanwendung nach, die Sie entwi-
ckeln könnten. Das wäre wohl ein in C geschriebenes CGI-Programm. In diesem Fall wäre
der Performance-Flaschenhals wohl nicht die Anwendung selbst, sondern vielleicht eine
Netzwerkschnittstelle oder -verbindung. Das eigentliche Performance-Problem wäre
natürlich, dass die Entwicklung dieser Webanwendung in C schwierig zu skalieren und zu
pflegen ist. Glücklicherweise haben wir das schon hinter uns gelassen und besitzen wun-
derbare Frameworks wie Rails, die uns einen Großteil der Komplexität solcher Low-Level-
Lösungen abnehmen.
Sie verwenden Rails, weil es die Entwicklung von Webanwendungen einfacher und
schneller macht. Aber wie wirkt sich das auf die Performance für den Benutzer aus? Häufig
00____RailsKochbuch.book Seite 399 Dienstag, 3. Juli 2007 8:13 08
Max.
Linie
Max.
Linie
400
|
Kapitel 12: Performance
Links
bezahlen Sie eine solche High-Level-Entwicklung mit der allgemeinen Performance der
Anwendung. Das gilt insbesondere für interpretierte dynamische Sprachen.
Rails behandelt Performance-Aspekte auf verschiedene Art und Weise. Die erste ist das
Konzept der Umgebungen. Wenn Sie Ihre Rails-Anwendung entwickeln, legen Sie fest,
dass Rails im Development-Modus (also im Entwicklungsmodus) laufen soll. Dabei wird
die gesamte Rails-Umgebung bei jedem Request neu geladen, so dass Änderungen an Ihrer
Anwendung sofort sichtbar werden. Sobald Sie die Anwendung produktiv einsetzen,
ändert sich die Situation. Nun wollen Sie schnellere Reaktionszeiten und weniger das
Neuladen von Klassen und Bibliotheken sehen, die sich zwischen den Requests nicht
mehr ändern. Für diesen Zweck ist der Production-Modus (d.h. der Produktionsmodus)
gedacht. Wird eine Anwendung im Produktionsmodus gestartet, wird die gesamte Rails-
Umgebung nur einmal geladen. Gegenüber dem Entwicklungsmodus erleben Sie einen
drastischen Performance-Schub.
Gehen wir noch mal zurück zu den Erwartungen: Die Benutzer sehen nicht, was hinter
den Kulissen passiert, und glauben, dass alles so schnell sein muss wie statisches HTML.
Ein recht hoher Anspruch, aber wenn man darüber nachdenkt, kann ein nicht technischer
Anwender kaum wissen, welche Elemente einer Seite dynamisch generiert werden und
welche nicht. Er wird Performance-Probleme sehen, und es könnte Sie einiges kosten,
wenn er entscheidet, dass der Inhalt das Warten nicht lohnt.
Rails hat auch für dieses Problem eine Lösung. Rails kann den Inhalt dynamischer Seiten
in einem Cache zwischenspeichern und auf diese Weise (wenn möglich) Seiten wiederver-
wenden, die bereits generiert wurden. Fordert der Benutzer eine dynamische Seite an,
wird das Ergebnis in einem Cache gespeichert. Nachfolgende Requests für den gleichen
Inhalt werden als statisches HTML zurückgeliefert, da angenommen wird, dass keine
dynamische Regenerierung erforderlich ist. Nach einer bestimmten Zeitspanne oder viel-
leicht auch nach einer bestimmten Aktion, die den dynamischen Inhalt ändern kann (etwa
ein Update der Datenbank), wird der zwischengespeicherte Inhalt ungültig (oder
gelöscht), und eine neue Version wird im Cache angelegt.
Rails kennt drei verschiedene Wege, um Inhalte in einem Cache zwischenzuspeichern.
Dieses Kapitel stellt alle drei vor. Wir stellen auch einige Tools zur Performance-Messung
vor. Letztendlich können Sie nur über eine Messung bestimmen, ob die Performance ver-
bessert wurde.
Unter dem Strich hängen Ihre Performance-Anforderungen von einer Reihe unterschied-
licher Faktoren ab. Sie können viele Dinge tun, um die Performance durch Hardware oder
auch durch clevere Konfigurationen zu verbessern. Dieses Kapitel behandelt (hauptsäch-
lich) Lösungen, die das Rails-Framework selbst betreffen.
Natürlich ist die Performance-Messung letztendlich eine statistische Analyse, und die Sta-
tistik ist eine ausgesprochen komplexe Angelegenheit. Nur zu leicht übergeht man wich-
tige Details, weshalb es besonders wichtig ist, sich streng an die Fakten zu halten und
genaue Messungen durchzuführen. Sie müssen wissen, was Sie messen und was das
00____RailsKochbuch.book Seite 400 Dienstag, 3. Juli 2007 8:13 08

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required