Comments on Mind Reference: Python Web Routing Benchmark

Just added.

2013-11-17T14:14:04.388+02:00

Just added.

Where is Pylons ? :)

2013-11-16T21:11:11.205+02:00

Where is Pylons ? :)

Test coverage tells me something, but not the spli...

2012-11-22T14:56:17.937+02:00

Test coverage tells me something, but not the split between code/tests/demos/etc.

You are mistaken, I do not present a bigger code base as something negative. The problem is with number of PEP8 or CC errors that needs attention. The numbers, being normalized, gives you an idea regardless the code base size.

Thank you.

2012-11-21T11:49:42.215+02:00

Thank you.

Chris, thank you for the comment. That might be an...

2012-11-21T09:30:09.744+02:00

Chris, thank you for the comment. That might be an idea for another post, but my idea was to get thing simple without spending much time in-depth analysis what is test, what is contributed, what is a sample, etc. The trend most likely remains.

I think it would be really interesting if you coul...

2012-11-20T14:57:04.489+02:00

I think it would be really interesting if you could describe why wheezy is faster. For example, I remember a talk (maybe it was linked from your template post?) showing benchmarks about the speed of different speed operations in python.

In a similar way, it would be nice if you can take two or three frameworks and state why wheezy is faster. Is due to the implementation? Is because the

wheezy.web seo routing benchmark has been improved...

2012-11-20T14:07:42.561+02:00

wheezy.web seo routing benchmark has been improved by approximately 40%.

The test works with module `app` located in a dire...

2012-10-17T18:52:50.200+03:00

The test works with module `app` located in a directory per framework. The load code is outside of timeit call.

The google group post basically says it all: Now ...

2012-10-17T18:41:00.034+03:00

The google group post basically says it all:

Now that I've looked in detail at the test, it is because the test is
nonsensical. Each time it tests the URLs, it constructs a fresh WSGI
application. Each fresh application has to compile each URL in the
urlconf before using it. It then destroys the application, and starts
another one up.

Could you be a bit more concrete with respect to c...

2012-10-11T20:31:47.782+03:00

Could you be a bit more concrete with respect to comments you would like to hear, please? Just ask your question or voice concern if any.

https://groups.google.com/d/msg/django-developers/...

2012-10-11T18:50:44.450+03:00

https://groups.google.com/d/msg/django-developers/4h0eP_mBE8A/40ZnOiJwjQQJ

Comments?

You are wrong in missing a fact that OS spent cycl...

2012-10-11T14:37:56.779+03:00

You are wrong in missing a fact that OS spent cycles on IO wait.

Isolated benchmark is executed on a single CPU core; even so you might get different results since kernel loop cores as process runs, however you can overcome this with `taskset` command to pin your process to concrete core... again Xeon processor shows better results here... longer test runs.

uwsgi can be

Okay, I understand your point. But I just have one...

2012-10-10T23:45:32.329+03:00

Okay, I understand your point. But I just have one question. Running a benchmark, as it is. without http, just testing the urldispatcher gives me worse results than using uwsgi with all the overhead of the HTTP layer and network layer, etc. ..?

Is this confuses me a lot.

The same test is performed using a benchmark and using uwsgi + ab.
In my opinion, a benchmark should

In your test the apache benchmark concurrency is 2...

2012-10-10T23:17:39.904+03:00

In your test the apache benchmark concurrency is 2. See http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html.

The reason you do not see the difference is related to environment you are using. If the limit is in your network - you will see lower CPU load, etc. This test get rid of all these factors and just measure internal framework effectivity, no network, no web

No matter whether it is realistic or not realistic...

2012-10-10T22:48:18.079+03:00

No matter whether it is realistic or not realistic! In fact, if a server is with little power, could easily be a realistic configuration. What is needed is a deterministic scenario for all tests. If you have 2 or 20 processes processes, will demonstrate that uwsgi works well, but should not affect the results. Would scale linearly to the number of processes that can manage your server.

How about concurrency... you think 2 concurrent re...

2012-10-10T19:28:25.265+03:00

How about concurrency... you think 2 concurrent requests are realistic?

The benchmark represents nominal numbers... you most likely run into network, CPU limitations (client or server). See previous post about web frameworks performance: there are several frameworks that runs almost at speed of plain simple WSGI application and difference is not visible, for that reason there is

I've been testing your benchmarks, with overhe...

2012-10-10T19:08:03.392+03:00

I've been testing your benchmarks, with overhead of http, and I can not get results similar to yours. "wheezy" is fast, but in several cases bottle has better performance.

Of course there is not much difference between the results. In your first case, wheezy is 9 times faster than django. But testing on uwsgi directly, only 2 times faster.

I think your charts

The numbers are captured by python standard module...

2012-10-10T16:53:22.494+03:00

The numbers are captured by python standard module `timeit` (see benchmark.py:38), it doesn't provide metrics you requested.

Could you graph the evolution of req/seq over time...

2012-10-10T16:06:39.974+03:00

Could you graph the evolution of req/seq over time ? Thanks.