Hacker News new | comments | show | ask | jobs | submit login

How would this compare to using JRuby and threads?

If you use eventmachine, every single network call you make has to be evented. So you'd need to use things like https://github.com/leftbee/em-postgresql-adapter which aren't going to be as well tested as the standard pg driver.

Only for requests you'd like to have return async, as in the example given; I use event machine to make async posts mixed with regular blocking IO all the time.

yep, or even MRI with threads.

EventMachine requires fundamental changes to your code.

threads do not.

And even with MRI, you are, I am going to predict, see _significant_ performance improvement using an app server that can dispatch multi-threaded (say, puma) with config.threadsafe!.

I am confused why threads aren't getting more attention on this topic.

Seriously, I just recently switched to puma and enabled config.threadsafe! and that was that. Now I/O calls like HTTP requests don't block the server, but are still synchronous. I didn't even need to switch to jruby.

> I am confused why threads aren't getting more attention on this topic.

I think it's because of the "threads are hard" meme. I think the Ruby community is growing beyond that, but it's not a fast process.

Ironically, doing evented/fiber code right is probably harder than doing threads right, for this kind of stuff.

I'm a bit astounded that heroku, in their attempt to deal with, um, let's call it "routing-gate", aren't talking about talking about multi-threaded dispatch and config.threadsafe!, but only unicorn with 2-4 forked processes. When it seems awfully likely that multi-threaded dispatch is going to scale a lot more efficiently with regard to number of overlapping requests.

I think some of it is the lack of mature, robust, 'self-managing' app server solutions. For MRI (with the GIL), what's likely needed is something that can fork multiple processes (to use all cores), with each of those processes dispatching multi-threaded (to deal with I/O blocking as well as even-ing out latency when not all requests finish in identical time). So far as I know, Passenger 4 Enterprise is the only thing that can do this for you, without you having to manually set it all up.

As a best practice, you're right. IO should be either 100% evented or 100% blocking.

But in this case, as long as you expect your database requests to be fast and reliable, it's fine to mix in the standard blocking pg driver.

Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact