Live data from Hacker News

Bjoern: A screamingly fast Python WSGI server written in C.

github.com

21–30 of 31 posts

Re: Bjoern: A screamingly fast Python WSGI server written in C.

#21
post #7
post #5

Interesting. I think I am gonna benchmark this against gunicorn with a simple flask app.

Ok took 30 minutes to run some benchmarks on a AWS instance. I used a small instance run a simple Flask Hello World app with gunicorn (1 worker and 4 workers) and bjoern. Frankly I was not able to fund any speed difference between both the servers. Here is the gist of the benchmark results https://gist.github.com/753998

http://imilky.cn/blog/2010/12/2nd-python-wsgi-server-test/

Author of gevent commented on this guy's earlier benchmark test

http://imilky.cn/blog/2010/04/python-wsgi-web-server/

Re: Bjoern: A screamingly fast Python WSGI server written in C.

#22
post #12
post #7

Earlier quoted context omitted.

Ok took 30 minutes to run some benchmarks on a AWS instance. I used a small instance run a simple Flask Hello World app with gunicorn (1 worker and 4 workers) and bjoern. Frankly I was not able to fund any speed difference between both the servers. Here is the gist of the benchmark results https://gist.github.com/753998

Is anyone else confused by "1 worker and 4 workers"?

Well I run gunicorn in production with 4 workers so just wanted to give it a try. Also I chose to add network latency by doing it on amazon instance.

Re: Bjoern: A screamingly fast Python WSGI server written in C.

#23

Earlier quoted context omitted.

Why on earth should developers ever say "Ok, it's fast enough. We're done." I mean, maybe temporarily done so that you can patch up some higher priority (more broken?) stuff, but DONE? Pushing the envelope is how you progress, and in this case also how you can learn.

Because at some point you will pass the point of diminishing returns. Suppose 3% of the time is spent in the server, and 97% in the web app. Do you really want to spend 200 hours trying to reduce that 3% to 2.5% instead of spending 10 hours on making your app twice as fast? You've made the server 20% faster, but what have you really gained in practice when you look at the overall picture? Even assuming unlimited deve…

Amdahl's law http://en.wikipedia.org/wiki/Amdahl%27s_law

Re: Bjoern: A screamingly fast Python WSGI server written in C.

#24

I think all emphasis on server software speed is overrated. In pretty much everything but hello world, the vast majority of the time is spent inside the web app, not in the server. Yes, lowering the web server overhead is a good thing. But I think in most cases it's already so low that further reducing this overhead results in no noticeable impact in real-life scenarios. At some point you'll just be benchmarking how…

Why on earth should developers ever say "Ok, it's fast enough. We're done." I mean, maybe temporarily done so that you can patch up some higher priority (more broken?) stuff, but DONE? Pushing the envelope is how you progress, and in this case also how you can learn.

Because increasing benchmark speed provides no business value (assuming your business isn't self-promotion, getting into flamewars, etc).

There's a extremely well known saying that speaks to this issue, goes something like "Preoptimiztion is root of all evil."

Re: Bjoern: A screamingly fast Python WSGI server written in C.

#25

Earlier quoted context omitted.

Why on earth should developers ever say "Ok, it's fast enough. We're done." I mean, maybe temporarily done so that you can patch up some higher priority (more broken?) stuff, but DONE? Pushing the envelope is how you progress, and in this case also how you can learn.

Because at some point you will pass the point of diminishing returns. Suppose 3% of the time is spent in the server, and 97% in the web app. Do you really want to spend 200 hours trying to reduce that 3% to 2.5% instead of spending 10 hours on making your app twice as fast? You've made the server 20% faster, but what have you really gained in practice when you look at the overall picture? Even assuming unlimited deve…

Totally agree with you. You dont really get 1000's of reqs/sec in a real world environment. All you need is a good server which is fast and memory efficient. Rest of the efforts should be focussed on the webapp side, more importantly DB. If you can work on your IO you will have a fast and efficient application.

Re: Bjoern: A screamingly fast Python WSGI server written in C.

#26
post #7
post #5

Interesting. I think I am gonna benchmark this against gunicorn with a simple flask app.

Ok took 30 minutes to run some benchmarks on a AWS instance. I used a small instance run a simple Flask Hello World app with gunicorn (1 worker and 4 workers) and bjoern. Frankly I was not able to fund any speed difference between both the servers. Here is the gist of the benchmark results https://gist.github.com/753998

> n. Frankly I was not able to fund any speed difference between both the servers.

That is because of this http://news.ycombinator.com/item?id=2037060

Re: Bjoern: A screamingly fast Python WSGI server written in C.

#27
post #9

Is the name a reference to the main character of Peggle? (Also, how does this compare speed-wise to Mongrel2? It easily handles the 4000 requests/second that my PSGI handler can do. I am sure it could do more if the backend was faster.)

Björn is hardly an uncommon name, as I understand it.

Re: Bjoern: A screamingly fast Python WSGI server written in C.

#28
I've been doing some research on small web servers, trying to understand didiwiki's code (a web server and wiki engine in ~2k lines of C):

http://c2.com/cgi/wiki?DidiWiki

This is a nice introduction to writing a minimal web server:

http://www.ibm.com/developerworks/systems/library/es-nweb/in...

Re: Bjoern: A screamingly fast Python WSGI server written in C.

#29

Earlier quoted context omitted.

Why on earth should developers ever say "Ok, it's fast enough. We're done." I mean, maybe temporarily done so that you can patch up some higher priority (more broken?) stuff, but DONE? Pushing the envelope is how you progress, and in this case also how you can learn.

Because at some point you will pass the point of diminishing returns. Suppose 3% of the time is spent in the server, and 97% in the web app. Do you really want to spend 200 hours trying to reduce that 3% to 2.5% instead of spending 10 hours on making your app twice as fast? You've made the server 20% faster, but what have you really gained in practice when you look at the overall picture? Even assuming unlimited deve…

> 200 hours trying to reduce that 3% to 2.5%

It's about progression over time. If someone didn't do it, we'd be leaving significant performance gains behind. That means more servers, more electricity and more money for everyone.

I'm not going to do that for my app but it's nice that there are people making these improvements for the benefit of everyone that uses their server.

When you take into account many small improvements, across all deployments, over time, they can and do add up to significant improvements.

Re: Bjoern: A screamingly fast Python WSGI server written in C.

#30
post #28

I've been doing some research on small web servers, trying to understand didiwiki's code (a web server and wiki engine in ~2k lines of C): http://c2.com/cgi/wiki?DidiWiki This is a nice introduction to writing a minimal web server: http://www.ibm.com/developerworks/systems/library/es-nweb/in...

Thanks for pointing that out -- I'll want to look didiwiki over since I also wrote a webserver/wiki in http://wry.me/~darius/hacks/ikiwiki.tar.gz

There's usually something to learn from anyone else tackling the same problem.

Post reply on HN