Justtechjobs.com Find a programming school near you






Online Campus Both


php3-list | 2000051

Re: [PHP3] oracle and PHP From: Ron Chmara (ron <email protected>)
Date: 05/06/00

Arthur wrote:
> RL:
> >I'm a little flabberfasted that you have $250,000 to spend but don't need
> >transactions and subselects, but hey, what do I know?
> Thanks for the info. Sorry for not being more clear. I was wondering if
> anyone had experience with Oracle + Oracle App Server versus Oracle + PHP4.
> I'm not the one who has 250K to donate to Oracle, and I'm just as
> flabbergasted at the intended use of such a budget. It's a company which
> has a DB with about 1 million rows in one table and a few thousand in say 3
> others, and they need to do multiple table joins to generate search
> results.

So, if they're text records <1024 chars, it's a *really* tiny db right now.

> Hit-rate is not known at this stage as they're still in dev. They
> *may* get into e-commerce later, but I see no need to use Oracle/Oracle App
> Server until they get to that stage. By the time they do it, 250K will buy
> a bigger box even from Sun.

Exactly. Moore's law pretty much means that platform investments are only
good for 18 months at most. Add in the fact that your first system will be
wrong (Brooke's Law), and you don't really _want_ to throw the entire
ball of wax into one investment, one company, until you know exactly what
you need, and how you need to do it.

> My question is: cost aside,
> does PHP4 + MySQL actually perform as well or better than Oracle + Oracle
> App Server when the task is simple and does not require transactions and
> subselects.

When the task is simple, yes. MySQL excels at smallish, flattish, high speed
transactions. You cannot have the same kind of design as you would be able
to have with Oracle. You will, however, have faster, tighter, design....

> When a DB like this does get massive hits, will PHP4 + MySQL
> scale well when a more powerful box is used?

Up to parallel, yes. Then you want to have a two tier (PHP box,
MySQL box) system. Assuming you're using cheapie boxes, (as compared
to Oracle on Sun), you can do thousands of hits a second on off the shelf
dual X86 CPU's, with 512 Mb of RAM, on *nix. As long as you have
really tiny transactions, in the right table design, almost any db
app can be designed to handle that transaction level.

On NT, well, you've got a bit more overhead there, but even a 600Mhz
machine running IIS can take thousands of hits a second.... the usual
bottleneck is _not_ the CPU, it'a the bandwidth of the site, the actual
internet connection. Here, I'll put it this way: If you have a tiny webpage,
say, ten 12KByte graphics, another 4 KByte of text, you have a 124KB site. To
send that over the net a thousand times in one second, you need a Gigabit
LAN connection. That's 1,024,000 KB per second from two NICs, or
a 1 GB internet link. Or, put another way, since a T-1 will drive 1.544
Megabits, or .193 MegaBytes per second, you'll need, oh, 5305 T-1's.

Er.. I doubted my math, so crunch it yourself. See how much of
your problem needs to be fixed by _redundant_, _mirroring_ db's
and servers, vs a "big box" somewhere. This is why there are db's
with powerful replication, so there can be a server hanging off of
each major backbone. This is where the high cost db's count in
web serving, in *replication* to reduce overall site costs. Try
calling your ISP and asking for 5305 T-1's. :-) That's what you
need to send out that much per second in web pages, after your
transactions. ...

So, here's another way to ask the question: How much of the db cost
is for redundancy and replication features? And how long do you think
it'll be before your site has 327,200 page views, every day? That's
how many site visits it takes to hit 1000 per second to the above pages.

-Bop 

--
Brought to you from iBop the iMac, a MacOS, Win95, LinuxPPC machine,
which is currently in MacOS land.  Your bopping may vary.

-- 
PHP 3 Mailing List <http://www.php.net/>
To unsubscribe, send an empty message to php3-unsubscribe <email protected>
To subscribe to the digest, e-mail: php3-digest-subscribe <email protected>
To search the mailing list archive, go to: http://www.php.net/mailsearch.php3
To contact the list administrators, e-mail: php-list-admin <email protected>