Transkript

1 Design von skalierbaren Websystemen und Test auf ihre Leistungsbeschränkungen Basiert auf der Veröffentlichung Design and testing of scalable Web-based systems with performance constraints von Mauro Andrelini, Michele Colajanni und Paolo Valente. (Sept. 2005) Remo Bergmann 1

2 Gliederung 1.Einleitung 2.Design eines Websystems 3.Leistungstest eines Websystems 4.Fallstudie: online Buchhandlung 5.Fazit Remo Bergmann 2

3 1.Einleitung Moderne Webseiten bestehen aus unterschiedlichsten Funktionen, eingerichtet innerhalb komplexer Infrastrukturen (verteilte Komponenten, Server etc.) Reagieren auf unberechenbare Lastschwankungen Schlüsselfaktoren: Systemleistung und Skalierbarkeit Multi-Tier-Architektur Aber: Es gibt keine optimale Architektur Remo Bergmann 3

4 1.Einleitung Multi-Tier-Architektur: HTTP Schnittstelle: statischer Inhalt, Kommunikationsschnittstelle für Client Applikationslogik: Herz des Systems, generieren dyn. Inhalt, erstellen HTML Informationsquelle: DB mit Infos für dyn. Seiten Remo Bergmann 4

5 1.Einleitung Client Front-end layer Middle layer Back-end layer (1) Tomcat Servlet Container (1) MySQL DBMS (1) Apache MySQL httpd distributor (c) mod_jk distributor Tomcat Servlet Container (t) MySQL DBMS (m) Remo Bergmann 5

6 1.Einleitung Ziele der Veröffentlichung: Hauptaugenmerk: System mit 10 Millionen Request/Tag Flaschenhälse identifizieren und beseitigen Grobkörniger Ansatz: Geben 1.Ansatz zur Lösung des Problems Feinkörniger Ansatz: Detaillierte Ansicht von Komponenten oder auch Funktionen und Prozesse beides vereinigen Benutzung von off-the-shelf Software (Open Source) Remo Bergmann 6

7 2.Design eines Websystems Leistungsbeschränkung: Antwortzeit einer Webseite Laut Studie von IBM: Modem-Benutzer: Antwortzeit > 30 sec = unakzeptabel Modem-Benutzer: Antwortzeit < 20 sec = ausreichend Breitband-Benutzer: Antwortzeit > 10 sec = Benutzer verliert die Aufmerksamkeit auf den Browser Design eines ausreichenden Systems ohne Test sehr schwer Einziger modifizierbarer Parameter: maximale Systemkapazität Remo Bergmann 7

8 2.Design eines Websystems Ziele des Designs: Skalierbarkeit: Erhöhung der Systemleistung durch zusätzliche Hard-/Software Bandbreite: System muss eine Antwortzeit unter der Leistungsbeschränkung haben und auf unerwartete Arbeitsbelastung reagieren können Tendenz: System darf Antwortzeit nicht wegen Flaschenhälsen verringern (z.b. CPU) Remo Bergmann 8

9 2.Design eines Websystems Skalierbarkeit von Software: HTTP Schnittstelle (Apache, IIS), Informationsquelle (MySQL, DB2) basieren auf etablierten Technologien Applikationslogik: Entweder Skriptsprachen (PHP, ASP) oder komponentenbasierte Technologien (JSP,Servlets) Laut Studie: PHP schneller als Servlets bei einfacher e- commerce Anwendung Aber: Das gilt nur für kleine bis mittlere Webseiten. J2EE unterstützt Mechanismen zur Skalierbarkeit. Erreicht höheren Durchsatz bei großen Webseiten. Deswegen weiterer Fokus auf J2EE Remo Bergmann 9

10 2.Design eines Websystems Skalierbarkeit von Hardware: Abbilden von logischen auf physikalische Server Vertikaler Ansatz: Jeder logische Server wird auf höchstens einen physikalischen abgebildet Horizontaler Ansatz: Logische Server können auf vielen physikalischen verteilt sein Oftmals Ansätze kombiniert (bessere Skalierbarkeit und Zuverlässigkeit) z.b. 4-Knoten-Architektur: Apache, J2EE(Businesslogik, Applikationsfunktionen), MySQL Remo Bergmann 10

11 3.Leistungstest eines Websystems Sind die Leistungsbeschränkungen zufrieden stellend? Ziele des Designs müssen eingehalten werden (Skalierbarkeit, Bandbreite, Tendenz) System muss unter größter Last laufen Client simuliert unterschiedliche Arbeitsbelastungen Black-Box Test (grobkörnig): Web-System wird von aussen betrachtet (Antwortzeit, Durchsatz) Test erfolgreich, wenn es unter größter Last besteht Remo Bergmann 11

12 3.Leistungstest eines Websystems White-Box Test (feinkörnig): Wenn Black-Box nicht zufriedenstellend Genaue Analyse der internen Komponenten (bis hin zu Funktionen und Prozessebene) Flaschenhals finden, Flaschenhals identifizieren Danach Flaschenhals entfernen z.b. bessere Hardware, Software umstellen, verteilte Komponenten anders auf den Servern abbilden Remo Bergmann 12

13 4.Fallstudie: online Buchhandlung Vorher: Model der Arbeitsbelastung (workload model) Es gibt unterschiedliche Services im Websystem: S = { S1,,Sn } z.b. suchen, kaufen etc. Workload mix: Simuliert das Verhalten eines Clients W = { p1,,pm }, wobei pj die Wahrscheinlichkeit eines Aufrufes von Sj darstellt Es werden immer mehrere workload mixes definiert Um an die Grenzen des Systems zu kommen, wird die Frequenz der Anfragen des Clients erhöht Remo Bergmann 13

14 4.Fallstudie: online Buchhandlung Service ID Service Class Browsing Mix (p i ) Shooping Mix (p i )Ordering Mix (p i ) S 1 Buy Confirm 0,007 0,01 0,1 S 2 Execute Search 0,1 0,16 0,12 S 3 Search request 0,12 0,2 0,14 S 4 New products 0,11 0,05 0,005 S 5 Customer registration 0,009 0,03 0,13 S 6 Admin request 0,0009 0,0007 0,001 S 7 Order inquiry 0,003 0,008 0,003 S 8 Product detail 0,19 0,17 0,11 S 9 Admin response 0,0006 0,0007 0,001 S 10 Buy request 0,008 0,02 0,13 S 11 Order display 0,002 0,007 0,003 S 12 Home interaction 0,31 0,17 0,11 S 13 Best sellers 0,11 0,05 0,005 S 14 Shopping cart 0,02 0,11 0, Remo Bergmann 14

15 4.Fallstudie: online Buchhandlung Systemkonfiguration Apache mit mod_jk auf einem Server Tomcat 5.5 als Servlet Container auf einem Server MySQL 4.1 auf einem separaten Server Servers: 2.4 GHz Xeon CPU, 1 GB RAM, Linux (Kernel 2.6.8) Remo Bergmann 15

16 4.Fallstudie: online Buchhandlung Zuerst: Systemkapazität evaluieren durch Antwortzeit und Durchsatz Remo Bergmann 16

17 4.Fallstudie: online Buchhandlung Flaschenhals finden: Server einzeln testen Remo Bergmann 17

18 4.Fallstudie: online Buchhandlung Flaschenhals identifizieren: White-Box Test Konzentration auf Datenbank Konzentration auf Browsing-Mix Emulierung von 90 Anfragen pro Sekunde Mögliche Ursachen: CPU-Auslastung, Anzahl von Festplattenoperationen, begrenzende Ressourcen des Betriebssystems, offene Sockets, Prozess Decriptors Remo Bergmann 18

19 4.Fallstudie: online Buchhandlung Flaschenhals identifizieren: Durchschnitt 230 Sockets, Maximum > alles Ok Remo Bergmann 19

20 4.Fallstudie: online Buchhandlung Flaschenhals identifizieren: Durchschnitt 300 Operationen, Maximum > Ok Remo Bergmann 20

21 4.Fallstudie: online Buchhandlung Flaschenhals identifizieren: Summe CPU-Auslastung geht gegen 1 -> Flaschenhals Remo Bergmann 21

22 4.Fallstudie: online Buchhandlung Flaschenhals identifizieren: Komponente finden die CPU hauptsächlich belastet Systemmonitor: mysqld-prozess Mithilfe von Systemprofiler mysqld-fkt. Identifizieren Function(s) Call percentage buf_page_is_corrupted 75% I/O management 7% Tuple management 8% Others 10% Meiste CPU-Zeit durch buf_page_is_corrupted Remo Bergmann 22

23 4.Fallstudie: online Buchhandlung Flaschenhals identifizieren: buf_page_is_corrupted erzeugt Checksumme für asynchronen I/O Buffer um Datenkonsistenz zu gewährleisten Flaschenhals ist das asynchrone I/O Subsystem Flaschenhals entfernen: mehrere Möglichkeiten: besserer CPU, zweiter DB- Server, Tuning der Software (Parameter) Remo Bergmann 23

24 4.Fallstudie: online Buchhandlung Flaschenhals entfernen: Lösung hängt vom Know-how, Budget, Möglichkeiten zur Skalierung ab Tuning von Parametern: Größe des Anfragecaches erhöhen (reduziert I/O Operationen) Führte beim Black-Box Test nicht zum gewünschten Ziel Neuer White-Box-Test, Flaschenhals könnte sich geändert haben Horizontale Replication des DB-Servers ist beste Möglichkeit, Systemkapazität erhöht sich um Faktor Remo Bergmann 24

25 5.Fazit Es ist fundamental ein leistungsstarkes und zuverlässiges Websystem zu entwerfen, denn: Aufgrund unterschiedlichster Informationen, Services (News, Kreditkartennummern, persönliche Informationen etc.) erhöht sich die Komplexität und Durch die Steigerung der Beliebtheit von Webseiten erhöhen sich die Anfragen Es muss skalierbar sein, um zukunftssicher zu sein Remo Bergmann 25