I just want to thank everyone for their responses.  I do realize this was 
not exactly a question that could be "answered" as such but I still wanted 
to hear some people that have had personal experiences dealing with similar 
issues.  FYI, I have read many websites that attempt to answer this 
question in one way or another, but I feel that the details I can get from 
places such as this mailing list are much better.

Anyways, to focus on one question I had asked, can anyone provide with 
websites that run using LAMP (large, higly trafficed 
websites)?  http://www.sourceforge.net comes to mind, but I don't know 
really what's going on in the background.  Specific examples would be 
helpful to my case.

Any ideas?


At 12:46 PM 5/31/2002 -0500, you wrote:
>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".)

hehe, thanks.

> > 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
>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.
>PHP General Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to