• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Scaling Rails
 

Scaling Rails

on

  • 2,486 views

Presentation by Jonathan Weiss about Scaling and Performance, focused at Ruby on Rails. Presented at Rails Konferenz 2009 in Offenbach/Frankfurt.

Presentation by Jonathan Weiss about Scaling and Performance, focused at Ruby on Rails. Presented at Rails Konferenz 2009 in Offenbach/Frankfurt.

Statistics

Views

Total Views
2,486
Views on SlideShare
2,429
Embed Views
57

Actions

Likes
1
Downloads
3
Comments
0

3 Embeds 57

http://blog.peritor.com 50
http://www.slideshare.net 6
http://webcache.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Scaling Rails Scaling Rails Presentation Transcript

    • Scaling Rails
      • Jonathan Weiss, 02.09.2009
      • Peritor GmbH
    • Scaling Rails
    • Scaling Rails
    • Rails
    • Performance
      • Wikipedia:
        • Das Wort Leistung (engl. Performance ) wird in der Informatik verwendet, um das Vermögen eines Datenverarbeitungssystems zu beschreiben, Aufgaben allgemein ( Funktionalität ) oder auf bestimmte Weise ( schnell , gleichzeitig , ununterbrochen usw.) auszuführen.
    • Performance Probleme
      • Benutzer warten auf Antwort
      • Anfragen dauern zu lange
      • Es werden nicht genug Anfragen verarbeitet
    • Scaling = Δ Performance
    • + Δ Performance = Weniger Probleme - Δ Performance = Mehr Probleme
    • Scaling
        • Kein Selbstzweck – Problem loesen
        • Gewaehrleisten, dass die Seite in bestimmter Zeit erreichbar ist
        • Request/sec und response time
      Fixing something that’s wrong
    • Vorgehen Repeat
    • FIN
    • Realität
    • Wissen wir nicht Repeat Wissen wir nicht Wissen wir nicht Wir haben XYZ optimiert Es sollte jetzt, hoffentlich…
    • Resultat
    • Scaling Tricks
    • Scaling Tricks NO TRICKS!
      • Schritt 1 bis 5
      • Pragmatismus
    • Pragmatismus
      • Kosten/Nutzen immer bedenken
      • Aufhören, wenn es schnell genug ist
      • Kein Over-Engineering
    • Not knowing Always measure performance
    • MEsasure
      • Kosten/Nutzen immer bedenken
      • Aufhören, wenn es schnell genug ist
      • Kein Over-Engineering
    • Munin
    • Munin
    • Munin
    • Monit
        • Apache
    • Monit
        • Mongrel
    • Monitoring
      • Wie ist die Performance meiner Seite jetzt?
      • Vorraussetzung, um pro-aktiv zu handeln
      • Essenziell
    • Not knowing Then find out what is slow, and why
    • Rails Production Log
        • RAWK, production log analyzer, Request-log-analyzer & co
    • New Relic
    • MySQL Slow Query Log
        • mysqldumpslow, mysql_slow_log_parser, mysql-slow-query-log-parser, …
    • Profiler
        • ruby script/benchmark/profiler
    • Not knowing Now go and fix it!
    • Not knowing Now go and fix it! Ein Plan muss her
    • Constraints
      • Begrenzte Ressourcen:
          • Geld
          • Entwickler
          • Zeit
    • Hardware ist billig
      • +2 GB RAM pro Server
      Vs. 2 Wochen Optimierung Speicher
    • Frontend Performance
      • Zu oft ignoriert
      • Teilweise bis zu 90% der Geschwindigkeit aus Benutzersicht
      • Yslow und JavaScript-Profiler sind ein Muss!
    • Asynchrone Berechnungen
      • Aufwändige Aufgaben werden außerhalb des Requests verarbeitet
      Message/Queue Scheduler
    • Datenbank
      • IO und damit die Datenbank ist typischerweise die erste große Hürde
      • Das Skalieren der Datenschicht ist das schwierigste Problem:
          • Read-Slaves
          • Master-Master-Setup
          • Replication
          • Document-Databases
          • Sharding
          • ...
    • Datenbank
      • IO und damit die Datenbank ist typischerweise die erste große Hürde
      • Das Skalieren der Datenschicht ist das schwierigste Problem:
          • Read-Slaves
          • Master-Master-Setup
          • Replication
          • Document-Databases
          • Sharding
          • ...
    • Archivierung
      • (Historische) Daten reduzieren
        • Löschen
        • Aggregieren
        • Partitionieren
        • Verhindern von exponenziellem Wachstum
        • DB Indices reduzieren
        • Auslagern in separate Datenbanken
        • Auslagern in andere Datenform
    • Algorithmus
      • Manchmal ist auch einfach die Formel falsch
            • O(N^2) & co
            • Pure Ruby statt C
            • Zentral statt verteilt
            • Relational statt dokumentorientiert
    • Golden Hammer
      • Das richtige Tool für das richtige Problem
            • Rails Metal
            • Caching
            • DB-Replikation
            • DB-Sharding
            • Hardware Load-Balancing
            • Rails selber?
            • ...
    • Patching Ruby (GC, Heap & co)
      • Sehr selten notwendig: You are not twitter!
      • Gefahr von ununterstützer Version
      • Tuning-Zeit meist anders sinnvoller einsetzbar
      • Wenn, dann: Ruby Enterprise Edition
    •  
    • “ Kein Plan überlebt den ersten Feindkontakt”
            • Helmuth von Moltke
    • Over-Engineering
      • Einfach gewinnt:
          • Komplexität
          • Wartbarkeit
          • Robustheit
          • Skalierung
          • Anpassungsfähigkeit
          • ...
    • Ein Plan muss her Umsetzung
    • Not knowing Verify!
    • Benchmarking
        • ruby script/benchmark/benchmarker
        • Apache benchmark
    • Benchmarking Results
    • Beobachtungen nach dem Deployment
    • Not knowing Verify! Ich liebe es, wenn ein Plan funktioniert
    • Q & A Fragen?
    • Thank you
          • http://www.flickr.com/photos/49656291@N00/3708459793
          • http://www.flickr.com/photos/7437378@N08/448316403
          • http://www.myownmusicindustry.nl/images/mr-t-fro.jpg
          • https://nodpi.org/wp-content/uploads/2008/06/trainwreck.png
          • http://www.olino.org/us/wp-content/uploads/2009/03/response-time-long.jpg
          • http://www.thehollywoodnews.com/thn/assets_c/2009/05/MrT15-thumb-500x500-297.jpg
          • http://www.geocities.com/televisioncity/9348/ateam2.jpg
          • http://www.geocities.com/televisioncity/9348/ateam3.jpg
          • http://fc08.deviantart.com/fhttp://fc08.deviantart.com/fs38/f/2008/351/6/0/Ivory_Tower_by_Hideyoshi.jpgs38/f/2008/351/6/0/Ivory_Tower_by_Hideyoshi.jpg
          • http://de.wikipedia.org/wiki/Datei:GFM_Moltke.jpg
    • Peritor GmbH Blücherstraße 22 10961 Berlin Telefon: +49 (0)30 69 20 09 84 0 Telefax: +49 (0)30 69 20 09 84 9 Internet: www.peritor.com E-Mail: kontakt@peritor.com  Peritor GmbH - Alle Rechte vorbehalten