× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



That isn't at all a very good picture. You can easily achieve very high 
transaction rates on
both PC and UNIX systems running off a very limited DASD volumes. Amazingly 
enough,
there are a LOT of other factors that mitigate the impact of DASD - including 
the fact
that PC's and UNIX systems can and do use raid disk arrays that are much less
expensive than similar arrangements on S/390 or AS400 systems.

They loose when it comes to plain old fashioned indexed file operations for 
exactly the
reason you mention, but the big guy database systems, in particular DB/2 & 
Oracle
perform very very well  - when they are designed correctly. As in sub-second 
response
on transactions. And yes, 'selects' take a while when they return a large 
number of records;
so does selecting and returning a large number of records out of a typical 
indexed file
as well.


-Paul

----- Original Message -----
From: "Syd Nicholson" <sydnic@ccs400.com>
To: <midrange-l@midrange.com>
Sent: Wednesday, May 01, 2002 12:01 PM
Subject: Re: iSeries Disk Pricing


> On PC based servers the data base is often located on a single disk. If one
> has an SQL server database, the entire database is usually installed on one
> single DASD. At best, a PC data base can only serve one user at a time, all
> other users must join the queue.
>
> On the iSeries, with data spread over multiple disks this limitation does not
> apply. An iSeries should easily out perform any equivalent PC database server.
> The number of disk arms in this situation is extremely important.
>
> It is not unusual for PC DB servers to run like a dog unless very fast drives,
> powerful CPUs, extra memory for caching, etc, etc is present. Many companies,
> including those that develop these PC systems, just don't realize the
> implications of scale. That which works perfectly in a test environment,
> performs abysmally, or dies when put in the real environment because the
> system is unable to handle the load. This is where the iSeries wins and
> Windows based systems fail.
>
> The iSeries has the advantage of scalability and stability, and the number of
> disk arms is part of this equation. Whether a PC DB has 10 users, or 10,000
> users it cannot go any faster by adding more CPU power, or memory if the rate
> limiting factor is how fast it gets data from a single disk. Overload it and
> it dies, and probably the network with it with devices timing out all over the
> place.
>
> Syd Nicholson
>
>
>
>
> >
> > > Subject: RE: iSeries Disk Pricing
> > >
> > > This is a multipart message in MIME format.
> > > --
> > > [ Picked text/plain from multipart/alternative ]
> > > Everybody keeps chanting the arms mantra as if a bank of original 10mb
> > IBM
> > > PC hard drives would out perform a 8gb iSeries drive.  I argue that if
> > > they keep improving all of the other performance metrics of drives
> > then
> > > you may not need as many arms for the same amount of data.
> > >
> > > Rob Berendt
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.