Rapid once deployed too

[Fairlight]

Y'all catch dis heeyah?  Howie been jivin' 'bout like:
> FYI:
> 
> Aside from rapid development, filePro runs incredibly quickly in real world
> environments too:
> 
> Here are the current runtime statistics at Aljex right now:
> 
> 247 users,  load average: 0.14, 0.11, 0.14
> 
> and the # of users running *clerk
> 
> # ps -edalf | grep clerk | wc -l
>     226
> 
> and 2 users running reports:
> 
> # ps -edalf | grep report | wc -l
>       2
> 
> on a duel cpu server with fast drives 

Okay, no offense Howie, but here's how the (what we in the gaming community
call) "d**ksize wars" begin.  People come in with half-baked benchmarks and
claim SCREAMING performance.  A good deal of the time, the results aren't
even applicable because the basic premise is SO fouled that it's just not
even remotely tennable.

Tell me this:  Of those 228 processes running, how many are listed as being
in sleep mode in the process table? 

I thought so.

Subtract every process that's flagged with an S and you have how many of
them are -actually- doing anything.  I'd be surprised if there's even one
left, given a combined load below 0.5 on a 2-cpu system.  The system is
almost completely nascent.

Given a load of 0.14, I take an educated guess they're almost all in sleep
mode, as load average is supposed to be an estimate of how many processes
are in contention for CPU use.  On a dual-CPU machine, your actual load
would be 0.14 / 2 for a single CPU.  If you have a load that small (0.07),
the processes sitting on that chip are barely even doing anything at
all...mostly idling.  People may be typing, but there's so much CPU cycle
space between keystrokes it's not funny--even with 300 people typing at
once.  Geez, we used to be able to pull it off on a 40MHz UNISYS.

Start a rebuild of a single index that'll take a while and watch your load
spike and maintain that spike for the duration of its runtime.  It should
go to 1.14 or higher from the same state on a single CPU.  On a dual-cpu,
I'd expect a -possibility- of it staying below 1.0 if the load average is a
combined average.  Maybe 0.67, but in reality only one CPU would take the
full hit of the process load, since fP is single-threaded.

Unless you can show me a combined output where processes are -NOT- in
sleep mode (say, a paste from 'top'), and your load is that low (not
possible), the basis of your claim is pretty much meaningless.  It is
simply not possible to have even one process actually -doing- something
computationally and keep the load that low.  That's a totally false metric
you're looking at.  Most of those are *clerk sessions, and unless you're
using WAITKEY, which goes into a polling loop and should suck up whatever
percentage of a single CPU is free, most of those processes are in sleep
probably 90%+ of the time because frankly people type a -lot- slower than a
CPU can run.

Start rebuilding 10 or even 5 indexes at the same time and tell me what
your load average is with those concurrent rebuilds.  I'm wagering it's
either 2.07 or 5.14, give or take, depending how the CPU balancing goes.
Actually one should be 2.x and the other 3.x, accounting for five
threads--you can't symmetrically balance an odd number of threads.

Nobody that understands how uptimes actually work would actually ever make
this claim -based on the evidence used-.  I'm not saying fP isn't fast, I'm
saying your benchmark criterion is seriously, seriously flawed.

Again, no offense.  It's just an almost entirely invalid metric you're
using to prop up your claim.  About the only thing this tells -me- is that
fP sleeps whenever it possibly can, and is efficient about doing it at the
soonest possible breakpoint.  Seeing as keyboard input in blocking mode
is basically a sleep situation, that's not really complex to achieve (no
offense to the fP dev team, it's how systems work, period).

mark->