Rails skalieren: So löst du typische Ruby on Rails Performance-Probleme

Rails ist tot – so hört man es alle paar Monate. Doch während Kritiker die Skalierbarkeit der Ruby-on-Rails-Plattform infrage stellen, bewältigt Shopify in der Praxis bis zu 489 Millionen Anfragen pro Minute und 53 Millionen Datenbankabfragen pro Sekunde. Doch was oft als "Rails kann nicht skalieren" missverstanden wird, sind meist Architektur- oder Implementierungsfehler – nicht Schwächen des Frameworks selbst.

Die Herausforderung liegt nicht im Rails-Code, sondern in der Art, wie Anwendungen darauf aufbauen. Im Folgenden zeigen wir dir die häufigsten Stolpersteine und wie wir sie in unseren Projekten erfolgreich behoben haben.

N+1-Abfragen: Der stille Performance-Killer

Ein klassischer Fehler in Ruby on Rails ist das N+1-Abfrageproblem. Stell dir vor, du listest 100 Blogbeiträge und möchtest für jeden den Autorennamen anzeigen. Ohne Optimierung führt Rails 101 Datenbankabfragen aus – eine für die Beiträge und 100 weitere für die Autoren. In der Entwicklung mit fünf Datensätzen mag das noch harmlos wirken, doch in der Produktion mit zehntausenden Einträgen führt dies zu massiven Ladezeiten und Datenbanküberlastung.

Die Lösung ist simpel: Eager Loading mit includes. Damit reduziert sich die Anzahl der Abfragen auf zwei – unabhängig von der Datenmenge.

# Langsam: 1 + N Abfragen
posts = Post.all
posts.each { |p| puts p.author.name }

# Schnell: Nur 2 Abfragen
posts = Post.includes(:author)
posts.each { |p| puts p.author.name }

Um solche Probleme früh zu erkennen, setzen wir das Bullet-Gem in der Entwicklungsumgebung ein. Es warnt Entwickler:innen vor unnötigen N+1-Abfragen, bevor der Code in die Produktion gelangt. Nach der Bereinigung der schwerwiegendsten Fälle bei unseren Top-10-Endpunkten sank die P95-Antwortzeit um etwa 40%.

Speicherlecks und Ruby-Garbage-Collector

Ruby-Anwendungen leiden oft unter Speicherproblemen, insbesondere bei langlaufenden Prozessen wie Sidekiq-Workern oder Puma-Workern. Der Standard-Speicherallokator malloc fragmentiert den Speicher schnell unter hoher Last, was zu steigendem Arbeitsspeicherbedarf (RSS) führt – bis ein Neustart erforderlich wird.

Zwei schnelle Lösungen haben sich bewährt:

• Wechsel zum jemalloc-Allokator: Viele Teams berichten von 20–40 % weniger RSS pro Worker durch diesen Allokator.
• YJIT in Ruby 3.3+ aktivieren: Shopify erzielte durch die Aktivierung von YJIT eine 15-prozentige Geschwindigkeitssteigerung in seiner Produktionscode-Basis.

Für Batch-Operationen empfiehlt sich zudem der Wechsel von Model.all.each zu find_each(batch_size: 1000). Diese einfache Anpassung hat uns mehr Ausfälle verhindert als jedes Monitoring-Tool.

Nebenläufigkeit: Puma, Sidekiq und blockierende Aufgaben

Die Standardkonfiguration von Puma ist für Minimalprojekte (MVP) geeignet, doch für Produktionslasten oft unzureichend. Hier die wichtigsten Optimierungen:

• Puma-Tuning: Wir setzen auf 5 Threads × 2 bis 4 Workers pro Dyno, basierend auf CPU- und Speicherkapazität – nicht auf Default-Werten.
• Blockierende Aufgaben auslagern: PDF-Generierung, API-Aufrufe an Drittanbieter, E-Mail-Versand und Bildverarbeitung gehören in Sidekiq.
• Priorisierte Sidekiq-Warteschlangen: Wir teilen Sidekiq in critical, default und low ein. So blockiert eine Massenexport-Aufgabe keine Webhook-Verarbeitung.

Drei Anpassungen, die 80 % der Produktionsprobleme bei Rails-Anwendungen lösen.

Die zentrale Erkenntnis: Rails skaliert – wenn die Architektur es zulässt

Ruby on Rails liefert das Fundament, aber du legst die Schienen. Skalierung gelingt nicht durch blindes Optimieren, sondern durch:

• Profiling vor Optimierung: Identifiziere Engpässe mit Tools wie rack-mini-profiler oder Skylight, bevor du Ressourcen verschwendest.
• Eager Loading vor Caching: Effiziente Datenbankabfragen sind der erste Schritt – Caching kommt danach.
• Langsame Aufgaben aus dem Request-Zyklus verlagern: Sidekiq, Hintergrundjobs und asynchrone Verarbeitung sind entscheidend.

Falls du feststeckst: Ruby-on-Rails-Entwickler:innen mit Erfahrung in Skalierungsprojekten können dir helfen, ohne ein Viertel deines Budgets zu verbrennen. Die meisten Rails-Skalierungsprobleme sind bekannte Probleme mit erprobten Lösungen – es gilt nur herauszufinden, welches aktuell deinen Code bremst.

Die Botschaft ist klar: Rails ist nicht das Problem. Die Architektur entscheidet.