Brubeck

[Chase Lee]

I'm sure some of you saw http://brubeck.io recently mentioned on Hacker News.  Anyone have any opinions or thoughts to share?  It seems to be an attempt to make something like Tornado and to make it easier as "callback spaghetti" is mentioned (personally, I don't find callbacks that hard to manage).  I wouldn't think it's more performant than Tornado, but has anyone heard or seen otherwise?  Looking forward to hearing what you guys have to say.

- Chase

[simp x]

I was just thinking how to avoid the callback.
I don't think callbacks is that hard to manage, but sometimes it is confused.
After scan the example code of brubeck, I just have no idea about how
it does asynchronous work without callback?
Can anyone explain it to me.Thanks!

2011/7/18 Chase Lee <umcha...@gmail.com>:

[Didip Kerabat]

The paradigm of Eventlet is similar to traditional fork() based app server: multi-threaded. What's (seemingly) interesting about Eventlet is the green thread thing, which is much lighter weight than OS process.

Overall, Brubeck is far more interesting framework I've seen recently. Looking inside its source code, it looks eerily similar to Tornado (down to its naming convention).
I wouldn't mind to give it a try. Not knowing much about Mongrel2;
  * What its architecture,
  * How to monitor its processes,
  * What's its relationship with 0mq, etc, etc.

I'm a little hesitant about using it in production.

Just my 2 cents.

- Didip -

On Mon, Jul 18, 2011 at 5:46 PM, Chase Lee <umcha...@gmail.com> wrote:

I'm sure some of you saw http://brubeck.io recently mentioned on Hacker News.  Anyone have any opinions or thoughts to share?  It seems to be an attempt to make something like Tornado and to make it easier as "callback spaghetti" is mentioned (personally, I don't find callbacks that hard to manage).  I wouldn't think it's more performant than Tornado, but has anyone heard or seen otherwise?  Looking forward to hearing what you guys have to say.

- Chase

--
- Didip -
loves Python, Ruby, Javascript, and Ubuntu.

[Andrew Fort]

On Tue, Jul 19, 2011 at 10:26 AM, Didip Kerabat <did...@gmail.com> wrote:
> The paradigm of Eventlet is similar to traditional fork() based app server:
> multi-threaded. What's (seemingly) interesting about Eventlet is the green
> thread thing, which is much lighter weight than OS process.

Yeah, the approach has a lot of advantages, particularly in testing,
because your code is identical to single threaded code, and actually
can generally be run without eventlet in a single thread. It has some
disadvantages (monkeypatching isn't perfect, it's "magic", etc), and
these usually don't matter, until you're in production :-).

For some strange reason I always felt more comfortable using
eventlet/etc for clients, rather than servers (which is partly what
led me to use Tornado in the first place). Plus, its Python style is
very familiar to me for some reason :-).

[James Dennis]

Hello,

I am the author of Brubeck and am happy to see it discussed on the Tornado mailing list.

I initially started work on Brubeck, at least partially, to address what I perceive to be bad handling of blocking code in Tornado.  I faced this for 9 months at my previous job and, though it's commendable of bit.ly to have done this, I didn't want to write an async driver for every database I intended to use.  Tornado provides no facilities (last I checked) for managing blocking resources where eventlet will convert existing blocking drivers into nonblocking ones automatically.

With regard to callback spaghetti, I believe Eventlet (or Gevent) offers a solution that's easier to reason about, especially when the code base gets large.  As was previously said, the code looks synchronous because it uses implicit context switches instead of the explicit ones you see in Twisted, Tornado or even Node.js.  This is why I felt it was worthwhile to build a new framework around it.

With regard to speed, Brubeck holds up great against Tornado. Please see this completely unscientific comparison for a general feel of what to expect: https://gist.github.com/882555

And finally, I believe a zeromq socket between Brubeck and Mongrel2 to be far more efficient than Nginx upstreaming to multiple tornado processes which requires HTTP overhead for every connection. Brubeck just keeps a single zmq socket open to Mongrel2 and Mongrel can detect when a Brubeck instance goes down immediately. Contrast this with waiting for an HTTP upstream to time out.

I am happy to try and answer any other questions / concerns but I'd encourage anyone interested to also join our mailing list: http://groups.google.com/group/brubeck-dev

James Dennis (aka @j2labs)

[James Dennis]

I would like to address any concerns you have about running Brubeck in production.  I'm not sure this list is the appropriate place to do it.

Please feel free to email me at jde...@gmail.com or join our mailing list brube...@googlegroups.com.

I will only add that Eventlet has been used in production for many years supporting SecondLife. And though ZeroMQ is somewhat new, it was also created by one of the designers of AMQP. And we probably all know who Zed Shaw is. Combine those three, and throw in a personal project DictShield, and I believe you have a very solid foundation from which to work.

[wataka]

I dunno, to many moving parts to mange in the end, ZeroMQ, Mongrel
e.t.c

On Jul 19, 9:33 pm, James Dennis <jden...@gmail.com> wrote:
> I would like to address any concerns you have about running Brubeck in
> production.  I'm not sure this list is the appropriate place to do it.
>

> Please feel free to email me at jden...@gmail.com or join our mailing list

[Chase Lee]

Hi James,

Thanks for responding in here. I also appreciate the unscientific
comparison. Simple but exactly what I wanted to see.

What other benefits does Brubeck provide over Tornado outside of
Eventlet creating aysnc drivers? My current project already uses
aysncmongo, and I've been happy with it so that's not so much of an
issue for me (I'm a huge Mongo fan).

Thanks,
Chase

On Jul 19, 3:33 pm, James Dennis <jden...@gmail.com> wrote:
> I would like to address any concerns you have about running Brubeck in
> production.  I'm not sure this list is the appropriate place to do it.
>

> Please feel free to email me at jden...@gmail.com or join our mailing list

[Ben Darnell]

Hi James,

On Tue, Jul 19, 2011 at 12:24 PM, James Dennis <jde...@gmail.com> wrote:

Hello,

I am the author of Brubeck and am happy to see it discussed on the Tornado mailing list.

Welcome to the list, and congratulations on the release!

 

I initially started work on Brubeck, at least partially, to address what I perceive to be bad handling of blocking code in Tornado.  I faced this for 9 months at my previous job and, though it's commendable of bit.ly to have done this, I didn't want to write an async driver for every database I intended to use.  Tornado provides no facilities (last I checked) for managing blocking resources where eventlet will convert existing blocking drivers into nonblocking ones automatically.

I actually agree with this.  The vision for Tornado was never that you'd need to have async versions of everything, but rather that blocking is OK in small and predictable amounts (IIRC the only @asynchronous handlers in Friendfeed were the long-poll updates handler and the ones that dealt directly with external Facebook/Twitter/etc APIs; everything else made blocking calls to memcache and mysql).  Of course, that's not always an easy goal to reach, and Tornado is not currently very good at either tolerating long blocking calls or helping you turn blocking calls into non-blocking.  

This is a problem I'd like to do something about in a future Tornado release.  My preferred solution is to use real threads for the "active" phase of a request, and then use explicit callbacks for long-poll/push scenarios (similar to GSE's detachThread() http://code.google.com/p/opengse/source/browse/trunk/transports/nio/java/com/google/opengse/core/HttpConnection.java#290 or Jetty's suspend() http://wiki.eclipse.org/Jetty/Feature/Continuations).  However, given the GIL, I can definitely see the appeal of using eventlet/gevent for a unifying solution.

-Ben

[James Dennis]

There were a few responses so I have collected them and responded
below.

>> I dunno, to many moving parts to mange in the end, ZeroMQ, Mongrel e.t.c

This is a fair criticism. I typically find the ZeroMQ install a one
time thing and then I don't have to think much more about it. Other
than that, it's not much different from Nginx + Tornado or Gunicorn +
Django.

>> What other benefits does Brubeck provide over Tornado outside of Eventlet creating aysnc drivers? My current project already uses aysncmongo, and I've been happy with it so that's not so much of an issue for me (I'm a huge Mongo fan).

We can see the most glaring difference in the handling of
concurrency. There are reasons to like explicit switching and there
are reasons to like implicit switching. As long as you're using
Python, I'm happy.

Brubeck, by nature of using ZeroMQ, offers nonblocking message passing
to just about any language. ZeroMQ could be described as language
agnostic sockets with erlang style mailboxes. If you're used to AMQP,
you might like this link: http://www.zeromq.org/docs:welcome-from-amqp
. If you're already glued to RabbitMQ you could use the 0MQ plugin to
hook Brubeck up: https://github.com/rabbitmq/rmq-0mq/wiki .

This repo has been helpful to me when describing how ZeroMQ works:
https://github.com/j2labs/zmq_examples/

I'm not sure what work has already been done with Tornado and ZeroMQ,
but I tried merging the two in a project I worked on before Brubeck
called Dillinger (after Dillinger Escape Plan). Some might find the
code useful: https://github.com/j2labs/dillinger/blob/master/helloworldo.py
Facebook appears to have done the integration of ZeroMQ with the
IOLoop.

An additional contribution is DictShield. DictShield is a database
agnostic modeling tool and sorta completes Brubeck's agnostic approach
to moving pieces. The modeling system can be used as class methods,
or instances of classes, that shape python dictionaries. You define a
class, similar to what you'd do with Django, and you can then
serialize to a Python dictionary or JSON. I find this tool convenient
for the types of elastic modeling one might do with MongoDB or key-
value stores. Recently people have started storing models serialized
to JSON in SQLite too.

My thoughts here are simply that queries are too important for a
framework to build them for you. https://github.com/j2labs/dictshield

DictShield started life as MongoEngine and was open sourced during my
time at ex.fm (which you should try!). I have continued it's
development and it's still open source. It works great with Tornado
too.

>> Welcome to the list, and congratulations on the release!

Thanks, Ben!

>> This is a problem I'd like to do something about in a future Tornado release. My preferred solution is to use real threads for the "active" phase of a request, and then use explicit callbacks for long-poll/push scenarios.

This sounds cool. I imagine the interface could be somewhat simple
too, since the scope is nice and narrow.

Looking forward to seeing that!

James

[Chase Lee]

Checked out DictShield, and it looks quite nice. I really like how
lightweight it feels as opposed to working with something like
Django's ORM, which makes it a perfect fit for Brubeck and Tornado,
both of which I would consider lightweight frameworks (one of the
things I like most about Tornado actually). Great work James and
thanks for sharing.

[wataka]

I think its a little more than that James

> This is a fair criticism.  I typically find the ZeroMQ install a one
> time thing and then I don't have to think much more about it.  Other
> than that, it's not much different from Nginx + Tornado or Gunicorn +
> Django.

I took another look, it really is, for me at least twice as much work.
Just getting Mongrel2 compiled installed and configured would be
bothersome and to make matters worse, no load balancing. Compare this
to an firing up as many tornado instances you need, configure them as
backend sources, throw them behind Cherokee. Cherokee balances the
load and tries to bring them up when they go down. Mongrel2 has such a
tool, but its separate and you would have to compile that
separately...I stopped reading at that point.

Brubaker running with a pure Python queue would be nice, http://www.snakemq.net/

[wataka]

uh "Brubeck" not Brubaker :)

[Daniel Truemper]

Hi there,

I am new to this list but am using Tornado for roughly 6 months now. I
also started using ZeroMQ around that time. If it is of any interest to
some: I have written a Mongrel2 Handler for Tornado [1]. This
(hopefully) allows you to run Tornado Apps directly behind Mongrel2 by
simply using the "Mongrel2Handler" instead of the "HttpServer". So far I
have only tested it in toy projects, but I am planning to test one of my
real life projects on it.

> Just getting Mongrel2 compiled installed and configured would be
> bothersome and to make matters worse, no load balancing.

Compiling and installing Mongrel2 is about as easy as compiling nginx.
The load balancing is automatically handled by ZeroMQ, so you do not
have to worry about that. Just connect many Tornado Processes to your
Mongrel2 instance(s), and ZeroMQ will do the rest!

Best
Daniel

[1]: http://truemped.github.com/tornadotools/mongrel2.html
Code:
https://github.com/truemped/tornadotools/tree/master/tornadotools
/mongrel2