[Grok-dev] Grok raw performance

Martijn Faassen faassen at startifact.com
Mon May 11 10:48:19 EDT 2009

Michael Haubenwallner wrote:
> Hash: SHA1
> Raw performance comparison of grok and competing web frameworks
> method: ab -n 1000 http://localhost:port/
> system: ubuntu8.4, python2.6
> # grok (wsgi) == 100%, bigger numbers are better
> 0.8 ... grok (zopectl, zodb)
> 1.0 ... grok (wsgi, zodb)
> 2.3 ... zope2.12 (zodb)
> 7.3 ... repoze (zodb)
> 7.3 ... pylons (no db)
> 8.6 ... repoze (no db)
> I remember that repoze had 3 times the reqs/sec of grok some months ago,
> then started to optimize and is now almost 9 times faster than grok.
> Anyone interested in working on speed optimizations? This could be a
> target for a Grok 1.1 release.

It's important to know what we're actually testing here. What is behind 
localhost:port? How much overhead do we get from real-world Grok 
applications? With repoze, do you mean bfg?

Feel free to profile the stack. However...

I'm far more interested in getting the total code footprint of Grok down 
first, and worry about optimization later (which a lower code footprint 
should make a lot easier).

What I think should be done:

* start pulling in the new refactored libraries to seriously cut down on 

* make progress on the zope.pipeline topic

* look into a simplification of the traversal mechanism

I expect that a minimal configuration of bfg will always be faster than 
Grok, as Grok simply tries to do more. But I'd like to get Grok's 
minimal configuration down a lot.

Anyway, profiling and optimization would be helpful too in knowing where 
to focus our simplification efforts, but again I'm far more interested 
in *simplifying* the code that's behind publishing a request in Grok 
than I am in optimizing it right now.



More information about the Grok-dev mailing list