Re: CGIDEV2 performance versus Net.Data

["Nathan M. Andelin" <nandelin@xxxxxxxxxxxxxxxxxxx>]

From: "Buck Calabro" <Buck.Calabro@commsoft.net>

>I thought that the server fired up different threads rather
> than different jobs.  I have a question and a statement.

In my last post I inadvertently referred to the HTTP Server BCH Job as the
BCI Job, and visa versa.  I hope it didn't cause too much confusion.  Now
that I'm looking at the WRKACTJOB display, I see that the main HTTP Server
instance is the BCH job, and the Jobs that run CGI programs are type BCI.

Option 5 (WRKJOB) enables me to see the active threads.  The BCH Job has 46
active threads.  The BCI Jobs run one (1) thread each.

When people say that the HTTP Server is a multi-threaded program, they're
referring to the BCH Job.  The point being that separate single threaded
Jobs are used to handle CGI requests.

Actually it appears that a thread in the BCH job handles the communication
with the browser, while a BCI job is used to call the CGI program, which
generates a response.

> First the statement: Activation groups work WITHIN jobs,
> not across them. If the server really fires up 40 different jobs,
> the programs in AG(CGI) do not share storage, etc across
> those 40 jobs.  The point being that *NEW or named have no
> bearing on the machine IF it creates multiple jobs for load
> balancing.

Right.  That's pretty clear.  But programs are activated within Jobs.  My
point was that our 100 CGI programs could be active in each one of the 40
BCI Jobs.  Hence 4,000 program activations.

> The question: Do named AGs share storage across threads?
>  I'll try to find the references myself when I get a chance to hit
> the internet again later today, but I haven't got the practical
> experience (only small tests; no heavy volume.)

It's likely.  That's why thread synchronization is so important.  Each
thread runs the same logic and references the same memory.  People who write
multi-threaded programs implement synchronization strategies to prevent more
than one thread from changing shared memory until after the active thread
completes it's line of execution and returns to a wait state.

Nathan M. Andelin
www.relational-data.com