Your SlideShare is downloading. ×
0
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Skalierung & Performance
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Skalierung & Performance

2,005

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,005
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Raus aus der Garage, rein in den Markt: Skalierung und Performance von Web-Applikationen René-Chr. Glembotzky CommunityCamp Berlin
  • 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. 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. 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. 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. 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. 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. Skalierung <ul><li>Beispiel: </li></ul><ul><li>Kurzfristig steigender Bedarf an Web- oder Datenbankkapazitäten </li></ul>
  • 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. Skalierung und Performance sind nicht das gleiche
  • 11. Skalierung und Performance sind nicht das gleiche
  • 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. 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. 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. Der Programmierer wird unzufrieden <ul><li>Anwendungs- und Datenbankebene werden auf getrennte Server verlagert. </li></ul>
  • 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. 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. 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. 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. Immenser Gewinn an Popularität
  • 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. Point of no return...-
  • 23. Wir erinnern uns....
  • 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. 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. 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. 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. Best Practices <ul><li>Software-Dokumentation </li></ul><ul><li>Release Management -> Entwickeln, Testen, Releasen </li></ul><ul><li>Source Control </li></ul>
  • 29. Schönes Wochenende :-)‏ [email_address]

×