6 ms·

I've seen a lot of dumb Rails server configs and even dumber usages of Rails without any tuning at all. With a couple weeks or a month of work I could shrink t

I've seen a lot of dumb Rails server configs and even dumber usages of Rails without any tuning at all. With a couple weeks or a month of work I could shrink the hosting fees or resources consumed by a factor of 5 out of most Rails apps that are sitting up around 30 servers... and probably a factor of 10. Leaving aside whatever rookie or even intermediate mistakes were made in their Ruby code or their database, this post indicates a lack of understanding of what happened when their server fell over. Proper tuning of a deployment should not trigger a 100% failure mode like this. These folks were itching to get off of Ruby for whatever reason... after all their roots were in Java. If your goal is to do a rewrite and learn a new language and gain some notoriety why waste time learning what you did wrong with Ruby or your server config?

dkkkdkdk 14y ago
TLDR: I'm butt-hurt that people are dumping Ruby. And because I hate Java I'll blame it on it also.
- sabat 14y ago
  Not quite. He's saying that people who think Ruby is slow are often people who have no idea how to performance-tune it.
  - bpicolo 14y ago
    Well, more of the time it's because Ruby actually is, in fact, slow.
    - pjmlp 14y ago
      I though the implementations were slow or fast, not the languages.
      - codygman 14y ago
        Typically a language is considered slow or fast based on it's most popular implementation, sadly.
      - ajanuary 14y ago
        True, though language design can have implications on how fast things can be implemented.
        pjmlp 14y ago
        Agreed, but it is still an implementation issue, because one can eventually discover ways to optimize such cases without changing the language.
    - sabat 14y ago
      Ruby is not, in fact, slow. This myth has been debunked so many times that I'll just leave the googling to you as an exercise.
btilly 14y ago
Your inability to understand their clear description of a basic cascading failure mode under load speaks poorly of your actual knowledge and experience. Given that, I have to take everything else that you say with a large helping of salt.
- ef4 14y ago
  Their description of the root problem was very superficial: > At some threshold above 50%, our Rails servers would spike up to 100% CPU usage and become unresponsive. Yes, but why? What exactly were those processes doing? Why the sudden change at a particular threshold? Their lack of detailed investigation into this makes their post useless to me -- I have no way of knowing (1) what specific aspect of Ruby's architecture makes it unfit for their problem?, or (2) is their application doing something stupid that causes the problem in first place?
  - btilly 14y ago
    If you read that sentence in context, your questions are answered. Here are the previous two sentences for context. The bigger problem was dealing with big traffic spikes. When a big spike in traffic came in, it created a domino effect that would take take down our entire cluster Given the article to that point, it is clear what is happening. They are maintaining a steady state of X% (where X is above 50), then a big traffic spike comes along. That traffic load is not distributed equally (my guess is because requests are not created equal) and there is a hot spot. The hot spot fails, then increases the load on everything else. After this repeats a few times, there is insufficient capacity. In other words at some steady state threshold above 50%, you wind up without sufficient capacity to handle traffic spikes. Nothing in this failure scenario is specific to Rails. It is a well-known failure mode for a cluster under load with a push based architecture (which http requests are). The fact that you did not understand that description speaks poorly of your problem solving skills. Now they may well have been doing something trivial that is fixable to cause load to be less than it was. But you haven't convinced me that you're the person to be trusted to figure that out.

dkkkdkdk 14y ago

TLDR: I'm butt-hurt that people are dumping Ruby. And because I hate Java I'll blame it on it also.

sabat 14y ago
Not quite. He's saying that people who think Ruby is slow are often people who have no idea how to performance-tune it.
- bpicolo 14y ago
  Well, more of the time it's because Ruby actually is, in fact, slow.
  - pjmlp 14y ago
    I though the implementations were slow or fast, not the languages.
    - codygman 14y ago
      Typically a language is considered slow or fast based on it's most popular implementation, sadly.
    - ajanuary 14y ago
      True, though language design can have implications on how fast things can be implemented.
      - pjmlp 14y ago
        Agreed, but it is still an implementation issue, because one can eventually discover ways to optimize such cases without changing the language.
  - sabat 14y ago
    Ruby is not, in fact, slow. This myth has been debunked so many times that I'll just leave the googling to you as an exercise.

btilly 14y ago

Your inability to understand their clear description of a basic cascading failure mode under load speaks poorly of your actual knowledge and experience. Given that, I have to take everything else that you say with a large helping of salt.

ef4 14y ago
Their description of the root problem was very superficial: > At some threshold above 50%, our Rails servers would spike up to 100% CPU usage and become unresponsive. Yes, but why? What exactly were those processes doing? Why the sudden change at a particular threshold? Their lack of detailed investigation into this makes their post useless to me -- I have no way of knowing (1) what specific aspect of Ruby's architecture makes it unfit for their problem?, or (2) is their application doing something stupid that causes the problem in first place?
- btilly 14y ago
  If you read that sentence in context, your questions are answered. Here are the previous two sentences for context. The bigger problem was dealing with big traffic spikes. When a big spike in traffic came in, it created a domino effect that would take take down our entire cluster Given the article to that point, it is clear what is happening. They are maintaining a steady state of X% (where X is above 50), then a big traffic spike comes along. That traffic load is not distributed equally (my guess is because requests are not created equal) and there is a hot spot. The hot spot fails, then increases the load on everything else. After this repeats a few times, there is insufficient capacity. In other words at some steady state threshold above 50%, you wind up without sufficient capacity to handle traffic spikes. Nothing in this failure scenario is specific to Rails. It is a well-known failure mode for a cluster under load with a push based architecture (which http requests are). The fact that you did not understand that description speaks poorly of your problem solving skills. Now they may well have been doing something trivial that is fixable to cause load to be less than it was. But you haven't convinced me that you're the person to be trusted to figure that out.