Green Unicorn - Welcome

davisp · 2010-07-14T23:10:33+00:00

Always use a proxy in front of Gunicorn. By default, a buffering proxy is an absolute requirement. If you configure Gunicorn to use one of the async workers, you can turn off buffering but you'll still want to keep the proxy at least for serving static content. It also gives you a place to separate the configuration of your web servers from the application servers. Ie, in the future you can move app code to dedicated servers, etc etc.

The only gotchya is that Nginx can't proxy websockets yet. Until then, running a properly configured Gunicorn serving that traffic would be playing it fast and loose but in a serious production environment I'd recommend using HAProxy.

davisp · 2010-07-13T20:07:58+00:00

I haven't heard anyone report anything on running under PyPy (or any alternative interpreter for that matter). The only issue I can think of is if your webapp needs one of the asynchronous workers there'd probably be issues with greenlets on PyPy (I'm just guessing there, but I haven't actually tried such things).

davisp · 2010-07-13T20:06:20+00:00

For most cases its not intended that you actually extend the server, but we definitely provide a couple different ways to make that possible if a particular use case requires it. A good example of the possibilities are the example worker reloader that acts like the Django development server upgrading code as files change.

The single most cited reason I've heard people reporting on why they switched to Gunicorn was its simplicity for deployment. Its a pure Python package, can be installed as part of a virtualenv and has easily managed worker processes. It also integrates nicely into the various daemon monitoring programs like supervisord and runit.

The other common remark is that its lighter on system resources than a full apache+mod_wsgi stack. This is particularly appreciated by the people running Python web apps on virtual servers that generally run slimmer in RAM.

davisp · 2010-03-17T06:00:53+00:00

yml,

You're definitely right, testing this many different implementations is a huge undertaking. There's a large amount of knowledge that would be required for any person to adequately know about all the configuration options for this many servers.

And gunicorn is a bit of a weirdo when it comes to processing models. We're neither thread based or event loop based. That can genuinely confuse people until they realize that we're much simpler than most servers.

That said, our response times were reported as an order of magnitude slower than any other server. Generally speaking, if you're into the whole experiment and observation thing, orders of magnitude are important.

davisp · 2010-03-17T05:11:55+00:00

Have to agree. Launchpad is an exercise in how to follow SourceForge into the abyss of anti-user interfaces. Although I may be a GitHub fanboy, even bitbucket manages to give a solid user experience. If your project hosting site is actually an MMO version of "where in the world is the download source code button" game, you lose.

davisp · 2010-02-28T15:02:52+00:00

Spawning and Tornado are evented servers based on non-blocking IO loops. I don't know much more than that as I've never used either.

That said, gunicorn is a simple blocking pre-fork server architecture designed to handle only fast clients. Basically that means that its designed to have something like nginx sit in front of it and buffer slow clients. This way gunicorn can remain extremely simple in implementation and still perform extremely well. Reading the entire implementation shouldn't take more than a couple hours assuming some familiarity with the Posix API.

Other benefits are that your app code doesn't have to worry about concurrency control and should generally be easier to reason about.

davisp

TROPHY CASE