NYCPHP Meetup

[Edward Potter]

I think you can buy a pallete of Compaq's on eBay for probably next to 
nothing. Make a cluster + php +oracle or postgres, et al. That would be 
the cheap and easy way to do it. But if you have venture capital, you 
can wow them for months with whiteboards, arcane technical details, J2EE 
enterprise models, etc and stay on the payroll much longer!

-- ed


On Friday, October 11, 2002, at 11:23 AM, 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 ---
>
>