> Hi all, > > I've been using TurboGears for the better part of a year now, and am a > big fan. I am about to develop a potentially very large social > networking site for my employer, and I'm trying to decide what > technologies to use. > > TurboGears has some problem which I don't think can be overcome: > > 1. Unfamiliar templating language. The UI for the "user" section of > this site will be coded by someone other than me. That someone is > already familiar with the Smarty PHP templating system. And would be > reluctant to switch to Genshi or Cheetah.
Their loss. Seriously, I hate smarty with a passion :) > 2. Need to restart the server. This is the big one, and my major > gripe with TurboGears. It has two major sub-problems: > > a. Whenever a single page (template) on the site is changed, the > server process needs to be restarted. This results in down-time (even > if only a couple of seconds). It also requires that template > designers, potentially unaware of their actions, have access to a site- > restart mechanism. You're talking about a big site right? professional development teams never, ever work on the live site. It is utterly untouchable. In any serious web organisation they barely have access to it except in an emergency, there is a handover from the dev team to the operations team. Outages and upgrades are scheduled events - often days or weeks before, run at times specifically identified as low user and - if there are serious uptime requirements - the transfer is done at the load balancer from one live production platform running the old version to the new production platform, allowing immediate rollback in the event of unexpected failure. If you're actually going to take downtime seriously, that's the kind of thinking you should be doing. If you're going to be running this whole thing on one box with everybody just muddling with the code whenever they feel like it, stop worrying about having to restart the server - it'll be the least of your worries. Places that have contracts for multiple 9's after the 99.% uptime do the above. If you're not one of those that's fine, but don't let server restarts scare you, they're just not that big a deal. And seriously, make sure you don't have people mucking around with live, it's just asking for trouble. Use SVN or whatever, and run a dev box, and export to live properly in scheduled releases. > b. If controller code is changed, and has significant bugs for some > reason, this causes the server process to die, or refuse to start. > This can cause even more down-time. There are a number of things that cover this eventually. The main thing is process - a solid test suite, proper discipline in terms of dev, pre-production and production platforms, and scheduled outages. The rest is standard tech, good monitoring, use of supervisord or equivalent auto-restart methods, exception catching, alerts, notifications and escalations. Do it right, and you'll be fine. > As much as I hate many aspects of PHP, at least it doesn't suffer from > this problem. hahaha. Try running a web hosting platform sometime :/ the number of ways PHP can use all available ram, bring the server to its knees and leave you with a completely unusable site are uncountable. Take no chances. > 3. Stability. I already have one site running with TG, and it cops a > reasonable amount of traffic. And it dies every couple of days. The > server process doesn't crash, it just stalls, and the whole site > becomes unresponsive. You have a problem with your installation, code or configuration, turn on all your logging, learn to use pdb for embedded debugging, etc. I have a number of commercial sites running in TG, several of them very complex and dealing with plenty of traffic. They don't fail at all. I have one that has been running pretty much continuously since TG 0.81, it's still there. That aside, see above regarding proper monitoring and restart processes. > 1. Has anyone used TG in this way before? Can anyone imagine benefits/ > drawbacks from doing this? Only that you're wasting your time writing a bunch of PHP when you don't have to. > 2. Can anyone comment on the TG problems I listed above (esp. item 2), > and tell us what you did to over-come them? In essence, I built my processes and methods around a real production environment. I'm not detailing all of this to put anyone down, the truth of the matter is that too few people getting out there and building their first "big" site have encountered a proper setup before, and don't realise how much is involved. If you do your homework and get the foundation right with your processes etc, you will gain something infinitely precious: uninterrupted sleep. For this purpose, TurboGears is more than capable and has no limitations that prevent it from being an effective player in the big website world. -- Richard Clark, Red Spider Limited http://www.redspider.co.nz/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
