We tried the CP3 route, and I think if we are willing to break 1) tg1
style tests, and 2) configuration, it's not at all hard to make
TurboGears work with CherryPy 3, and it would be a great idea for TG
1.1 if there are people who are very interested in it -- and willing
to work on it.  I'm actually find with breaking 2, but 1 seems more
difficult to justify.  If we want this to be an incremental update
where is is very easy for people to port their applications they
should be able to run tests to prove things worked...

I don't think the TG community would be well served by us sidetrack
TG2 development, or overload the current developer base CP3
integration, but we will definitely accept patches. ;)

And if you make significant progress on this, I'm sure there will be
some people who can't help but get excited by this, and want to help
out.  ;)

--Mark Ramm

On Dec 26, 2007 9:26 AM, dbrattli <[EMAIL PROTECTED]> wrote:
>
> 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:54pm, 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.
> >
>



-- 
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to