NYCPHP Meetup

[Anirudh Zala]

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
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>--- Unsubscribe at http://nyphp.org/list ---




_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx