counting concurrent users...need advice.

[Fairlight]

Yo, homey, in case you don' be listenin', Jay Ashworth done said:
> On Fri, Aug 27, 2004 at 09:21:55PM -0400, Fairlight wrote:
> > On Fri, Aug 27, 2004 at 09:08:50PM -0400, Bob Stockler may or may not have
> > proven themselves an utter git by pronouncing:
> > > I thought you were looking for something that would run for
> > > just a litte while to tell one how many user licenses to buy.
> > 
> > Well, no, not really.  :)  More a case of, "We already have 'x' licenses,
> > spread across two or three clustered web servers.  Now, at any given point,
> > what is the maximum count taken on each server, and what -is- that count.
> > And when do those peak periods occur?"
> 
> I believe the proper solution is to make /appl/fp/dclerk and
> /appl/fp/dreport shell scripts which increment semaphores, call the
> binary and then decrement the semaphore.  It'll double your process
> table size, but that's trivial.

Didn't like the idea I presented privately, eh?  Curious why...

Mine also saves on the RAM used in all those extra processes.  RAM is
cheap, but I don't see a reason to throw it out the window, either.  At
1.8MB per instance of bash (tested, SuSE Pro 9.0), on a 32-user license
alone, that's 32MB in wasted RAM/swap.  It's not the process table I'd be
worried about so much as memory.

Additionally, you could get a race condition on semaphores unless you
did them very, very specifically, using facilities bash and bourne
(and probably ksh) don't even provide.  I didn't think my solution was
vulnerable to that due to the mechanism I used to ensure it.  It's as close
to safe as possible without rolling the code into fP's licensing core
itself.

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html