Re: Subject: Large PHP/Database driven site & scalability

I just posted another reply on the php-general mailing list with a few more specs - check that out - I know that having one beefy database server whether I throw 10 grand or 100 grand into it will eventually be outgrown because of the sheer ammount of data from a developement standpoint I definately need to figure out how I can get tables with 100,000 entries in them rather than several million (or even several hundred million) that is a rather dependant part of the process that is site specific what's really open for discussion I guess is the process in how webservers/database servers are organized - and to what would it take to do a query across all those databases I don't know if there is some really slick stuff thrown together to do it the problem with just replicating data and having a server pool is the sheer size of these tables - It just takes too long for an sql server to query 100 million rows when i could split a table up (sometimes) into susinct parts cached data is also a very important consideration having a real time game though with different users "playing cards?" would require some funky cross db server connections - but even then maybe that should be done on a dedicated server and assume it would take a whole shitload of talent to go beyond a single server for stuff like that sorry about the obvious brain dump I'm interested in anything you have to offer as well Thanks, Eric On Wed, 19 Jul 2000, David Sklar wrote: > Eric - > > I am attempting to solve similar problems with similar architectures (PHP, > MySQL, etc.) > > One thing that I have found that can cut down on load a lot is to take a hard > look at anything that gets calculated each time a request is processed and > evaluate whether it's something that can get processed offline and cached. > This doesn't work so well with user-specific information, but even if it's > something that can be regenerated every 5 minutes (or 1 minute), say, like a > list of top N players in a current game, it saves a ton of processing to have > a process create the necessary list, stick in in a file, and have the pages > that care about those numbers just include that file. > > What kind of hardware are you running the site on? I don't know what your > budget is like, but even a $5k - $6k box with 2 Pentium III 700s 1G RAM and a > few gigs of harddisk should be able to handle hundreds if not thousands of > queries a second. What's your SELECT vs. INSERT/UPDATE/DELETE mix? Can you use > replication to have all the write queries hit one box and then do your selects > off of it and replication slaves? > > -dave > > >