Re: performance of cgi-interactive programs -- WEB400

Hi Simon,

My understanding is that "persistent connections" and "persistent CGI" are
two separate and distinct things.  Persistent connections keeps a socket
open, and an HTTP server thread locked, but any CGI request from any browser
may be routed to any one of the BCI jobs for processing.  In contrast,
Persistent CGI establishes a single channel of communication between one
client and one active CGI program for the purpose of maintaining client
state.

My comments about the number of CGI activations pertained to the use of
persistent connections, combined with named activation.  Named activation is
a requirement for interactive CGI.  Otherwise, program initialization nearly
immediately leads to terrible performance.  With named activation, the only
way to deactivate a CGI program is to shut down the entire HTTP server.

What happens when a busy site uses both persistent connections and runs all
CGI programs under one (or more) shared activation group?  The HTTP Server
routes new CGI requests to the next available BCI job for processing.  If
all the BCI jobs are busy at the moment, a new BCI job is started.  The
CHGHTTPA command is used to specify the number of HTTP server threads, and
consequently, the maximum number of BCI jobs to start.

The HTTP Server's non-discriminate method of routing eventually leads to
each one of the BCI jobs having an active instance of each one of the CGI
programs.  40 BCI Jobs times 40 CGI programs = 1600 active CGI instances.

To test this, you might download the JMeter stress test tool from
www.apache.org, run some CGI programs under a shared activation group, then
use WRKJOB to view activation groups, allocated resources, open files, etc.
for each one of the HTTP Server BCI Jobs.

Try to integrate a healthy number of CGI programs, with a healthy number of
HTTP Server threads, and persistent connections, and it becomes a challenge
to tune performance.  This architecture will never be a good alternative to
5250.  Imagine an ERP system consisting of, say 500 hundred CGI programs,
and 100 active users.  That could lead to 50,000 active programs for the OS
to manage!

Nathan M. Andelin
www.relational-data.com

From: "Simon Coulter" <shc@flybynight.com.au>
> Hello Nathan,
>
> You wrote:
> > To support 40 concurrent users, you probably need at least 40 HTTP
Server
> >threads.  However, that may lead to 40 active BCI jobs.  Each one of
those
> >jobs could activate your 40 CGI programs.  That could lead to 1600 CGI
> >activations if the CGI programs run under a named activation group.  1600
> >active CGI instances may put a burden on OS/400 memory management.
>
> Surely that's only the case if you put each CGI program in its own named
> activation group?  If the CGI programs are part of the same application
why
> would they not be in the same activation group?  Thus one activation group
> per BCI job.  That should be manageable on any size AS/400.
>
> Persistent CGI requires named activation groups -- not that the names be
> different.
>
> Regards,
> Simon Coulter.