Re: CGIDEV2 performance versus Net.Data

[Mel Rothman <mel@xxxxxxxxxxxxxx>]

Yes, CGI programs running in named activation groups don't return their
resources to the system when they return.  That's the way they are supposed to
work.  That is a really a tremendous performance advantage for frequently run
CGI programs.  The alternative of running frequently used CGI programs in *new
activation groups is totally unacceptable for performance because creating and
destroying activation groups over and over again is really, really expensive.

As Leif points out, what's really being used is virtual memory.  The only time
this is a problem is when activity gets so high that excessive paging occurs.
As previously pointed out, this can and should be controlled by throttling the
server.  If the load is still too high (too many requesters being queued), then
it's time to get more system resources (memory, dasd, processor(s), etc.) and/or
improve the site's design.

Regarding design:
- many CGI programs can and should be replaced by static pages
- many CGI programs can be combined into fewer CGI programs
- multiple CGI programs can run in the same named activation group.
- infrequently used CGI programs can run in *NEW activation groups.  Since they
are not used often, the performance hit of creating and destroying the
activation group is not a big deal.
- a more difficult but very fast and efficient  as previously mentioned, is a
single CGI program that   - accepts browser inputs without examining them,
  - sends the inputs to a sockets server running application logic on the same
or different AS/400,
  - receives from the sockets server the output variables and HTML section
names, and
  - sends the HTML to the browser.

With this last scenario, every CGI server job runs only one program in one
activation group.  This is similar to your approach except that multiple CGI
programs are used instead of a multi-threaded server plug-in and communications
to the back end is via sockets instead of data queues.  It's not clear whether
you approach supports a remote application server.  I have experience with
back-end application servers communicating to CGIs through sockets and know they
are very fast and efficient.  In theory, your approach should be fast and
efficient too.

It appears that you are trying to prove that CGI doesn't scale well.  My view is
that web serving  with the AS/400 - iSeries architecture scales very well, no
matter whether using CGIs, Net.Data, or Websphere Application Server (WAS).  Of
these three, on low-end boxes, CGI and Net.Data scale best because WAS needs
more than a low-end box just to run.  On high-end boxes, Websphere Application
Server scales best, but all can scale more than well enough.

With all three, it's not hard to lose scalability and performance with lousy
designs and implementations.  On the other hand, all three can provide
acceptable, if not excellent, performance and scalability given decent designs
and implementations.


Mel Rothman
CGIDEV2 Author
IBM eServer iSeries Custom Technology Center (iCTC)
Rochester, Minnesota





"Nathan M. Andelin" wrote:
>
> From: "Leif Svalgaard" <leif@attglobal.net>
> > > It seems to me that running a CGI program in named activation group is
> akin
> > > to returning to a menu from a 5250 program without ever closing it's
> files
> > > or deallocating it's memory.
> >
> > Don't forget that (at least with the OPM) that that is the default
> behavior.
>
> "If many ILE RPG programs are activated (that is called at least once)
> system storage may be exhausted. Therefore, you should avoid having
> ILE programs that use large amounts of static storage run in the OPM
> default activation group, since the storage will not be reclaimed until the
> job ends."
>
> Quoted from ILE RPG Programming Guide.
>
> > >  Will that scale as the number of interactive Jobs increase?
> >
>
> > I'm not quite sure what you mean? is a GCI-job interactive?
>
> No, I was just drawing a parallel between how CGI programs are called from
> an HTTP Server Job, and how 5250 programs are called from the command line.
> When the CGI program runs in a named activation group, the resources it
> allocates are scoped to the HTTP Server Job that called it.  They are not
> reclaimed when the program ends.  So the activation of a lot of CGI programs
> will exhaust RAM (CGI programs generally use a lot of memory, and other
> resources).
>
> As far as scalability is concerned, I suppose it depends on the amount of
> RAM the box has?
>
> Nathan M. Andelin
> www.relational-data.com