[Grok-dev] Grok raw performance

[Sebastian Ware]

For what it is worth, I just want to mention that the performance of  
Grok on the CMS implementations I have done has not been an issue. In  
one case I am running with 500 content objects in Zodb using page  
templates. It is a multilingual, workflow based CMS back-end so it  
goes slightly beyond a "howdy earthlings" implementation. I do full  
text searching and so on.

http://www.boomtown.nu/

If I wanted to improve performance today, I would serve the static  
content directly through Nginx. I would also consider using memcache.  
The content delivery is snappy.

The bottom line is, wheras performance optimisation is great, I don't  
think there is any reason to panic. Reducing the code footprint seems  
to be a reasonable priority.

Mvh Sebastian

11 maj 2009 kl. 16.48 skrev Martijn Faassen:

> Michael Haubenwallner wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 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
> dependencies.
>
> * 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.
>
> Regards,
>
> Martijn
>
>
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev