[nycphp-talk] Scaling LAMP Architecture
chalu
chalu at egenius.com
Fri Oct 11 12:15:04 EDT 2002
I think you are hitting close to the basic point of "scalable".
Lot of folks worry about "scalabe" because you may not have the
experience of making your system scalable. Having designed many of
"scalable" systems and lived with them, there are a lot of assumptions
one makes. Fail-over and redundant design.... Replication.. 2-tier vs
4-tier. What is different about 4-tier vs SDDS? Just different jargon.
Lot of developers would throw lot of these technologies without having
configured themselves. Having a hot-failover system configured is very
elaborate. You need to worry about things as basic as ARP table and
configuring multipath RAID subsystem. Lot of things have gotten easier
over the years. But I still see many MCSE walking around with a clue of
how to use ARP. I have seen only few "scalable" systems over the years
serving the business owners. It is often "tail wagging the dog" as in we
tend to use technology as an escape hatch.
I remember seeing architectures of the world's busiest sites and the
biggest e-commerce sites. Then, I remember being impressed of
master-slave database servers. Absolutely the textbook case from
Microsoft land! Over the years, my longview reveals gigantic mistakes of
these architectures. Techies' idea of "scalable" does not scale business
or the use.
Nowadays, I am impressed by those architectures balancing different
objectives such as speed, flexibility and good common-sense of making
usable systems.
One of the folks mentioned "communityconnect". Here is a good example of
people who scaled to large traffic. For example, think of problem having
to serve so many images including resolving multiple includes of banners
from different web-sites. It is normal to gain most speed improvement
from programming practices like improving your database design and using
index tables.
A well know moutain climber said, "It is not the equipment, it is how
you use it."..... If you can scale ASP and MS SQL and run some large
sites, you can do it with PHP and MySQL. ditto.
Anirudh Zala wrote:
>Hi all :)
>
>Thank you for all of yours opinions and suggestions. All have given better
>solution for this problem as they could, and we know this problem can have
>many solutions, and finally depends upon person or company who is going to
>use and in which manner bcoz as it question of $ too J
>
>some of you have suggested using LAMP, or LAOP or LAPgP or .NeT or j2EE and
>many more but still problem remains same. What's correct definition of
>"Scalable" system or architecture?
>
>Well if it's just question of having such a system which can run with same
>speed and efficiency even when total hits increase from 1000 to 1 million,
>or having all above advantages plus having all enterprise features. etc then
>here we r mistaking all. There is no any solution, which can provide all of
>these advantages simultaneously and in which way we need.
>
>So we have to find better rather than best. Here my suggestion is whatever
>tech. is used, it must be able to satisfy the owner and those who r going to
>use. Here "Satisfy" is in general terms, so whatever u think would be ok..
>
>So main thing is not to talk advantages and disadvantage of any existing
>tech. likes comparison btwn MySql and Oracle or PHP and jSp or MsSql vs.
>PgSql or whatever, instead we need to think in diff direction like using
>concept of SDDS
>Scalable Distributed Database Server and/or Multiprocessing where client
>requests are divided into small parts or are redirected to other servers or
>processor thus keeping main server or processor less burdened.
>
>In SDDS, Data and Files are kept on several machines rather than same server
>or 2 servers (i mean many companies use db server and scripting/file server
>as separate to get better output and faster execution). This tech is also
>known as
>Client-Agent-Server tech. where u can say there is 1 main server where all
>data is kept and at second level there comes Agents machines/servers
>interacts btwn main server and client. All client servers has replica of
>main servers DB but in diff parts not as whole db so like 4 servers with 25%
>and almost all clients queries are first directed to this Agents only and
>replied/executed by these 4 servers and if needed they are redirected to
>main server and finally records btwn main server and agent servers are
>updated.
>
>This is similar like concept of cache servers in Oracle and Java but this is
>bit new and different. The main diff is all Agent servers acts like as they
>are main servers so at client end u never know where your request is being
>redirected or which server your data is coming from?
>
>This is like a concept of having chain store where u have McDonald's fast
>food available at New York, Syracuse and Seattle rather than all have to go
>to New York only whether u live in Syracuse or Seattle. I hope u all r
>getting what I mean.
>
>So main point is whatever tech (Db, Scripting lang, Servers OS u use) your
>software must have Strong RDBMS, Proper coding style, Robust architecture
>maybe using SDDS tech. an other normal stuffs.
>
>These concept can give u satisfactory solutions, otherwise there is no such
>tech. in this world which can give u all at once without having Distributed
>Database and/or multiprocessing. Also PHP guys will say PHP is best, ASP
>will say ASP is the best bcoz it has these facilities, same with DB and OS,
>ok ok we need to think in diff direction and develop something new using
>existing tech :) not just adhering to existing tools.
>
>Thanks All,
>
>Anirudh Zala
>(Globalwebwise INDIA)
>
>
>
>
>>From: "Ophir Prusak" <prutwo at onebox.com>
>>Reply-To: talk at nyphp.org
>>To: NYPHP Talk <talk at nyphp.org>
>>Subject: Re: [nycphp-talk] Scaling LAMP Architecture
>>Date: Thu, 10 Oct 2002 11:06:11 -0400
>>Received: from mc5-f22.law1.hotmail.com ([65.54.252.29]) by
>>mc5-s15.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 10 Oct
>>2002 09:50:32 -0700
>>Received: from parsec.nyphp.org ([66.250.54.138]) by
>>mc5-f22.law1.hotmail.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 10 Oct
>>2002 08:16:52 -0700
>>Received: from nyphp.org (parsec.nyphp.org [66.250.54.138])by
>>parsec.nyphp.org (8.12.3/8.12.3) with ESMTP id g9AF6Bix055705;Thu, 10 Oct
>>2002 11:06:11 -0400 (EDT)(envelope-from listmaster at nyphp.org)
>>Message-Id: <200210101506.g9AF6Bix055705 at parsec.nyphp.org>
>>X-Paralist-Archived:
>><http://nyphp.org/list/paralist_archive.php?L_mid=1348>
>>X-List-Software: Paralist 0.6
>>List-ID: <nyphptalk.nyphp.org>
>>List-Owner: <mailto:listmaster at nyphp.org>
>>List-Archive: <http://nyphp.org/list/paralist_archive.php?L_lid=1>
>>List-Subscribe: <http://nyphp.org/list/>
>>List-Unsubscribe: <http://nyphp.org/list/>
>>Organization: New York PHP
>>X-Mailer: Paramail 0.5
>>Return-Path: listmaster at nyphp.org
>>X-OriginalArrivalTime: 10 Oct 2002 15:16:52.0625 (UTC)
>>FILETIME=[0FF66810:01C27070]
>>
>>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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>
>_________________________________________________________________
>MSN Photos is the easiest way to share and print your photos:
>http://photos.msn.com/support/worldwide.aspx
>
>
>
>--- Unsubscribe at http://nyphp.org/list ---
>
>
>
>
>
--
Chalu Kim
eGENIUS
20 Jay Street, 1002
Brooklyn, New York 11201
chalu at egenius.com
(718) 858-0142
(718) 858-2434 FAX
www.egenius.com
More information about the talk
mailing list