There are a number of ways to scale. There are several factors to consider
on the network level and on the application level, some of which are:
1. The load on the php engine - how much processing is required per visitor,
what are the respective frequencies of different processing tasks, and how
many concurrent users will you have? For most applications, server and
application optimization are sufficient (Zend Caneveral or Zend Optimizer,
efficient application code). However, optimization will only buy you one
order of magnitude, and there are those situations where this is
insufficient. In such cases, hardware solutions must be found. The first
step is to use state-preserving load balancing hardware and several
identical application servers. You will have to separate your data storage
and database server from your application server for this to work, but this
is rarely a challenge.
2. The load on the database - are there many reads? many writes? In many
cases you can cache common read queries - applications that don't have many
writes will scale more easily than applications that store a lot of new
data. You may be able to get away with using a single MySQL database server
and a SAN; the next level would probably be a more versatile enterprise
database solution. Don't give up on MySQL though, it has a lot of potential
and there are scalable solutions emerging these days. Check the MySQL web
site - I believe there was a seminar a couple of months ago about such a
solution. It's not free, but niether is Oracle.
3. Database design. It is imperative that you design your database well.
This is not difficult, but happens so rarely that I must mention it. The
statistics are shocking. If you are developing a scalable application that
uses a database, I implore you to read (or review) one or two good books on
relational databases. A good start is "Relational Database Design Clearly
Explained, Second Edition" by Jan L. Harrington, with whom I am not in any
way affiliated.
4. Storage - how much data do you plan to store/collect/use per visitor? If
each visitor has just 10MB of storage, and there are 100,000 active users,
you will need a terrabyte of storage - which may be possible on a single
machine. But how often are the files accessed? If each user accessed just
500kB per day, you would need 1.5 terrabytes of bandwidth per month. To give
you some perspective, a T1 line (at $500-700 per month) would yield some
500GB of total bandwidth. The result - you may need a bandwidth solution
before a you need a storage solution.
5. Type of access. It may be that many scripts or files (or more challenging
still, the same script or file) are accessed simultaneously at a particular
time and rarely at others - this interesting scenario can be seen in online
ticket sales for events such as concerts or games. Several solutions exist,
and vary significantly in effectiveness and reliablity. You will need to
account for peaks in bandwidth and ensure that there is sufficient slack in
the bandwidth available to you to handle the overload. Application
processing during such peaks may also pose problems.
As you can infer, the cost and solution can vary substantially depending on
your application, and it is only through rigorous analysis of a specific
situation that an ideal solution can be found. Often exact usage metrics are
not known prior to deployment and in such cases historical analysis of
similar functionality must be used to quantify predictions. Moreover, in
these situations measures must be taken to verify the conformity of
estimates to actual usage and alternative infrastructures must be designed
for rapid deployment in the event of unpredictable variations from the
projected load.
Do you have a site that needs scaling? We would be happy to consult with you
to determine if this is indeed the case and if so what the best course of
action is. Scalable systems are not inexpensive, but the cost per visitor
tends to be a lot lower with larger systems - I challenge you to find anyone
who thinks that $25k per month is a major cost when there are a million
people who frequent their web site.
ECRIA
http://www.ecria.com 
