On Fri, 31 May 2002, Justin Felker wrote: > I have spent the last hour pouring over this list's archive.
(Not a flame, but I keep seeing this recently. The word is "poring".) > I, along with several other people am starting a business which will depend > heavily on its web presence. Unfortunately, I am in the all too common > position of having to make technical decisions that will have repercussions > on the future well-being of said business, with little to no budget. It is > crucial that the solution I pick, handle what we hope will become a very > large load in the not-to-distant future (whether this happens or not is a > question for another day, heh). To this end, I am very interested in using > the LAMP (Linux+Apache+MySQL+PHP) approach. I have experience with all of > these technologies, but I am definitely not in a position to vouch for > their worthiness for use in a large scale application running beneath a > heavy load. > > To quantify LAMP's ability, is it appropriate for say, sites that generate > on the order of 5 million unique hits per day? If not, where would you > draw the line? At 500,000? Or 1 million? If so, how much higher could it > go possibly? 10 million? 20? > > . . . > > So, what say you? Given all that I have said, is LAMP appropriate? Will > PHP and maybe even more importantly, MySQL be able to scale well? I have > no doubt that MySQL is fast, but just how scaleable is it? Will it die > beneath the kind of loads I have described? It's really difficult to answer this question without knowing a lot more about your application. But as a casual guess, if you reach that sort of traffic level, I'd say your stumbling block is going to by MySQL. At some point - granted, that point can be far away if you design your database and queries well - it will buckle under load. I'm too busy actually working, unfortunately, to pay attention to the bleeding edge developments in MySQL. But as it stands, there's no serious support for clustering, which means that when you are pushing more transactions than can be handled by the most expensive single machine you can afford, you've hit a brick wall. And as you know, there is a point after which multiple lesser-powered machines are a whole lot cheaper than a single mighty one. If your database transactions are mostly read-only, and you can segregate the infrequent write transactions to a separate server, you can do jury-rigged replication of the main data store and scale indefinitely. Otherwise, you'll probably have to plan with an eye to a migration path toward Oracle, DB2, or whatever. This doesn't mean you can't start out with MySQL, but it does mean you should develop with a database abstraction layer and shouldn't depend on features that are fast in MySQL but poorly supported by other databases (or emulated in the abstraction layer). As for Linux, Apache, and PHP, there's no limit to the transaction volume you can handle with even rudimentary load-balancing tactics, so that's nothing to worry about. miguel -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
