HP3000-L Archives

August 1996, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Kell <[log in to unmask]>
Reply To:
Jeff Kell <[log in to unmask]>
Date:
Fri, 2 Aug 1996 22:21:03 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (68 lines)
F. Alfredo Rego wrote:
> "Rudderow, Evan" <[log in to unmask]>> wrote:
> >"F. Alfredo Rego" <[log in to unmask]> wrote after Cecile Chi
> >>        How much does it cost me, in terms of hardware, software, gurus to
> >>        run the show, etc., to have a 100-user installation with an Oracle
> >>        or Sybase database (with all 100 users concurrently accessing
> >>        the same database)?
> >We recently started working on a new application here; it will have
> >approximately 50 concurrent users.
> You are half-way there, Evan, with your 50 users :-)
 
We have average 90 users on a 960 accessing around 2 dozen databases with
eighteen background jobs (daemon types) on a 192Mb 960; during peaks
(registration, fee payment, grades, and 14th-day statistics and state mandated
enrollment reporting) we have hit > 150 sessions, not including
finger/gopher/web servers reporting class availability and telnet (Eric
Schubert's NQTELNET) sessions doing online registration for students.
 
> >Anyway, I called an HP VAR whom we often work with (and who's got more than
> >a bit of Oracle experience) and asked them what kind of system we would
> >need.  Interestingly, they had just had another customer who implemented a
> >50 concurrent user oracle application; that customer had started with a
> >large HP9000 G series, but because of Oracle's performance characteristics
> >had been forced to upgrade to a 2-way K420 with gobs of memory and 22 GB of
> >disc on 11 spindles (in their case as well, it wasn't that they needed 22GB
> > -- they needed 11 spindles for the I/O concurrency).
> Ahem.  That's the whole point of this little discussion:
>         MPE Users Kick Butt!
 
There is a long-standing trend in computing for gobbling resources, but
generally you get more/better/faster/friendlier/robust gains for the expense,
and resource-intensive cute multimedia GUI point-and-click simplicity can be
justified if it simplifies life for the user.  But the unix DBMS arguments
don't have a clear "advantage" (IMHO) other than some add-ons (e.g., Oracle
Forms).  We should emphasize TPS/$ figures (if such were available for the
3000, but they aren't, and I don't expect them unless some 3rd party runs
them).  To play devil's advocate, we ran 64 users on a Series III, so the 3000
has it's appetite as well (MPE/V vs MPE/XL vs MPE/iX).  But there were clear
advantages for the extra resources.
 
> >I mentioned above that Oracle is our soon-to-be standard DBMS.  We're
> >supposed to be implementing Oracle's Fixed Assets within the next 6 months;
> >the requirements they gave us for the PC clients are:
> >     166Mhz Pentium
> >     256KB Burst Cache
> >     32MB memory
> >     2GB Hard Drive
 
That's more speed, memory, and disc capacity than our 64-user Series III had.
Think about that for a minute.  For bonus points, if you need that much
hardware for the "client" then what the heck is the "server" doing?
 
> >Luckily we'll only have 4 concurrent users for that application -- I figure
> >a 12-way T520 with 3.75GB ought to be able to handle the load...   ;-)
>
> Thanks, Evan.  Your last point is worth repeating, just in case some people
> missed it:
>
>         Luckily we'll only have 4 concurrent users for that
>         application -- I figure a 12-way T520 with 3.75GB
>         ought to be able to handle the load...   ;-)
>
> I rest mi case.
 
Su case es mi case :-)  [To paraphrase a Spanish saying]
 
Jeff Kell <[log in to unmask]>

ATOM RSS1 RSS2