Hacker News Reader

Comment by protomikron | Hacker News Reader

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.

View on HN

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.

What is Passenger exactly? Never heard of it before now. A quick Google brings up a marketing page that doesn't explain much more.

It’s a Ruby web server that can we bed used with nginx or Apache.

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...

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)

Where now = for 5 years or more.

Not sure if you mean this page or not: 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).

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.

I'm sure the original commenter is loving all your 20/20 hindsight.

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.

The posters point is that Ruby has surprising concurrency semantics compared to other solutions.

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.

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.

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.

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

> 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.

> 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.

Ah just like the 80's

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.

Reply on news.ycombinator.com