RE: CGIDEV2 performance versus Net.Data

These are neat ideas, especially the socket server. But I don't understand
how a socket server improves performance, I can't picture the
architecture...

Traditional CGI:

1. web browser request is sent to
2. http server, which calls
3. custom CGI program, which generates output back to
4. HTTP server, which sends the page to
5. web browser

So I can see that each time the CGI program is called, there is a lot of
activation overhead, unless you're in named activation groups and returning
with LR off (if using RPG).

Based on your comments, I picture the process as this:

1. web browser request is sent to
2. http server, which calls
3. "generic" CGI program, which sends requests to
3a. socket server, which evaluates the request and calls a
3b. custom CGI program to generate the response ??? back to
3c. the socket server, forwards the response to ???
3d. the generic CGI, back to ???
4. HTTP server, which sends the page to
5. web browser

I guess I fail to see where the performance benefits occur. Is 3a a
neverending socket server job? Is 3c a thread program in the 3a job, or is
3c a full program job call by 3a? For the typical pages we process (reading
realtime from databases), somewhere file opens and initialization takes
place. I can imagine a single request taking a little longer, due to more
program calls.

Our AS/400 is not connected to the internet, and probably won't be (at least
directly). We do have a requirement to develop  inquiries for our suppliers
to see vendor rating/supplier assessment information, but those requests
will probably be funneled through a corporate portal. Since we're doing
traditional CGI, with CGIDEV2 and e-RPG, it would be interesting to know how
other solutions work and tie together.

Are there any white papers or FAQs for understanding the architectural
differences between traditional CGI and message/data queue/socket server
based approaches to web requests?

Loyd


-----Original Message-----
From: Mel Rothman [mailto:mel@rothmanweb.com]
Sent: Thursday, October 04, 2001 8:49 PM
To: midrange-l@midrange.com
Subject: Re: CGIDEV2 performance versus Net.Data

<snip>

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.

<snip>

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