NYCPHP Meetup

[Ophir Prusak]

I'd like to clear up some potential confusion about the term "scalable".
See http://labs.google.com/glossary?q=scalable for some pretty good
definitions.
While we all agree (hopefully) about what scalable means, I think we're
talking about two different things that we're trying to scale.
You can talk about scalability of a web site in regards to:
1. Traffic and users - meaning if we get 100 times the traffic can we simply
add 100 times the hardware without the need make any significant changes to
the code/architecture.
2. Application complexity - meaning if we want to add more functionality to
the site, can we do so without making significant changes to the existing
code/architecture.

While I think it's obvious that LAP scale quite well in regards to traffic
(CCI proves this), I do agree that in regards to application complexity,
there are better solutions than PHP (though much more $$$$ to use and
probably slower)

My 2 cents.

Ophir

p.s.
Regarding MySQL breaking down, I do believe the problem was with
connections, not speed.
It just didn't hold up when trying to keep a few thousand simultaneous
connections to the MySQL server.
Oracle amazingly seems to do ok. It might slow down, but it doesn't
crash/die/freeze.

----- Original Message -----
From: "David Sklar" <sklar at sklar.com>
To: "NYPHP Talk" <talk at nyphp.org>
Sent: Thursday, October 10, 2002 10:26 AM
Subject: RE: [nycphp-talk] Scaling LAMP Architecture


> > From: Kyle Tuskey [mailto:ktuskey at exostream.com]
> > Sent: Thursday, October 10, 2002 12:20 AM
> >
> > You can scale LAMP (minus MySQL which is barely a database) to some
> > degree, but it isn't really the best way to approach it.  PHP was not
> > built to be an enterprise language.  The lack of the N-Tier model makes
> > it great for most sites, but true enterprise level needs would be better
> > approached with J2EE or .Net.  Using .Net or J2EE (Java) will make the
> > final solution much easier to use, manage, scale, and deploy.  Though
> > the word "enterprise" is thrown around too much and often isn't used
> > accurately, applications that truly are enterprise do need to take into
> > account a lot of the advantages of the N-Tier model.  PHP has XML-RPC to
> > all remote calls in a distributed architecture if I remember correctly,
> > but it isn't very efficient.  For instance, Java's RMI (Remote Method
> > Invocation) implementation is much more robust for this purpose.  If you
> > must use PHP for an enterprise solution, use a strong RDBMS (MySQL is
> > definitely not in this category) and some form of load balancing or
> > clustering as opposed to an attempted distributed architecture w/ PHP.
>
> So, Kyle, what is "true enterprise level," then? A billion pageviews per
> month? The 800B PV/month Ophir cited at CCI works out to about 300/second,
> and I presume that doesn't include images or other static objects.
>
> Tell me, where is the point that MySQL breaks down? Traffic?
Functionality?
> I admit, MySQL doesn't have, say, the World's Greatest parallel
hot-failover
> technology, but I don't think anyone would classify Oracle's efforts in
this
> regard in that way either.
>
> Don't get me wrong, I'm all for using the right tool for the job, and
MySQL
> or PHP or Linux or Apache aren't each the right tool for every job. But if
> you're going to insist that PHP or MySQL has problems, please point out
> actual problems, instead of vague assertions.
>
> Thanks,
>
> David
>
>
>
> --- Unsubscribe at http://nyphp.org/list ---
>
>
>
>