My response is inline.
> > I'd like to see this backed with data.
>
> Ok, but please be constructive (and read the whole mail), we are on the
> same side (holy war against WSGI ;)
>
> # brubeck app (running behind mongrel2):
> from brubeck.request_handling import Brubeck, WebMessageHandler
> from brubeck.connections import Mongrel2Connection
> import sys
>
> class DemoHandler(WebMessageHandler):
> def get(self):
> self.set_body('Hello World')
> return self.render()
>
> config = {
> 'msg_conn': Mongrel2Connection('tcp://192.168.173.19:9999',
> 'tcp://192.168.173.19:9998'),
> 'handler_tuples': [('/', DemoHandler)],
> }
> app = Brubeck(**config)
> app.run()
>
> # WSGI app (running over uWSGI behind mongrel2)
> def application(environ, start_response):
> start_response('200 OK', [('Content-Type', 'text/html')])
> return "Hello World"
>
>
> uWSGI is run with:
>
> uwsgi -w utest --zmq tcp://192.168.173.19:9999,tcp://192.168.173.19:9998
>
>
> The (stupid) benchmark i run:
>
> httperf --server=192.168.173.19 --port=6767 --uri=/ --num-conns=100
> --num-calls=10
>
>
> Results for brubeck (i have taken the best values):
> Connection rate: 55.8 conn/s (17.9 ms/conn, <=1 concurrent connections)
> Connection time [ms]: min 13.8 avg 17.9 max 42.2 median 17.5 stddev 3.8
> Connection time [ms]: connect 0.3
> Connection length [replies/conn]: 10.000
>
> Request rate: 558.4 req/s (1.8 ms/req)
>
>
> Results for uWSGI (i have taken the WORST values):
> onnection rate: 466.6 conn/s (2.1 ms/conn, <=1 concurrent connections)
> Connection time [ms]: min 1.7 avg 2.1 max 6.2 median 1.5 stddev 0.7
> Connection time [ms]: connect 0.3
> Connection length [replies/conn]: 1.000
>
> Request rate: 933.2 req/s (1.1 ms/req)
>
>
> What it shows ?
>
> WSGI is not relevant for performance, this is not the reason you have to
> fight for.
>
Ah neat. Now we're getting into some awesome details.
Are you using gevent for Brubeck? It supports Eventlet too, but Eventlet's
performance is significantly worse.
Would you mind trying the test again using the classless request handlers
with Brubeck? I have observed that using the classes, as you see here:
https://github.com/j2labs/brubeck/blob/master/demos/demo_minimal.py -
actually results in significantly worse performance that if you use a
simple function, like you see here:
https://github.com/j2labs/brubeck/blob/master/demos/demo_noclasses.py
> This is not even a problem of "ugliness" (sorry i am a C and perl
> developer, elegance is not relevant for me :P).
>
> The problem is in WSGI being a LIMIT for python web development.
>
> Read WEB-SIG (the group where python web standard are defined) threads,
> whenever someone try to propose something
> all go wrong.
>
> PSGI (the perl equivalent for WSGI, supported by uWSGI) has only a couple
> of years and it is already able to do EVERYTHING
> modern applications need. Putting it in uWSGI architecture has been a
> breeze, and a lot of new servers are coming out.
>
>
> > WSGI is not async without special work and that work puts you back in
> > Python, so your claim about pure-c makes no sense. On top of that,
> uWSGI's
> > async layer is a confusing mess. You have implicit AND explicit context
> > switching in the same project!
>
> I am agree but it has nothing to do with uWSGI, it is the WSGI way. Just
> try PSGI async in uWSGI. Its incredible how
> a "ugly" language like perl appears beatiful in such a context :)
>
>
> >
> > Alas, I didn't mean to offend. Only inform. There is a LOT of
> > misunderstanding around async in Python.
> >
>
> have you read the Async page on the uWSGI wiki ? A lot users blamed me for
> the warning on top, but
> it is still what i think. Again, we are on the same side, the only
> difference is in me "having to" support a standard,
> and you "having the freedom" to kill it. If you ask me to make a uWSGI
> adapter for brubeck (as i have already done for Pump) i would start
> working on it just now.
>
Hmm... Sure, why not. The performance seems to justify spending time on it,
which I was unaware of before. Thanks for correcting me.
And to answer to the other mail, yes uWSGI is the worst name ever
> (expecially for perl and ruby developers) but changing it, would require
> too much effort... (from a marketing point of view ;)
>
I think it'd be worthwhile, but I'm not going to spend anytime fighting for
it. :)
Sorry for the noise, and keep up the good work
>
It's not noise. Few things rile me up like when programmers think
conducting science and disputing claims is noise. We NEED to treat it like
a search for truth. If I make a mistake in my assertions, I will admit it
and move forward.
