Raus aus der Garage, rein in den Markt: Skalierung und Performance von Web-Applikationen René-Chr. Glembotzky CommunityCam...
Zur Person <ul><li>René-Chr. Glembotzky </li></ul><ul><li>32 Jahre </li></ul><ul><li>Gründer und Entwickler von free-sms.d...
Wunschzettel für unsere Webanwendung <ul><li>Hohe Verfügbarkeit </li></ul><ul><li>Skalierbarkeit </li></ul><ul><li>Perform...
High Availability... <ul><li>sorgt dafür, dass im Falle eines Ausfalls </li></ul><ul><ul><li>unsere Website erreichbar ble...
High Availability... <ul><li>sorgt dafür, dass im Falle eines Ausfalls </li></ul><ul><ul><li>unsere Website erreichbar ble...
High Availability <ul><li>Redundanz der Systeme </li></ul><ul><ul><li>2 Firewalls </li></ul></ul><ul><ul><li>2 Webserver <...
Skalierung <ul><li>Skalierung ist die Eigenschaft einer Plattform oder Anwendung, wachsenden Anforderungen gerecht zu werd...
Skalierung <ul><li>Beispiel: </li></ul><ul><li>Kurzfristig steigender Bedarf an Web- oder Datenbankkapazitäten </li></ul>
Was Skalierung NICHT bedeutet <ul><li>Reine Speed-Performance (2 Ghz vs. 3 Ghz)‏ </li></ul><ul><li>Betriebssystems (Linux ...
Skalierung und Performance sind nicht das gleiche
Skalierung und Performance sind nicht das gleiche
FAKT 1 <ul><ul><li>Eine Anwendung lässt sich nicht skalieren, </li></ul></ul><ul><ul><li>wenn sie nicht von vornherein daf...
FAKT 2 <ul><ul><li>Selbst wenn eine Anwendung für die Skalierung </li></ul></ul><ul><ul><li>entwickelt wurde, lässt die En...
Unsere neue Website :-)‏ <ul><li>Ein Server </li></ul><ul><li>Anwendung, Datenbank und Media auf einem System </li></ul><u...
Der Programmierer wird unzufrieden <ul><li>Anwendungs- und Datenbankebene werden auf getrennte Server verlagert. </li></ul>
Hurra: 1.000 Nutzer <ul><li>Media Files werden auch ausgelagert, um die Webserve mit weniger unnützen Prozessen zu belaste...
Das typische Startup-Setup <ul><li>Firewall/Load-Balancer </li></ul><ul><li>Mehrere Webserver </li></ul><ul><li>Datenbanks...
Das Startup wird erfolgreicher <ul><li>Redundante Firewall </li></ul><ul><li>Redundante Load Balancer </li></ul><ul><li>Me...
Immenser Gewinn an Popularität <ul><li>Nennung des Startups z.B. bei Digg oder Techcrunch </li></ul><ul><li>Caching: Rever...
Immenser Gewinn an Popularität
Point of no return... <ul><li>Caching mit Memcached </li></ul><ul><li>Datenbankreplikation „gibt auf“ </li></ul><ul><li>Da...
Point of no return...-
Wir erinnern uns....
PANIK! <ul><li>Überdenken des Geschäftsmodells </li></ul><ul><li>Überarbeitung der gesamten Applikation </li></ul><ul><li>...
Zurücklehnen... <ul><li>Applikation und Datenbank sind skalierbar </li></ul><ul><li>Performance ist „in Ordnung“ </li></ul...
Best Practices <ul><li>Trennung des IT-Bereichs in Development & Operations </li></ul><ul><li>Das Rad nicht zweimal erfind...
Best Practices <ul><li>Keine Über-Optimierung der Software -> bei Bedarf step-by-step anpassen </li></ul><ul><li>Last-Test...
Best Practices <ul><li>Software-Dokumentation </li></ul><ul><li>Release Management -> Entwickeln, Testen, Releasen </li></...
Schönes Wochenende :-)‏ [email_address]
Nächste SlideShare
Wird geladen in …5
×

Skalierung & Performance

2.353 Aufrufe

Veröffentlicht am

Veröffentlicht in: Technologie
0 Kommentare
2 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
2.353
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
9
Aktionen
Geteilt
0
Downloads
7
Kommentare
0
Gefällt mir
2
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Skalierung & Performance

  1. 1. Raus aus der Garage, rein in den Markt: Skalierung und Performance von Web-Applikationen René-Chr. Glembotzky CommunityCamp Berlin
  2. 2. Zur Person <ul><li>René-Chr. Glembotzky </li></ul><ul><li>32 Jahre </li></ul><ul><li>Gründer und Entwickler von free-sms.de mit 1.8 Mio Mitgliedern </li></ul><ul><li>IT Leiter von goolive.de Community mit 130 Mio. Seitenaufrufen pro Monat </li></ul>
  3. 3. Wunschzettel für unsere Webanwendung <ul><li>Hohe Verfügbarkeit </li></ul><ul><li>Skalierbarkeit </li></ul><ul><li>Performance </li></ul><ul><li>Einfache Verwaltung </li></ul><ul><li>Low Cost </li></ul><ul><li>Viele Features </li></ul><ul><li>€€€ </li></ul>
  4. 4. High Availability... <ul><li>sorgt dafür, dass im Falle eines Ausfalls </li></ul><ul><ul><li>unsere Website erreichbar bleibt, </li></ul></ul><ul><ul><li>unsere Nutzer und Kunden zufrieden sind und </li></ul></ul><ul><ul><li>weiterhin Revenues generiert werden. </li></ul></ul>
  5. 5. High Availability... <ul><li>sorgt dafür, dass im Falle eines Ausfalls </li></ul><ul><ul><li>unsere Website erreichbar bleibt, </li></ul></ul><ul><ul><li>unsere Nutzer und Kunden zufrieden sind und </li></ul></ul><ul><ul><li>weiterhin Revenues generiert werden. </li></ul></ul><ul><li>IT-Leitung behält ihren Job ;-)‏ </li></ul>
  6. 6. High Availability <ul><li>Redundanz der Systeme </li></ul><ul><ul><li>2 Firewalls </li></ul></ul><ul><ul><li>2 Webserver </li></ul></ul><ul><ul><li>2 Datenbankserver </li></ul></ul><ul><ul><li>usw... </li></ul></ul>
  7. 7. Skalierung <ul><li>Skalierung ist die Eigenschaft einer Plattform oder Anwendung, wachsenden Anforderungen gerecht zu werden und dahingehend vorbereitet zu sein, dass die Systeme bei Bedarf flexibel erweitert werden können. </li></ul>
  8. 8. Skalierung <ul><li>Beispiel: </li></ul><ul><li>Kurzfristig steigender Bedarf an Web- oder Datenbankkapazitäten </li></ul>
  9. 9. Was Skalierung NICHT bedeutet <ul><li>Reine Speed-Performance (2 Ghz vs. 3 Ghz)‏ </li></ul><ul><li>Betriebssystems (Linux vs. Solaris)‏ </li></ul><ul><li>Technologie (PHP vs. Python vs. Rails)‏ </li></ul><ul><li>Hardware (AMD vs. Intel)‏ </li></ul><ul><li>Code Optimierung (10 vs. 10.000 Zeilen Quelltext)‏ </li></ul><ul><li>Storage Technologie (SAN vs. NAS)‏ </li></ul>
  10. 10. Skalierung und Performance sind nicht das gleiche
  11. 11. Skalierung und Performance sind nicht das gleiche
  12. 12. FAKT 1 <ul><ul><li>Eine Anwendung lässt sich nicht skalieren, </li></ul></ul><ul><ul><li>wenn sie nicht von vornherein dafür </li></ul></ul><ul><ul><li>konzipiert wurde. </li></ul></ul>
  13. 13. FAKT 2 <ul><ul><li>Selbst wenn eine Anwendung für die Skalierung </li></ul></ul><ul><ul><li>entwickelt wurde, lässt die Entwickler wahnsinnig </li></ul></ul><ul><ul><li>werden, sobald es erforderlich ist. </li></ul></ul>
  14. 14. Unsere neue Website :-)‏ <ul><li>Ein Server </li></ul><ul><li>Anwendung, Datenbank und Media auf einem System </li></ul><ul><li>Einfach zu verwalten </li></ul><ul><li>Keine Ausfallsicherheit </li></ul>
  15. 15. Der Programmierer wird unzufrieden <ul><li>Anwendungs- und Datenbankebene werden auf getrennte Server verlagert. </li></ul>
  16. 16. Hurra: 1.000 Nutzer <ul><li>Media Files werden auch ausgelagert, um die Webserve mit weniger unnützen Prozessen zu belasten... </li></ul>
  17. 17. Das typische Startup-Setup <ul><li>Firewall/Load-Balancer </li></ul><ul><li>Mehrere Webserver </li></ul><ul><li>Datenbankserver </li></ul><ul><li>Internes Storage </li></ul><ul><li>Leicht zu verwalten </li></ul><ul><li>Keine Redundanz </li></ul><ul><li>Günstiger Betrieb </li></ul>
  18. 18. Das Startup wird erfolgreicher <ul><li>Redundante Firewall </li></ul><ul><li>Redundante Load Balancer </li></ul><ul><li>Mehr Webserver für mehr Performance </li></ul><ul><li>Datenbank Storage zieht um -> SAN </li></ul><ul><li>Aus Anwendungssicht relativ simpel... </li></ul>
  19. 19. Immenser Gewinn an Popularität <ul><li>Nennung des Startups z.B. bei Digg oder Techcrunch </li></ul><ul><li>Caching: Reverse Proxy (Squid/Varnish)‏ </li></ul><ul><li>Mehr Webserver </li></ul><ul><li>Replikation der Datenbank </li></ul><ul><li>Applikation überarbeiten :-)‏ </li></ul>
  20. 20. Immenser Gewinn an Popularität
  21. 21. Point of no return... <ul><li>Caching mit Memcached </li></ul><ul><li>Datenbankreplikation „gibt auf“ </li></ul><ul><li>Datenbankpartitionierung macht Sinn </li></ul><ul><li>Mediacluster für Content </li></ul><ul><li>Neustrukturierung der Applikation und Datenbank erforderlich </li></ul>
  22. 22. Point of no return...-
  23. 23. Wir erinnern uns....
  24. 24. PANIK! <ul><li>Überdenken des Geschäftsmodells </li></ul><ul><li>Überarbeitung der gesamten Applikation </li></ul><ul><li>Datenbankstrukturierung anhand von „weichen“ Features </li></ul><ul><ul><li>Partitionierung nach Herkunft, Nutzer ID, Themengebiet </li></ul></ul><ul><ul><li>Einsatz eines „Finde-Mechanismus“, um herauszufinden, welcher Nutzer in welchem Cluster beheimatet ist </li></ul></ul>
  25. 25. Zurücklehnen... <ul><li>Applikation und Datenbank sind skalierbar </li></ul><ul><li>Performance ist „in Ordnung“ </li></ul><ul><li>Neue Features werden wieder entwickelt </li></ul><ul><li>Code wird teilweise optimiert </li></ul><ul><li>Wachstum, aber managebares Wachstum </li></ul>
  26. 26. Best Practices <ul><li>Trennung des IT-Bereichs in Development & Operations </li></ul><ul><li>Das Rad nicht zweimal erfinden. Vorhandene Lösungen nutzen. </li></ul><ul><li>Einfaches soll so einfach wie möglich gemacht werden (aber nicht einfacher *g*)‏ </li></ul><ul><li>Gutes Equipment verwenden (Sun, Dell)‏ </li></ul><ul><li>Dienste trennen, „sanfte Updates“ -> Troubleshooting </li></ul>
  27. 27. Best Practices <ul><li>Keine Über-Optimierung der Software -> bei Bedarf step-by-step anpassen </li></ul><ul><li>Last-Tests der Applikation -> bevor es live zu Problemen führt </li></ul><ul><li>Caching! Caching! Caching! </li></ul><ul><li>Memory! Memory! Memory! (64 bit)‏ </li></ul><ul><li>Nice to have vs. have to have -> Performance Analyse neuer Features </li></ul>
  28. 28. Best Practices <ul><li>Software-Dokumentation </li></ul><ul><li>Release Management -> Entwickeln, Testen, Releasen </li></ul><ul><li>Source Control </li></ul>
  29. 29. Schönes Wochenende :-)‏ [email_address]

×