I wrote previously:
> I've still got some decisions to make such as FastCGI vs mod_python - > anybody have the pro's and con's between these two? Sorry, after doing some Googling and looking around it appears I should be considering SCGI rather than FastCGI. > > > I was wondering how well turbogears scales? Obviously interesting > > caching tricks can be done on the web face, and other strange voodoo > > can be done in the database, but is turbogears itself designed to > > scale? > > I don't see any reason why it shouldn't scale. A lot of it boils down > to the nature of your app. Python as a language is easily good enough > to power large systems. Ruby, Perl and PHP have all been used to > implement large systems and they're arguably slower than Python. > > So a lot depends on your webserver configuration and your system > architecture. > > Cache what you can, cut down database hits etc. > > > Can I host the controller, for instance, on multiple servers for better > > response time? If not, would it even be a good idea to implement that > > kind of functionality? > > Yes - here's how I'm approaching this: > > I'm planning to run Apache with either FastCGI or mod_python. CherryPy > will sit behind Apache and handle my controllers. I'm not going to use > sessions although I'll use minimal cookie data to store state. I'm > going to follow the mantra of sharing nothing. > > The controllers will access the database server using SQLObject. The > database server is running Postgres. Another server will be used for > storing user images and files using the native flat file system. > > Scaling then: when I need to scale I'll add another web server running > Apache and TurboGears/CherryPy. I'll load balance between these web > servers probably in a round-robin way to begin with. There are hardware > and software solutions to load balancing. So, different web servers > will be able to handle different requests from the same user. This is > why sharing nothing is a good idea. Try not to store state on your web > servers. > > As the number of web servers increases they'll begin to stress the > database. The database server will become the bottleneck. Cache if you > can. Next on the cards then is some form of database replication, > although that's sufficiently far enough into the future to not worry > about just now. :-) > > Bottom line: I think the framework is good enough to trigger your > controllers and deliever templated response in a timely fashion. The > rest is down to external factors that apply to any other web system out > there. > > I've still got some decisions to make such as FastCGI vs mod_python - > anybody have the pro's and con's between these two? > > > >>I was wondering how well turbogears scales? Obviously interesting >>caching tricks can be done on the web face, and other strange voodoo >>can be done in the database, but is turbogears itself designed to >>scale? >> >>Can I host the controller, for instance, on multiple servers for better >>response time? If not, would it even be a good idea to implement that >>kind of functionality? >> >>If you had to design a truly big system, or a lot of little >>interconnected remote sites, and wanted TG to do it what are the >>options? >> >>Can I do this entire post entirely with questions? I think not. >> >> >> >> >> > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
