Re: CGIDEV2 performance versus Net.Data

See inline comments.

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


"Nathan M. Andelin" wrote:

> > If you run your CGIDEV2 "shootout" program in a named activation
> > group and turn all debugging off (as previously discussed) and discard
> > the measurement on the first execution, I am sure you will find that
> > CGIDEV2 performance is more than competitive, probably in line
> > with the ratios in table 6.1.
>
> Pretty close.  The Easy400 version now uses only 80% more CPU than the
> Relational-Web version.  The Net.Data version uses 90% more CPU.

Where are you measuring Relational Web's CPU?  In the message server?  In the
application server(s)? Both?  It seems that both is what should be measured.
What about response time comparisons?  I suspect they are closer than the CPU
differences you report.  I don't doubt that a message-based server plug-in has
performance, resource utilization, and probably scalability advantages, but I'm
not convinced they are as great as you say.

>
> > On the other hand, your current "shootout" comparison, most likely
> > unintentionally, unfairly represents CGIDEV2 as a poor performer.
>
> > If you continue to use the "shootout" in your marketing, you owe it
> > to yourself, your customers, and your prospects to do it right.
>
> Named activation is not necessarily right.  And I think it's use is
> uncommon.  But I'll follow your recommendations.
>
> Named activation groups are a two-edged sword.  On the one side, the CGI
> program consumes much less CPU.  On the other hand, named activation can
> lead to programming problems and scalability issues.

With CGI, named activation groups are the only way to go because *NEW activation
groups have such heavy overhead.  IBM strongly says so in its documentation.  I
have discovered the same in more than 5 years of developing CGIDEV and CGIDEV2
and using them in performing contract work for customers.  Comments in the
newsgroups and mailing lists have consistently agreed.

A web site whose CGI programs are hit heavily will die a lot quicker if all its
CGIs run in *new activation groups.  The overhead is that heavy.

>
> To address the scalability issue, an example may illustrate.  Suppose that
> the HTTP server supports a busy dynamic Web site.  Suppose that CGI programs
> support a significant number of active concurrent users.  And suppose
> that a server hosts dozens, or even hundreds of CGI programs.  Under those
> conditions, over time, the HTTP server will launch several instances of
> every program in an attempt to scale to the demand.  Those instances never
> go away until the HTTP server is shutdown.  At some point, RAM memory
> usually becomes the limiting resource, IBM internal code kicks in to
> page and manage memory, and overall system performance degrades.
>
> I offer a solution that cuts the CPU time to almost half, and cuts the
> memory requirement to a small fraction, at a comparable load.
>

Some of my customers have combined CGI and a sockets server (available from the
iCTC) to make their sites faster and more scalable.  This is  similar to your
method in that the application logic is performed by never ending programs
running in the sockets server, either on the same or a different AS/400.
Instead of a server plug-in (which I think is an excellent idea), a small number
of CGI programs accept browser input,  send processing requests to the sockets
server, receive responses from the sockets server, and send  responses to the
browser.  This is extremely fast, extremely scalable, and, when the sockets
server runs on a different AS/400, extremely secure.

One of my customers is using this approach with only one CGI program to handle
all requests.  The CGI  accepts the browser's inputs and sends them to the
sockets server.  It doesn't even look at the variables or their values.  The
sockets server performs the application logic and sends substitution variables
and section (fragment) names, etc. to the CGI, which then writes those sections
(fragments) to the browser.  This is very fast, very slick, and the one CGI
program, once written, never has to be touched again.