6 ms·

There is something seriously wrong with your number (struggling to serve 20 people). I do not have experience with Ruby, but I think it's similar to Python (in

There is something seriously wrong with your number (struggling to serve 20 people). I do not have experience with Ruby, but I think it's similar to Python (in performance) and even if it's let's say 5 times slower (which I don't think it is), a webservice on a simple machine (workstation) in Ruby can easily serve north to 1k (or more) requests per seconds (behind nginx or apache or whatever), and in no way would 20 users be a problem. It doesn't matter if that's async or not (note, not being async does not rule out concurrency or parallelism), but there was something seriously wrong with your application (if you have to serve long-running tasks, you have to make a msg queue anyway and shouldn't do that in your HTTP response directly). You may gain from async if you are IO bound, but with 20 users you are not IO bound, believe me.

strken 6y ago
We were "IO-bound" using a setup that executed a maximum of two requests at a time, completely blocked processing new requests until earlier ones fully completed, and took a long time to execute requests because of unexpected latency in a dependency, while 20 frustrated users sat in a room hammering the refresh button and dumping more tasks onto the queue. You're absolutely right when you say there was something seriously wrong with the setup! The problem is that it was more or less what you'd get if you set up a default Rails app behind Passenger, and Passenger did this because some of the major Ruby gems weren't threadsafe (e.g. Rails, until 2008), which comes back to concurrency problems with the ecosystem.
- darwinwhy 6y ago
  What is Passenger exactly? Never heard of it before now. A quick Google brings up a marketing page that doesn't explain much more.
  - johnmcauley 6y ago
    It’s a Ruby web server that can we bed used with nginx or Apache.
  - universa1 6y ago
    Something like mod_perl / mod_xxx in the early days... and they did some work on the concurrency problems with rails and ruby around the ruby 1.8 days iirc... In the meantime they expanded to more languages...
  - ForHackernews 6y ago
    It's an application server. If you're familiar with the Python webdev ecosystem, Passenger is roughly a Ruby equivalent for something like uWSGI or Gunicorn. (IIRC, you can actually run Python apps with Passenger now, too)
    - coldtea 6y ago
      Where now = for 5 years or more.
  - e12e 6y ago
    Not sure if you mean this page or not: https://www.phusionpassenger.com/ https://www.phusionpassenger.com/ But as they say, it's an application server. Similar to mod_perl for apache/php, unicorn or indeed nodejs (which can function as an application server for Javascript).
- jacobsenscott 6y ago
  If you were IO bound you could have run many more rails processes. There's no reason to limit your self to one process per core. You can run many times that number of processes since they are all just waiting on IO.
  - EdwardDiego 6y ago
    I'm sure the original commenter is loving all your 20/20 hindsight.
    - coldtea 6y ago
      The original commenter offered his story as an issue with Ruby preventing X. The 20/20 hindsight is not meant to retroactively solve their problem, it's mean as a counter-argument, that the problem was their design, not Ruby.
      - Person5478 6y ago
        The posters point is that Ruby has surprising concurrency semantics compared to other solutions.
        Evan__ 6y ago
        It has the same concurrency semantics w/r/t IO as any other language that isn't using an event based runtime. If you wrote your app in C and used a single thread you'd have the exact same issue.
- kevincox 6y ago
  Ruby should be able to execute more than one request on a time because while it can only have one thread executing Ruby at a time it can run other threads while waiting for IO. It seems like for some reason Rails was limited to one thread which is not how it should be configured.
xorcist 6y ago
We know nothing about the details, of course, but there's something fishy about the performance story. If I were to take a guess it sounds more like a problem with misconfigured software than having used fundamentally wrong tools for the job. It sounds like the concurrency was set much too low. That's not limited to the configured max workers but there will be similar settings for the web server, database connection layer and the database itself. A similar thing would have happened with C++ or Java if there was a connection pool of two and database queries that took 500 ms to complete. I've seen worse mistakes in producion code. The lesson to learn from this is probably not that goroutines makes everything faster, but that you have to understand the tools you use. Also, test demos. And always keep a backup plan. That's what Steve Jobs did, relentlessly, for all his demos.
deleted 6y ago
[deleted]
throwaway189262 6y ago
He said there was high db latency. This matters a ton when your language is single threaded and not using async io. 20 queries would tie up the whole server for a second at 50ms db latency. You can get around it by using async instead of blocking, using fibers which don't block, or using a thread pool so other threads can keep serving. I'm not experienced with Ruby but it sounds like Ruby doesn't do any of those
- dragonwriter 6y ago
  > I'm not experienced with Ruby but it sounds like Ruby doesn't do any of those Modern ruby can do any of those, though in 1.8 or earlier it could do fewer, and less well.
- sciurus 6y ago
  > You can get around it by using async instead of blocking, using fibers which don't block, or using a thread pool so other threads can keep serving. The typical approach for Ruby, Python, and similar languages is just to run more processes.
  - throwaway189262 6y ago
    Ah just like the 80's
- inopinatus 6y ago
  Ruby does all of those things. The story sounds ancient, and even then a consequence of naive production design far more than any emergent property of language.

strken 6y ago

We were "IO-bound" using a setup that executed a maximum of two requests at a time, completely blocked processing new requests until earlier ones fully completed, and took a long time to execute requests because of unexpected latency in a dependency, while 20 frustrated users sat in a room hammering the refresh button and dumping more tasks onto the queue. You're absolutely right when you say there was something seriously wrong with the setup! The problem is that it was more or less what you'd get if you set up a default Rails app behind Passenger, and Passenger did this because some of the major Ruby gems weren't threadsafe (e.g. Rails, until 2008), which comes back to concurrency problems with the ecosystem.

darwinwhy 6y ago
What is Passenger exactly? Never heard of it before now. A quick Google brings up a marketing page that doesn't explain much more.
- johnmcauley 6y ago
  It’s a Ruby web server that can we bed used with nginx or Apache.
- universa1 6y ago
  Something like mod_perl / mod_xxx in the early days... and they did some work on the concurrency problems with rails and ruby around the ruby 1.8 days iirc... In the meantime they expanded to more languages...
- ForHackernews 6y ago
  It's an application server. If you're familiar with the Python webdev ecosystem, Passenger is roughly a Ruby equivalent for something like uWSGI or Gunicorn. (IIRC, you can actually run Python apps with Passenger now, too)
  - coldtea 6y ago
    Where now = for 5 years or more.
- e12e 6y ago
  Not sure if you mean this page or not: https://www.phusionpassenger.com/ https://www.phusionpassenger.com/ But as they say, it's an application server. Similar to mod_perl for apache/php, unicorn or indeed nodejs (which can function as an application server for Javascript).
jacobsenscott 6y ago
If you were IO bound you could have run many more rails processes. There's no reason to limit your self to one process per core. You can run many times that number of processes since they are all just waiting on IO.
- EdwardDiego 6y ago
  I'm sure the original commenter is loving all your 20/20 hindsight.
  - coldtea 6y ago
    The original commenter offered his story as an issue with Ruby preventing X. The 20/20 hindsight is not meant to retroactively solve their problem, it's mean as a counter-argument, that the problem was their design, not Ruby.
    - Person5478 6y ago
      The posters point is that Ruby has surprising concurrency semantics compared to other solutions.
      - Evan__ 6y ago
        It has the same concurrency semantics w/r/t IO as any other language that isn't using an event based runtime. If you wrote your app in C and used a single thread you'd have the exact same issue.
kevincox 6y ago
Ruby should be able to execute more than one request on a time because while it can only have one thread executing Ruby at a time it can run other threads while waiting for IO. It seems like for some reason Rails was limited to one thread which is not how it should be configured.

xorcist 6y ago

We know nothing about the details, of course, but there's something fishy about the performance story. If I were to take a guess it sounds more like a problem with misconfigured software than having used fundamentally wrong tools for the job. It sounds like the concurrency was set much too low. That's not limited to the configured max workers but there will be similar settings for the web server, database connection layer and the database itself. A similar thing would have happened with C++ or Java if there was a connection pool of two and database queries that took 500 ms to complete. I've seen worse mistakes in producion code. The lesson to learn from this is probably not that goroutines makes everything faster, but that you have to understand the tools you use. Also, test demos. And always keep a backup plan. That's what Steve Jobs did, relentlessly, for all his demos.

deleted 6y ago

[deleted]

throwaway189262 6y ago

He said there was high db latency. This matters a ton when your language is single threaded and not using async io. 20 queries would tie up the whole server for a second at 50ms db latency. You can get around it by using async instead of blocking, using fibers which don't block, or using a thread pool so other threads can keep serving. I'm not experienced with Ruby but it sounds like Ruby doesn't do any of those

dragonwriter 6y ago
> I'm not experienced with Ruby but it sounds like Ruby doesn't do any of those Modern ruby can do any of those, though in 1.8 or earlier it could do fewer, and less well.
sciurus 6y ago
> You can get around it by using async instead of blocking, using fibers which don't block, or using a thread pool so other threads can keep serving. The typical approach for Ruby, Python, and similar languages is just to run more processes.
- throwaway189262 6y ago
  Ah just like the 80's
inopinatus 6y ago
Ruby does all of those things. The story sounds ancient, and even then a consequence of naive production design far more than any emergent property of language.