Re: CGIDEV2 performance versus Net.Data

["Nathan M. Andelin" <nandelin@xxxxxxxxxxxxxxxxxxx>]

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

> Nathan, although the amount of data is small, it could be
> argued that a small amount of data and simple processing
> is the best way to isolate the relative performance of the
> underlying methods.

Good point.  I think the benchmark offers an apples to apples comparison.
It's not that the data is bad.  It's just limited.
We need additional data that reflects a real-world scenario.

> Your web site's "shootout," compares net.data running in a named
> activation group (and your product running in a ??? activation group)
> to CGIDEV2 hobbled by running in a *new activation group.

Right.  Net.Data runs in a named group.  The Relational-Web version runs in
a *new activation group.  And at your recommendation, I just changed the
Easy400 version to use a named group and return without freeing resources.

> 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.

> 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.

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.

Thanks,

Nathan M. Andelin
www.relational-data.com