> "my time has a cost and optimisation often buys less performance than, > say, a Dell SC1425" > Unfortunatly my time is not worth a IBM 64way mainframe (or I would be > one happy hacker). Bigger machines help but as my comment said before > this will give you only linear optimization at some point you will need > _exponential_ optmizaitions. This also depends on the complexity of the > data relationships that your application needs. You need a machine that > is 64 times faster buy
Nah mate you miss my point! Not bigger machines, *more* machines. A Dell SC1425 is a pretty low-end piece of kit, the idea is you use multiple machines. Let's say you have an application that is currently running at 100% above acceptable capacity. You can solve this problem in basically four ways: 1. Buy hardware that is twice as powerful 2. Perform optimisation, caching - etc. 3. A combination of the 1) and 2) 4. Buy another similar server and run them both In my experience, 4) is always the cheapest option, and requires less hassle than 2) and 3) (and less hassle is the TG way!). The trick is to make option 4 possible by asking questions like "What will happen if I use two app or database servers - or both" early on in the build process. I do this for everything and it's served me right so far :-) Part of my personal PHP standard library is some wrappers around session management and database handling that means: 1) All my session data is stored in the database, which means from then on I can implement *all* my persistent storage in an RDBMS. 2) My database "reads" and my database "writes" are separated and controllable, so if we need to add replication it's possible to direct all writes to the master server and balance reads between the slaves. (Yes I said there are alternatives to the master/slave setup, but in web apps which are mostly read-heavy it's a pretty good solution anyway). -Rob PS. If you're interested in the "writing to one place" problem, you should look m/custer (http://www.continuent.com/index.php?option=com_content&task=view&id=211&Itemid=168). We have our own solution, but in general it's a pretty awesome setup for database scaling through multiple servers. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
