FilePro running on Unix vs Windows

[Bill Vermillion]

In the last exciting episode of the filePro saga, 
Mike Schwartz-PC Support & Services was heard to say:" 
if: Wed, Dec 15 18:24  
then: nm = Mike Schwartz-PC Support & Services 
if:
then: show nm < "said:"  
Mike Schwartz-PC Support & Services said: 

> > My company, Floors, Inc. has asked me to research the
> > possibility of us moving our system to a Windows based
> > network platform.

> Hi Cindy!

>  Bill Campbell already addressed the folly of running mission
> critical database apps on a Windows computer, so I won't go
> into those issues, except to say that I agree.

>  From a performance standpoint, since Filepro does not run
> as a server based application in a Windows environment, your
> applications will simply die on a Windows Server network.

>  Let me explain. Suppose you have a 10,000 record master order
> database and you need to scan all the records to find the
> orders from Wisconsin. On a Unix computer, the 10,000 records
> are examined in seconds because they only have to be moved from
> the hard drive to the RAM memory to be examined, and then only
> a few bytes of data has to be sent across your network lines
> and to your workstation, so that you can see which records were
> selected on your screen.

>  However, on a Windows network, all 10,000 records in their
> entirety have to be dragged across your network cables and into
> your own workstation so that your workstation can examine all
> the fields in each order to determine whether or not the order
> should be selected. I've seen situations where a couple of
> users doing scans for data can bring a 100 MBPS network down to
> its knees.

>  In one example, a company had a bunch of night reports that
> took about an hour to generate on a 386 Xenix computer. A
> Windows geek convinced the company that they should purchase
> the Windows version of filePro, so that they could get rid of
> the Xenix computer. They did the conversion, but, even though
> this was a "new" Pentium computer (circa 1998) with lots of
> ram and Windows NT 4.0 on it, the reports ran so slowly when
> executed from a workstation that they weren't done on Monday
> morning!!!

And older example here when TPTB said "Windows is king - Unix shall
go"

The first time a major report was run I was called to see why
things were so slow.   So instead of running reports that took
forever, I generated them to the local machine, and then when that
was done sent the finished report back to the network.

That cut the report generation time to 1/4 of what it was set up
originally.  However this was still about 5 times longer than the
Unix system.

Then the printing time going from the local machine back to the
network was cut by about 1/2.

So in the end the entire process took only 4 hours as opposed to 8.
But originally the local machine was tied up for 8 hours - and now
it was tied up for only about 30 minutes - and then 4 hours to
print.

Everyone who did any significant work wanted the unix system back
because it was easily 4-6 times faster on hardware that was less
than 1/2 as powerful.

A lot has to do with the design of the systems and the Unix systems
did have SCSI drives.  In modern systems the normm seems to be
for IDE - as people think they are fast enough.     The problem
is that so many of the MS type systems still don't have intelligent
file handling and IDE exacerbates that.

In SCSI you have TCQ - tagged command queing - which means the
drives handle data in the most logical order.

Of the current SATA drives extant at the moment only two of which
I'm aware have TCQ in IDE.  This is a first as most of the SATA
drives use a PATA to SATA tranlastion on the drive.

TCQ - Tagged command queing - means the HD itself can store and
sort command to perform them in the most efficient order.  Without
this the instructions to the drive are handled in the order in
which they are received.

In single user system this really isn't a problme but the more
users you have the more of a bottleneck this becomes.

A phrase that used to be used to describe these actions is
'elevator seek' because the HD acts just like an elevator.

You put 20 people on and the elevator stops at each floor along the
way.  But if you take the method an IDE drive uses, if people got
on the elevator and punched in floors 20, 7, 13, 2, 18, 5, and 11,
the elevator would first go to floor 20 and let off one person,
then go down to the 7th  floor to let off another, up to 13 to let
off yet another, back to floor 2, then up to 18, back to 5, and
finally go to 11.

While not database oriented maybe this example can give you an
idea.  A friend owns a hardware/software support company and is
primarily an MS shop.  When one client moved their mail
from Unix [first a Sun and later a BSD] to a Microsoft server
I found out that MS recommended [according to him] one server
for each 500 mail clients.  Simlar hardware running Unix systems
don't have problems until you get past about 20,000.

So you may not notice a big performance hit with high powered
systems running 20 or so users, but I think the move from
Unix to MS with 250 users would be quite noticeable.

>  The reports eventually locked up the entire network by
> Tuesday, and never did entirely finish. After I came into the
> picture and switched them back over to a Pentium SCO Unix box,
> the end-of-day reports ran in under 5 minutes. (True Side note:
> The Windows Geek headed to Las Vegas to become a dealer after
> this blunder, and several other blunders involving their Novell
> setup...)

If he is that inept with computers, would you mind telling us
where he's dealing in LV.  It might be a winning table.

Bill
-- 
Bill Vermillion - bv @ wjv . com