<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The great web technology shootout &#8211; Round 3: Better, Faster, and Shinier</title>
	<atom:link href="http://blog.curiasolutions.com/2009/10/the-great-web-technology-shootout-round-3-better-faster-and-shinier/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.curiasolutions.com/2009/10/the-great-web-technology-shootout-round-3-better-faster-and-shinier/</link>
	<description>Technology thoughts and ideas</description>
	<lastBuildDate>Sun, 11 Sep 2011 16:00:11 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: The great web technology shootout – Round 4: Pyramid vs Django vs TG vs Rails 2 &#38; 3 - Curia</title>
		<link>http://blog.curiasolutions.com/2009/10/the-great-web-technology-shootout-round-3-better-faster-and-shinier/comment-page-1/#comment-288</link>
		<dc:creator>The great web technology shootout – Round 4: Pyramid vs Django vs TG vs Rails 2 &#38; 3 - Curia</dc:creator>
		<pubDate>Fri, 19 Nov 2010 00:08:34 +0000</pubDate>
		<guid isPermaLink="false">http://blog.curiasolutions.com/?p=409#comment-288</guid>
		<description>[...] Development [Note: This post is the continuation of a series. Please read Round 1, Round 2, and Round 3 first if you are just now joining [...]</description>
		<content:encoded><![CDATA[<p>[...] Development [Note: This post is the continuation of a series. Please read Round 1, Round 2, and Round 3 first if you are just now joining [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jeo</title>
		<link>http://blog.curiasolutions.com/2009/10/the-great-web-technology-shootout-round-3-better-faster-and-shinier/comment-page-1/#comment-66</link>
		<dc:creator>jeo</dc:creator>
		<pubDate>Sun, 07 Mar 2010 08:54:22 +0000</pubDate>
		<guid isPermaLink="false">http://blog.curiasolutions.com/?p=409#comment-66</guid>
		<description>Nice...not on twitter but sure would be cool to see a node.js test...</description>
		<content:encoded><![CDATA[<p>Nice&#8230;not on twitter but sure would be cool to see a node.js test&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Arndt</title>
		<link>http://blog.curiasolutions.com/2009/10/the-great-web-technology-shootout-round-3-better-faster-and-shinier/comment-page-1/#comment-41</link>
		<dc:creator>Chris Arndt</dc:creator>
		<pubDate>Fri, 09 Oct 2009 23:02:21 +0000</pubDate>
		<guid isPermaLink="false">http://blog.curiasolutions.com/?p=409#comment-41</guid>
		<description>@Jorge I ran the TG2 tests with the 2.0.3 release.</description>
		<content:encoded><![CDATA[<p>@Jorge I ran the TG2 tests with the 2.0.3 release.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alex Dedul</title>
		<link>http://blog.curiasolutions.com/2009/10/the-great-web-technology-shootout-round-3-better-faster-and-shinier/comment-page-1/#comment-40</link>
		<dc:creator>Alex Dedul</dc:creator>
		<pubDate>Fri, 09 Oct 2009 08:51:17 +0000</pubDate>
		<guid isPermaLink="false">http://blog.curiasolutions.com/?p=409#comment-40</guid>
		<description>Nice tests, thank you :)</description>
		<content:encoded><![CDATA[<p>Nice tests, thank you :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jorge Vargas</title>
		<link>http://blog.curiasolutions.com/2009/10/the-great-web-technology-shootout-round-3-better-faster-and-shinier/comment-page-1/#comment-39</link>
		<dc:creator>Jorge Vargas</dc:creator>
		<pubDate>Fri, 09 Oct 2009 05:01:42 +0000</pubDate>
		<guid isPermaLink="false">http://blog.curiasolutions.com/?p=409#comment-39</guid>
		<description>@Chris Arndt 

is that TG2 or TG2.1? as you can see from the tests 2.1 has been getting some performance improvements.</description>
		<content:encoded><![CDATA[<p>@Chris Arndt </p>
<p>is that TG2 or TG2.1? as you can see from the tests 2.1 has been getting some performance improvements.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jorge Vargas</title>
		<link>http://blog.curiasolutions.com/2009/10/the-great-web-technology-shootout-round-3-better-faster-and-shinier/comment-page-1/#comment-38</link>
		<dc:creator>Jorge Vargas</dc:creator>
		<pubDate>Fri, 09 Oct 2009 05:00:53 +0000</pubDate>
		<guid isPermaLink="false">http://blog.curiasolutions.com/?p=409#comment-38</guid>
		<description>@Graham

That is a very good point. And I think that should be a really nice benchmark. And In fact I believe TG will come up really nice on that, mainly because TG is not affected by the &quot;more routes more lookups&quot;, in case you are not familiar TG builds a graph of objects ie:

class BlogController:
    def index(self):
        pass

class RootController:
    blog = BlogController
    def index(self):
        pass

so /index and /blog/index are the urls. Since this is pure python traversal having as many methods/instances will not slow TG down. However it has one drawback in deep nested structures, that said I believe if you go beyond 5-6 elements in your PATH_INFO you are probably doing something else wrong.</description>
		<content:encoded><![CDATA[<p>@Graham</p>
<p>That is a very good point. And I think that should be a really nice benchmark. And In fact I believe TG will come up really nice on that, mainly because TG is not affected by the &#8220;more routes more lookups&#8221;, in case you are not familiar TG builds a graph of objects ie:</p>
<p>class BlogController:<br />
    def index(self):<br />
        pass</p>
<p>class RootController:<br />
    blog = BlogController<br />
    def index(self):<br />
        pass</p>
<p>so /index and /blog/index are the urls. Since this is pure python traversal having as many methods/instances will not slow TG down. However it has one drawback in deep nested structures, that said I believe if you go beyond 5-6 elements in your PATH_INFO you are probably doing something else wrong.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Seth</title>
		<link>http://blog.curiasolutions.com/2009/10/the-great-web-technology-shootout-round-3-better-faster-and-shinier/comment-page-1/#comment-37</link>
		<dc:creator>Seth</dc:creator>
		<pubDate>Fri, 09 Oct 2009 04:13:40 +0000</pubDate>
		<guid isPermaLink="false">http://blog.curiasolutions.com/?p=409#comment-37</guid>
		<description>Graham, your question is intriguing and perhaps in the coming weeks I will find the time to put such a test together.

Chris, as I believe CherryPy is expected to be faster than Paster, I put TG 1.1 through my mod_wsgi test and came up with the following results: http://bit.ly/1czNm3 . I was not able to get Mako to work for some reason.</description>
		<content:encoded><![CDATA[<p>Graham, your question is intriguing and perhaps in the coming weeks I will find the time to put such a test together.</p>
<p>Chris, as I believe CherryPy is expected to be faster than Paster, I put TG 1.1 through my mod_wsgi test and came up with the following results: <a href="http://bit.ly/1czNm3" rel="nofollow">http://bit.ly/1czNm3</a> . I was not able to get Mako to work for some reason.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Graham Dumpleton</title>
		<link>http://blog.curiasolutions.com/2009/10/the-great-web-technology-shootout-round-3-better-faster-and-shinier/comment-page-1/#comment-36</link>
		<dc:creator>Graham Dumpleton</dc:creator>
		<pubDate>Fri, 09 Oct 2009 00:12:56 +0000</pubDate>
		<guid isPermaLink="false">http://blog.curiasolutions.com/?p=409#comment-36</guid>
		<description>Jens, a very basic hello world test may not say too much, but hello world tests can still be informative for developers of frameworks if they go to the extent of breaking down how much time is spent in each major component within their system. That is, routing, database, data processing and templating. And then varying the complexity of configured routing and templates to gauge how the growing complexity affects the throughput ability. To do this in a meaningful way you can&#039;t just use any application as you need to control that complexity in a step wise fashion to get meaningful results.

This is why I was pushing for some benchmarks for increases in routing complexity as I have a feeling this is an area which is often neglected and where users may not even appreciate the implications on performance by adding more and more URLs within an application using whatever routing mechanism configuration has to be used.</description>
		<content:encoded><![CDATA[<p>Jens, a very basic hello world test may not say too much, but hello world tests can still be informative for developers of frameworks if they go to the extent of breaking down how much time is spent in each major component within their system. That is, routing, database, data processing and templating. And then varying the complexity of configured routing and templates to gauge how the growing complexity affects the throughput ability. To do this in a meaningful way you can&#8217;t just use any application as you need to control that complexity in a step wise fashion to get meaningful results.</p>
<p>This is why I was pushing for some benchmarks for increases in routing complexity as I have a feeling this is an area which is often neglected and where users may not even appreciate the implications on performance by adding more and more URLs within an application using whatever routing mechanism configuration has to be used.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jens Diemer</title>
		<link>http://blog.curiasolutions.com/2009/10/the-great-web-technology-shootout-round-3-better-faster-and-shinier/comment-page-1/#comment-35</link>
		<dc:creator>Jens Diemer</dc:creator>
		<pubDate>Thu, 08 Oct 2009 06:34:25 +0000</pubDate>
		<guid isPermaLink="false">http://blog.curiasolutions.com/?p=409#comment-35</guid>
		<description>IMHO a Benchmark make only sense if you test is near a real world example instead of a &quot;Hello World&quot;.
With a minimal Test app, you will only test the Overhead of this small part of the Framework.</description>
		<content:encoded><![CDATA[<p>IMHO a Benchmark make only sense if you test is near a real world example instead of a &#8220;Hello World&#8221;.<br />
With a minimal Test app, you will only test the Overhead of this small part of the Framework.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Arndt</title>
		<link>http://blog.curiasolutions.com/2009/10/the-great-web-technology-shootout-round-3-better-faster-and-shinier/comment-page-1/#comment-33</link>
		<dc:creator>Chris Arndt</dc:creator>
		<pubDate>Wed, 07 Oct 2009 23:52:15 +0000</pubDate>
		<guid isPermaLink="false">http://blog.curiasolutions.com/?p=409#comment-33</guid>
		<description>Interesting comparison. I have ported the test code for TurboGears2 to TurboGears 1.1. On my hardware (a Mac mini 1.87 Ghz Core Duo with 2GB RAM), the results for TG 1.1 vs TG 2 are:

TG1 (using CherryPy built-in server):

Document Path:          /
Requests per second:    284.03 [#/sec] (mean)
Document Path:          /genshi_hello
Requests per second:    144.52 [#/sec] (mean)
Document Path:          /mako_hello
Requests per second:    198.85 [#/sec] (mean)
Document Path:          /jinja_hello
Requests per second:    208.91 [#/sec] (mean)
Document Path:          /raw_sql
Requests per second:    121.98 [#/sec] (mean)
Document Path:          /genshi_sql
Requests per second:    119.51 [#/sec] (mean)
Document Path:          /mako_sql
Requests per second:    120.14 [#/sec] (mean)
Document Path:          /jinja_sql
Requests per second:    120.77 [#/sec] (mean)

TG 2 (using paste built-in server:

Document Path:          /
Requests per second:    199.22 [#/sec] (mean)
Document Path:          /genshi_hello
Requests per second:    109.45 [#/sec] (mean)
Document Path:          /mako_hello
Requests per second:    142.79 [#/sec] (mean)
Document Path:          /jinja_hello
Requests per second:    153.79 [#/sec] (mean)
Document Path:          /raw_sql
Requests per second:    90.98 [#/sec] (mean)
Document Path:          /genshi_sql
Requests per second:    62.28 [#/sec] (mean)
Document Path:          /mako_sql
Requests per second:    91.30 [#/sec] (mean)
Document Path:          /jinja_sql
Requests per second:    95.47 [#/sec] (mean)


I&#039;ll upload the code to http://chrisarndt.de/projects/wf-shootout/ shortly.</description>
		<content:encoded><![CDATA[<p>Interesting comparison. I have ported the test code for TurboGears2 to TurboGears 1.1. On my hardware (a Mac mini 1.87 Ghz Core Duo with 2GB RAM), the results for TG 1.1 vs TG 2 are:</p>
<p>TG1 (using CherryPy built-in server):</p>
<p>Document Path:          /<br />
Requests per second:    284.03 [#/sec] (mean)<br />
Document Path:          /genshi_hello<br />
Requests per second:    144.52 [#/sec] (mean)<br />
Document Path:          /mako_hello<br />
Requests per second:    198.85 [#/sec] (mean)<br />
Document Path:          /jinja_hello<br />
Requests per second:    208.91 [#/sec] (mean)<br />
Document Path:          /raw_sql<br />
Requests per second:    121.98 [#/sec] (mean)<br />
Document Path:          /genshi_sql<br />
Requests per second:    119.51 [#/sec] (mean)<br />
Document Path:          /mako_sql<br />
Requests per second:    120.14 [#/sec] (mean)<br />
Document Path:          /jinja_sql<br />
Requests per second:    120.77 [#/sec] (mean)</p>
<p>TG 2 (using paste built-in server:</p>
<p>Document Path:          /<br />
Requests per second:    199.22 [#/sec] (mean)<br />
Document Path:          /genshi_hello<br />
Requests per second:    109.45 [#/sec] (mean)<br />
Document Path:          /mako_hello<br />
Requests per second:    142.79 [#/sec] (mean)<br />
Document Path:          /jinja_hello<br />
Requests per second:    153.79 [#/sec] (mean)<br />
Document Path:          /raw_sql<br />
Requests per second:    90.98 [#/sec] (mean)<br />
Document Path:          /genshi_sql<br />
Requests per second:    62.28 [#/sec] (mean)<br />
Document Path:          /mako_sql<br />
Requests per second:    91.30 [#/sec] (mean)<br />
Document Path:          /jinja_sql<br />
Requests per second:    95.47 [#/sec] (mean)</p>
<p>I&#8217;ll upload the code to <a href="http://chrisarndt.de/projects/wf-shootout/" rel="nofollow">http://chrisarndt.de/projects/wf-shootout/</a> shortly.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

