Is 4000 users too high a number for filePro

[Fairlight]

The honourable and venerable Nancy Palmquist spoke thus:
> 
> I might consider a design that offers a web-based interface to filepro 
> for this kind of a system.

I agree that this is a -better- way to go.  I just don't buy your number as
one that will work adequately for him.

> Since all 4000 users would not actively issue a submit at the same 
> moment a 256 license or smaller might be sufficient.
> 
> If you think about it, if a record update process took 1 sec (most of 
> mine are less than that.) it would require 256 users to actively write 
> the data they are entering during that same second to exceed the limit.

Even assuming he used OneGate, which can "extend" a license a bit because
it has the lock/retry cycle that you can configure, you're -still- not
going to extend it more than a percentage.  This all depends on how long
each transaction takes.

But there's no way I would put it up there with only a 256 user license for
4000 users.  The odds highly favour someone getting shut out, even with a
lock delay.  If you said a 2000 user license--maybe even a 1000 user, okay,
I -might- believe it's tenable.  But 1/16 of the required amount?  That
doesn't seem credible no matter whose CGI engine they use.

Even -if- I redesigned OneGate to handle extended lengths of time for
retry longer than the 5min or so after which the browser and apache both
give up (I actually can't remember which gives up first...Ken Cole might
remember though, as he ran up against this), this not only defers things
for an unacceptably long cycle for most applications, it also just puts
off the inevitable for a few minutes, since if you hit that threshhold,
more requests are likely due to be inbound before you get to the backlogged
ones, and it will cascade into an overrun of the license count.

I'd think it should be at -least- half of the required count.  At least.
I'd prefer to see 3/4.  And this presupposes a CGI with retry, like OG.  A
solution that just gives you an error page immediately if the count is
currently in excess won't cut it (ie, forget fPCGI).

> A report on a large file, on a hot machine might take a few minutes, but 
> I would still expect the load balance to be well within limits.

And during that few minutes, a large percentage of the 15/16 could submit
requests.  Put another way:  If you have only 1/16th of your users running
long reports, the rest of your users are unable to use the system until the
others are done.  Even deferring only helps so much, and it decreases
proportionately the larger the difference between license count and
concurrent users, where the former is lower, and also decreases in
proportion to the average length of the transaction.

The -exact- statistical analysis is beyond my mathematical abilities to get
much closer than I already have demonstrated.  However, I wouldn't trust it
based on those numbers alone.  Too risky.

Whoa.  Better send this before I have to use vim's recover (PITA for
mail). Last lightning strike just de-sync'd DSL for 20 seconds.  Ugh.

mark->
-- 
          *****   Fairlight Consulting's Software Solutions   *****
OneGate Universal CGI Gateway:                  http://onegate.fairlite.com/
FairPay PayPal Integration Kit:                 http://fairpay.fairlite.com/
RawQuery B2B HTTP[S] Client & CGI Debugger:     http://rawquery.fairlite.com/
Lightmail Mail Sending Agent:                   http://lightmail.fairlite.com/
FairView Image Viewer for Integration:          http://fairview.fairlite.com/