Comments on: The great web technology shootout – Round 1: A quick glance at the landscape http://blog.curiasolutions.com/2009/09/the-great-web-development-shootout/ Technology thoughts and ideas Tue, 13 Jul 2010 02:50:28 -0700 http://wordpress.org/?v=2.8.6 hourly 1 By: Seth http://blog.curiasolutions.com/2009/09/the-great-web-development-shootout/comment-page-1/#comment-19 Seth Thu, 01 Oct 2009 23:20:08 +0000 http://blog.curiasolutions.com/?p=172#comment-19 Marcel, Thanks for the info. I'll have to take a look at it. Feel free to quote, although you may want to wait for "part 3" (which I should have done next week). I'll be doing a bit more "scientific" tests for each Python framework, and revisiting Bottle in a little bit more detail (with the test source code). Stay tuned ;) Marcel,

Thanks for the info. I’ll have to take a look at it.

Feel free to quote, although you may want to wait for “part 3″ (which I should have done next week). I’ll be doing a bit more “scientific” tests for each Python framework, and revisiting Bottle in a little bit more detail (with the test source code).

Stay tuned ;)

]]> By: Marcel Hellkamp http://blog.curiasolutions.com/2009/09/the-great-web-development-shootout/comment-page-1/#comment-18 Marcel Hellkamp Thu, 01 Oct 2009 22:55:01 +0000 http://blog.curiasolutions.com/?p=172#comment-18 fapws3 is another asynchronous HTTP/WSGI web server, similar to Tornado. It uses libev instead of epoll and is definitely worth a look. http://github.com/william-os4y/fapws3 Oh, and thanks for this great article. I hope you don't mind if I quote you on Bottles start page ;) fapws3 is another asynchronous HTTP/WSGI web server, similar to Tornado. It uses libev instead of epoll and is definitely worth a look. http://github.com/william-os4y/fapws3

Oh, and thanks for this great article. I hope you don’t mind if I quote you on Bottles start page ;)

]]> By: Seth http://blog.curiasolutions.com/2009/09/the-great-web-development-shootout/comment-page-1/#comment-12 Seth Sat, 19 Sep 2009 07:45:05 +0000 http://blog.curiasolutions.com/?p=172#comment-12 Graham, Thanks for your input. I'm planning on re-doing this in mod_wsgi embedded mode soon. My initial testing seems to indicate an increase of several hundred req/sec. You have really given the community a killer module. Thank you! Graham,

Thanks for your input. I’m planning on re-doing this in mod_wsgi embedded mode soon. My initial testing seems to indicate an increase of several hundred req/sec.

You have really given the community a killer module. Thank you!

]]> By: Graham Dumpleton http://blog.curiasolutions.com/2009/09/the-great-web-development-shootout/comment-page-1/#comment-11 Graham Dumpleton Tue, 15 Sep 2009 06:03:08 +0000 http://blog.curiasolutions.com/?p=172#comment-11 Hooray, someone who has actually tried to provide a realistic comparison of Tornado rather than their biased comparison of a Tornado hello world application with heavy weight Django. Using a WSGI hello world application is a much more realistic comparison for what they were running on Tornado. You didn't even use the fastest configuration for mod_wsgi and it still came out equivalent and nothing like their claim of Tornado being 4 times better. As far as scaling up of Tornado, it still remains to be seen how well that will work when you start using a proper blocking WSGI interface on top of Tornado and with longer request times. Sure you can write purpose built event driven web applications for Tornado which may perform better, but that doesn't mean existing WSGI applications somehow benefit from Tornado being event driven in its core. Multiprocess event driven servers arguably may also be a really bad idea for WSGI applications due to the possible blocking effects. Hooray, someone who has actually tried to provide a realistic comparison of Tornado rather than their biased comparison of a Tornado hello world application with heavy weight Django. Using a WSGI hello world application is a much more realistic comparison for what they were running on Tornado. You didn’t even use the fastest configuration for mod_wsgi and it still came out equivalent and nothing like their claim of Tornado being 4 times better.

As far as scaling up of Tornado, it still remains to be seen how well that will work when you start using a proper blocking WSGI interface on top of Tornado and with longer request times. Sure you can write purpose built event driven web applications for Tornado which may perform better, but that doesn’t mean existing WSGI applications somehow benefit from Tornado being event driven in its core. Multiprocess event driven servers arguably may also be a really bad idea for WSGI applications due to the possible blocking effects.

]]> By: Chris Gratigny http://blog.curiasolutions.com/2009/09/the-great-web-development-shootout/comment-page-1/#comment-10 Chris Gratigny Mon, 14 Sep 2009 06:59:14 +0000 http://blog.curiasolutions.com/?p=172#comment-10 ouch. at least Kohana is much faster than Cake :) ouch.

at least Kohana is much faster than Cake :)

]]>