Hi,
I understand the decision of going for Pylons with TG2, but I think
there's a large group of TG users that originally came from the
CherryPy camp that are not all to happy with this (including myself).
They love CP and have a lot of knowledge about CP, and they want to
continue using that knowledge in their future projects. They also know
about the good things about CP3 (tools, config, ...) and would like to
be able to use those features with their TG projects.
I think the main problem with CP3 and TG is that the projects have
drifted apart. In my view, CP3 is making things more explicit (tools,
config), while TG tries to make things more implicit (one for all
@expose, ...). CP3 uses the config system in a very different way than
TG to get different behaviour at different parts of the application.
Thus with CP3 you can fine tune your system to get higher performance.
With my TG application, even the simplest controller suffers from the
complexity of the rest of the system. If I need session, identity,
transactions, widgets support in one part of the application, then a
simple static controller also suffer from this. With CP3 you can fine
tune the config system, so simple controllers run at the highest
speed, while complex controllers have to suffer from the features they
need. One might argue that TG is fast enough, but in my view a
controller that runs twice as fast can handle twice as many users (or
use one less server $$).
One could port TG1 to CP3, but it may not make much sense, since it
would be hard to utilize the CP3 features within TG. For TG to be CP3
"friendly" one would have to rewrite features such as sessions,
identity, transactions, widget handling etc to become CP3 Tools. This
is possible and very interesting, but even if the API could be kept
mostly intact, it would be a very different animal than both TG1 or
TG2.
As a test I used a few days to rewrite my application that uses TG1,
Genshi, SQLObject (MySQL/InnoDB) and ToscaWidgets to run on CP3 by
porting the TG database/transaction and identity system as CP3 Tools.
I also had to write ToscaWidgets as a CP3 Tool. To test the system, I
checked the perfomance with funcload on one of my simplest
controllers, the /faq page. It still renders Genshi and uses SO
database for session storage with transactions, so it makes things
more interesting than an empty page.
As I expected, with exact same featues for my application on both TG1
and CP3, the performance was very different. Below I show the best
cycle for each test (75 CU) for 20 seconds:
With TG1:
The number of Successful **Page** Per Second (SPPS) over Concurrent
Users (CUs)
CUs SPPS maxSPPS TOTAL SUCCESS ERROR MIN AVG
MAX P10 MED P90 P95
1 0.700 1.000 14 14
0.00% 0.137 0.149 0.216 0.138 0.141 0.158 0.216
75 6.100 30.000 122 122 0.00%
4.683 8.486 11.604 5.341 8.771 11.119 11.330
Slowest average response time during the best cycle with **75** CUs: *
In page 001 get: /faq took **8.197s**
With CP3:
The number of Successful **Page** Per Second (SPPS) over Concurrent
Users (CUs)
CUs SPPS maxSPPS TOTAL SUCCESS ERROR MIN AVG
MAX P10 MED P90 P95
1 0.750 1.000 15 15
0.00% 0.052 0.064 0.215 0.052 0.052 0.055 0.215
75 17.800 53.000 356 356 0.00%
0.091 2.478 4.959 0.666 2.513 4.177 4.310
Slowest average response time during the best cycle with **75** CUs: *
In page 001 get: /faq took **1.938s**
For both cases TG1 and CP3 ran behind apache (mod_rewrite), and apache
handled all static content. SPPS includes the times for static
content, slowest avg resp time is for the /faq page alone. Funcload
was running on the same machine as the server, so numbers should be
better for both cases in a different setup.
One could argue about how interesting it is to serve faq pages, but at
least I know now that CP3 can serve 3 times as many pages as TG1 for
the same period of time. TG1 is quite slow, and my gut feeling tells
me that I'm worried about the performance of TG2. It's difficult to
test TG2 right now since it's missing many features, but I will try
with a simpler controller.
Anyway, CP3 is very fast! It's also quite easy to make some
controllers that uses identity, sessions, transactions, widgets etc
and some controllers that don't use such features and most importantly
don't suffer in performance because other controllers needs more
advanced featues.
TG3 anyone ;-)
-- Dag
On Dec 18, 10:54 pm, Christopher Arndt <[EMAIL PROTECTED]> wrote:
> simpsomboy schrieb:
>
> > Some months past... and now, what about cherrypy3 with tg1.1?
>
> CherryPy 3 support for TG is dead.*
>
> > I've found some issues about this, specially
> > thishttp://trac.turbogears.org/ticket/1181,
>
> This ticket is closed and obsolete.
>
> > at trunk, actually tg2 cherrypy sems to be no longer used, and at 1.1
> > branche, the requerimet is "CherryPy >= 2.2.1,<3.0.0alpha" yet...
>
> Yes, TurboGears 1.0.x is still based on CherryPy 2.2 and won't work with
> CherryPy 3.
>
> > somebody have some answer about it?
>
> It seems that you have not been following the latest developments in
> TurboGears land very closely lately. Here are some pointers to get you
> started on reading up on the status of TG today:
>
> http://docs.turbogears.org/1.1/DevPlanshttp://docs.turbogears.org/2.0/RoughDocs/WhatsNewhttp://docs.turbogears.org/Newshttp://paddyland.serveblog.net/article/18
>
> Chris
>
> * Unless somebody wants to have another try at porting TG 1.1 to CP 3.
> But that would basically mean forking TG 1.1 and TG 2.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
