>>
>> > everyone is over double - then do it the right way and cut WSGI out
>> > completely.
>> >
>>
>> sorry, i do not know wich kind of benchmark you have made, but for an
>> hello world mongrel2+uWSGI outperform mongrel2+brubeck in every test.
>>
>
> 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.
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.
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 ;)
Sorry for the noise, and keep up the good work
--
Roberto De Ioris
http://unbit.it
