Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stripe open-sources Einhorn

stripe.com

Post reply on HN
Print view View original

21–30 of 35 posts

Re: Stripe open-sources Einhorn

#21

Post by waffle_ss »

gdb wrote: post #18
waffle_ss wrote: post #17

Am I to understand that Einhorn doesn't require the use of Unix sockets to delegate work to workers? If so, it could work quite nicely for JRuby apps as Java doesn't support Unix sockets and it's therefore not possible to just plop nginx in front of the Web server (Tomcat or Jetty) instances and have it queue up requests to a shared Unix socket like the typical Unicorn setup does.

That's correct. In fact, at the moment Einhorn only supports TCP sockets. (That being said, I might be mistaken, but I think that Unicorn can also bind TCP sockets.)

Thank you for the follow-up. Even though Unicorn does support TCP sockets, it is irrelevant for our JRuby apps as I believe (IIRC) it won't even install under JRuby due to being written in C only, with no native-Java or pure-Ruby alternatives available. So it's not a Web server that can be used for serving JRuby apps.

Now, since you've extracted the capabilities of Unicorn out into something that isn't coupled to a Web server (and it's written in pure Ruby, so is portable), we should be able to use it as a shim between nginx for managing Trinidad (Tomcat) instances. Very much looking forward to giving it a try - thanks for your efforts!

EDIT: Whoops, guess I spoke a bit too soon. I get this error:

  NotImplementedError: fork is not available on this platform
I think a typical workaround on JRuby is to use the posix-spawn or spoon gems. If I have some time this next weekend maybe I could test this a bit more and maybe formulate a patch. Example posix-spawn usage [here][1].

[1]: https://github.com/ddollar/foreman/blob/master/lib/foreman/p...

Re: Stripe open-sources Einhorn

#22

Post by gdb »

waffle_ss wrote: post #21
gdb wrote: post #18

Earlier quoted context omitted.

That's correct. In fact, at the moment Einhorn only supports TCP sockets. (That being said, I might be mistaken, but I think that Unicorn can also bind TCP sockets.)

Thank you for the follow-up. Even though Unicorn does support TCP sockets, it is irrelevant for our JRuby apps as I believe (IIRC) it won't even install under JRuby due to being written in C only, with no native-Java or pure-Ruby alternatives available. So it's not a Web server that can be used for serving JRuby apps. Now, since you've extracted the capabilities of Unicorn out into something that isn't coupled to a W…

Ah, interesting. Yeah, would love a patch!

Re: Stripe open-sources Einhorn

#23

Post by cperciva »

Depending on your platform, how many children you've forked, and your rate of incoming connections, this design could expose you to a thundering herd.

You might find that you get better performance by having the parent call accept() and hand off sockets to the children. With sufficient abuse of LD_PRELOAD you can probably do this without making any changes to the child processes -- you just need to override accept() with a function which checks if any sockets have been handed off.

Re: Stripe open-sources Einhorn

#25

Post by gdb »

cperciva wrote: post #23

Depending on your platform, how many children you've forked, and your rate of incoming connections, this design could expose you to a thundering herd. You might find that you get better performance by having the parent call accept() and hand off sockets to the children. With sufficient abuse of LD_PRELOAD you can probably do this without making any changes to the child processes -- you just need to override accept()…

That's a fair point. Even if your accept() implementation is fine, event-driven workers would instead be select()ing on the shared socket, which can also lead to a thundering herd. I think you'd need quite a few worker threads before this became an issue in practice though.

Re: Stripe open-sources Einhorn

#26

Post by jondot »

coderdude wrote: post #5

(The following is off-topic:) I noticed that the Stripe blog doesn't allow comments. I think most people find it odd or frustrating when they can't add their 2 cents to something (for better or for worse!). Any idea which things might have driven this decision? - Not wanting to deal with how most people act on the net? (Or maybe they're in a highly competitive space where the juggernauts wouldn't think twice about tr…

I also thought about it. Think about your blog - your posts can be: articles, essays, discussions. I chose essay, and removed comments. In a sense:

"This is what I have to say, I've wrote it and re-written it, and reformulated it and I think its good for publishing. I then published it and if you have comments, send me an Email and I'll consider amending my post".

Re: Stripe open-sources Einhorn

#27

Post by Danieru »

coderdude wrote: post #14
justinsb wrote: post #9

Earlier quoted context omitted.

I made the same decision on my personal blog. When there are comments both on a blog and here on HN, the conversation feels unnaturally fragmented to me. Further, when I did have both, comments that self-selected the blog (vs HN) are - in my opinion - much more likely to be spam/promotional, or generally less 'valuable' (e.g. more likely to be simple questions that are already answered in the post).

There's an angle I hadn't considered. The spammy and promotional type of comments would be far more likely to appear directly on the blog since that's where the value (for the commenter) is in leaving them. That's something that moderated comments would control, but you can't moderate your way out of fragmentation. I would expect more negative comments to be left directly on the blog as well since the commenter won't…

Moderation can also get tricky. Pure spam is simple but you will run into comments where the commenter somehow works in their (product || experience). So long as they provided some commentary it is not pure spam. So the situation becomes a bit touchy.

This is a problem we ran into at PhpPhotoUploadr. In our case we have a very talented team so we hacked together a solution.

PS: We're always hiring 忍者!

Re: Stripe open-sources Einhorn

#28

Post by crystalneth »

I just heard of Unicorn / Rainbow as a way to get more out of Heroku workers/dynos. I wonder if this is also compatible, or a better alternative?

I'm new to this whole concept, so am just about to get my feet wet.

Hopefully, Heroku will implement something like this internally, as it seems it would help them to eliminate the greatest flaw with their system - that each deployment require 5-10 seconds of downtime as new dynos are started.

Re: Stripe open-sources Einhorn

#30

Post by cperciva »

gdb wrote: post #25
cperciva wrote: post #23

Depending on your platform, how many children you've forked, and your rate of incoming connections, this design could expose you to a thundering herd. You might find that you get better performance by having the parent call accept() and hand off sockets to the children. With sufficient abuse of LD_PRELOAD you can probably do this without making any changes to the child processes -- you just need to override accept()…

That's a fair point. Even if your accept() implementation is fine, event-driven workers would instead be select()ing on the shared socket, which can also lead to a thundering herd. I think you'd need quite a few worker threads before this became an issue in practice though.

Indeed, it's an edge case... but it's a painful one if people do run into it.
Post reply on HN