Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
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.488 Aufrufe

Veröffentlicht am

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

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]

×