Re: CGIDEV2 performance versus Net.Data -- MIDRANGE-L

Mel,

What a pleasant surprise to hear from you.  I sometimes wonder whether
anyone reads my posts <smiling>.  I respect the work you and Giovanni have
done on the Easy400 product and Web site.  It's refreshing to hear IBM
promoting something other than Websphere for Web development.

I apologize in advance for my lengthy response.

From: "Mel Rothman" <mel@rothmanweb.com>

> Nathan, it appears that your CGIDEV2 sample code
> is returning with LR on.  Based on your notes, it also appears
> not to be running in a named activation group.  If so, this puts
> CGIDEV2 at a significant,  unnecessary, and unfair disadvantage.

My Easy400 CGI program does turn on the LR indicator.  And it runs in a new
activation group.  After consulting with several other CGI programmers, I
concluded that this was more common.  But maybe we can learn something from
your experience.

The folks I talked to felt uncomfortable about coding and running CGI
programs that never freed memory and other resources they used.

I recently questioned a Java expert's claim that CGI programs don't scale
well.  I used the logic that the mechanics were in place to start more
instances of CGI jobs as the number of concurrent users increased.  But I
wondered if system resources might become exhausted over a period of time if
a large enough number of programs ran and never freed the resources they
used?

My Java friend pointed out that Threads use less system resources than Jobs.
And that many of the same resources are shared across multiple threads.
What about Jobs that never free resources?  From your point of view, should
most CGI programs run in a named activation group, and return without
freeing resources?  Or should that technique be reserved for special
circumstances?

BTW, given the multithreaded design of Servlets, would you have any
references that refute a Java programmer's claim that CGI doesn't scale
well?

> It can be made even faster by turning off all debugging output
> by running the SetNoDebug(*on) subprocedure.

I added this call to my Easy400 CGI program and found that it significantly
improved the performance.  I'll report the results after I get a chance to
tweak the Net.Data and Relational-Web versions.  The generation of the HTML
was where most of the CPU time was spent.

> Perhaps your observation occurred because your program
> is spending a significant portion of its time in the dbReport
> subprocedure (or program), thus masking CGIDEV2's
> performance improvements on the second and subsequent
> executions.

No.  The same dbReport() procedure is called by each of the versions.  The
file is opened with each call.  The time it takes to perform it's logic is
not significant.  All three versions of the application spend most of their
time in the loop that generates the HTML table.

> I would guess that CGIDEV2 programs that are properly
> written for performance would significantly outperform similar
> Net.Data macros, especially when there is significant procedural
> logic as opposed to simple set operations.

Got any references to point to?

> Also, note, that the current CGIDEV2 version supports multiple
> HTML files (up to 127) in the IFS.

OK.  I'll make a note of that.

Thanks again,

Nathan M. Andelin
www.relational-data.com


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