TG does not create a "new instance per request" if it is set up as an app server. indeed it operates on a thread pool, equivalent to an apache mpm worker pool. This is pretty much as optimal as you get short of very tricky multi-paradigm tricks using things like libevent. PHP5 itself can, I believe, operate in a multithread fashion, but the last I looked (some time ago admittedly) many of the libraries commonly used were unable to operate in threaded mode and thus demand a multiprocess apache worker instead.
In general, it depends much more on what, precisely, you're *doing* within any given request that will be the final determination of efficiency. The Turbogears model allows the use of app-server memory, allowing you to do queues, caching etc using thread locks and similar tools. These are generally faster than inter-process communication (although these days it gets pretty up in the air if you have multiple cores etc), and better integrated with the app server so you don't have to worry about stuff hanging around after shutdown etc. On the other hand, pretty much nobody actually does this. SQLobject uses it for locking and caching but after some practical experimentation it turned out this was more of a mistake than anything else. Instead people tend to use memcached for caching, and a variety of ext- process queue servers for fast queue management. As a result there's no real win for the threads for those tasks. It used to be general wisdom that threads were quicker than processes for startup, but the use of pooling on both models has made that pretty redundant. So in general, it's all pretty much a wash. you'd never implement something the same way in PHP and TG, so apples-to-apples comparisons are almost pointless. People using TG do it primarily because it's simply faster to build apps in, not because it performs better or worse. PHP loses because the language is ugly, but has one win for deployment that are worthy of note: You don't have to restart anything to bring in new code. For people doing rapid updates on popular sites this has particular value, and is one of my main regrets about TG as a platform choice - the main site I use it on now couldn't have been built on PHP in time, but as a result every time I do an update people get thrown off the system for the 7 seconds to takes to perform a restart. In the end however, the choice of wsgi or proxy or PHP or whatever was dwarfed by the sheer precision of the needs of a heavily loaded app. In one case I had to replace a particular set of functions with a twisted implementation because it was getting hit so fast, and needed a very precise level of atomicity for updates. In other areas stuff got batched out to database, offloaded to memcache, loaded into internal caches, turned into stored procedures within postgres, views, a libevent-driven queue service, a front-end static-only server with proxy for dynamic sections, etc etc all based on the various demands of the problems at hand. Worrying about the speed of one tiny component of your overall stack in any given tiny subset of the possible use cases seems like a waste of time. The questions are simple: can you build it? can you change it? can you manage it? will it do what you need? maximize as many of these factors as you can with your platform choice and then go for it. If all you want is lightning speed, gcc, libevent and a lot of work will get you something that will leave any modern web platform in the dust. Stop worrying about performance, TG, PHP, RoR - they're all plenty fast enough for almost any application, and where they aren't you can do what I did and slice out the one or two functions that need more speed and use an alternate method. On Jun 27, 6:17 pm, Sanjay <[EMAIL PROTECTED]> wrote: > Hi All, > > It might be a novice question on deployment. I am a TurboGears guy > since long, but still new to certain things like deployment etc. So, > pl. bear with me if my words are not exact and technical. > > A couple of days back I was presenting about TurboGears to a PHP web > architect. He was of the view that PHP behind Apache is faster because > it doesn't have to create new instances per request or queue requests. > > But frameworks like RoR create new instances for each request and > hence is not preferable for high traffic sites. > > CherryPy applications, as I have understood, do similar thing as PHP > and should be at par. So, reverse proxing a TG Application behind > Apache or NginX should be at par with a PHP+Apache deployment. > > Is my understanding ok? > What about TG 2.0? > > thanks > Sanjay --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
