Ruby is slow

R

In den letzten Wochen hat Twitter einen unglaubliche Popularität rund um den Globus erlangt. Dank der offenen API gibt es jede Menge spannender Add-Ons, Clients und Mashups. Nur eins stört die globale Twitter Community: Der Speed. Kaum wurde Twitter richtig groß – wurde es gleichzeitig verdammt langsam. Und ist es zuweilen immer noch.

In einem Interview mit Josh Kenzer lässt Alex Payne,einer der Twitter Developer tief in die Karten der derzeit größen auf Ruby on Rails basierten Platttform blicken:

The common wisdom in the Rails community at this time is that scaling Rails is a matter of cost: just throw more CPUs at it. The problem is that more instances of Rails (running as part of a Mongrel cluster, in our case) means more requests to your database. At this point in time there’s no facility in Rails to talk to more than one database at a time. The solutions to this are caching the hell out of everything and setting up multiple read-only slave databases, neither of which are quick fixes to implement. So it’s not just cost, it’s time, and time is that much more precious when people can[’t] reach your site.

None of these scaling approaches are as fun and easy as developing for Rails. All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.

It’s also worth mentioning that there shouldn’t be doubt in anybody’s mind at this point that Ruby itself is slow. It’s great that people are hard at work on faster implementations of the language, but right now, it’s tough. If you’re looking to deploy a big web application and you’re language-agnostic, realize that the same operation in Ruby will take less time in Python. All of us working on Twitter are big Ruby fans, but I think it’s worth being frank that this isn’t one of those relativistic language issues. Ruby is slow.

Zusammengefasst kann man also konstatieren:

  • Ruby on Rails ist nicht einfach durch das ergänzen neuer Hardware zu skalieren
  • Es kostet viel Zeit, eine Rails Umgebung auf bessere Skalierbarkeit umzustellen
  • Dabei verliert man viele der schönen Features von RoR
  • Die langsamen bzw. performancehungrigen Teile der Anwendung sollten mit einer anderen Sprache realisiert werden

Ich finde diese Aussage sehr spannend, insbesondere da ich bislang zweimal mit Ruby on Rails Experten zusammengetroffen bin, die beide stets die leichte Skalierbarkeit vertreten haben: Auf der FoWa 2006 sprach dazu David Heinemeier Hansson und ähnliches hörte ich auch bei einem Workshop bei Prof. Carsten Bormann in Offenbach.

Aber dieser Bericht aus der Praxis spricht natürlich eine andere Sprache. Also Finger Weg von Ruby on Rails bei … bei Projekten die so schnell, so stark wachsen wie Twitter? Das weiß natürlich niemand vorher. Und ob PHP sich so leicht so schnell hochskalieren lässt weiß ich auch nicht. Fazit also: RoR is sicher für 99.9% aller WebApps völlig ok. Dem 0.1% das wirklich binnen kürzester absolut raktenartig wächst wird man auch einige Tage Refactoring verzeihen, oder?

Mittlerweile gibt es ein Update zu diesem Thema
Auf seinem Blog bezieht David Heinemeier Hansson Stellung zu den Vorwürfen von Alex und hat dabei grundsätzlich einige gute Punkte:

Scaling is the act of removing bottlenecks. When you remove one bottleneck (like application code execution), you tend to reveal another (like database queries). That’s natural and means you’re making progress. But you have to keep your marbles straight when doing this. If your bottleneck has moved to the database, you probably won’t see big results by replacing pretty constructs with ugly ones. In other words, if a database query is taking 0.5 seconds, improving a loop from 0.05 to 0.01 seconds is not worth bothering with at this point.

Second, when you work with open source and you discover new requirements not met by the software, it’s your shining opportunity to give something back. Rather than just sit around idle waiting for some vendor to fix your problems, you get the unique chance of being a steward of your own destiny. To become a participant in the community rather than a mere spectator. This is especially true with frameworks like Rails that are implemented in high-level languages like Ruby. The barriers to contribution are exceptionally low.

9 Kommentare

  • Hallo Oliver,

    die Kontroverse kocht ja gerade etwas. Alex Payne hat die Sache in einem Kommentar zu David Heinemeier Hansson’s Blogpost (http://www.loudthinking.com...) noch einmal etwas deutlicher klargestellt.

    Beste Grüße,

    Stephan Hansen-Oest

  • Nun, wenn ich mir die ein oder anderen Benchmark-Vergleiche zwischen PHP und RoR anschaue, mag ich stark bezweifeln das eine entsprechende PHP Variante einfacher zu skalieren oder überhaupt dem aktuellen Umfang von Twitter standhalten könnte *g*.
    Überhaupt, skalierbarkeit ist das eine, aber ab einem bestimmten Punkt reicht es nichtmehr aus, eine Anwendung zu skalieren, sondern einfach die Hardware bis zum erbrechen aufzustocken.
    Was mich aber an der Aussage von Josh Kenzer interessieren würde ist, ob sie (Twitter) „einfach“ mal einen Datenbankcluster probiert haben. So wie ich das verstanden habe, wurde lediglich der Versuch, mehrere Datenbank direkt an die Anwendung anzuschliessen, durchgeführt!?

  • Wenn eine DB nicht reicht würde ich auch vorschlagen einen Cluster mit Loadbalancer (zB. ldirectord) zu nutzen.

  • Cluster und Loadbalancer nuetzen unter umständen wenig. Wenn die Daten nicht vollständig partitionierbar sind, so wird der Tempovorteil recht schnell von der Internode-Kommunikation aufgefressen. Schönes Beispiel sind hier die RAC-Cluster, die auch auch mit viel Wissen behandelt werden wollen, damit diese wirklich einigermassen skalieren.

  • Hm, das kenn ich ja, denn eines der Dinge, die ich viel zu hören bekomme, ist, dass Plone langsam sei ;-) (Das stimmt natürlich auch aber andererseits hat es eben auch direkt einen recht grossen Funktionsumfang , der halt immer dabei ist, ob man ihn braucht oder nicht).

    Was das Beispiel hier aber zeigt ist, dass man sich doch, egal welche Programmiersprache man benutzt, immer ab einem bestimmten Punkt um das Load-Balancing kümmern muss und evtl. auch seine Applikation schon von vornherein mit dieser Tatsache im Blick konzipiert.

    Vielleicht liegt auch der Schlüssel hier nicht darin, immer schneller Implementierungen vorzulegen, sondern eher darin, die Skalierbarkeit zu erhöhen. Aber alles leider keine trivialen Probleme.

    Und dummerweise kommen diese eigentlichen Probleme auch immer erst recht spät zum Vorschein und sind auch immer etwas schwer im vorhinein zu testen.

Instagram