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