FW: CGIDEV2 performance versus Net.Data

-----Original Message-----
From: Joel R. Cochran
Sent: Wednesday, October 03, 2001 4:54 PM
To: 'nandelin@relational-data.com'
Subject: RE: CGIDEV2 performance versus Net.Data


Hey Nathan,

I know that we have exchanged many e-mails in the past about CGI and the
like.  I just wanted to let you know a couple things as they relate to the
way I've handled some of the same problems.

1) On our first server, a small 170 like yours, I got bit by the *NEW
problem a few times before I learned about activation groups.  We went
through a period of heavy activity for about a month and the poor old 400
just ground to a halt.  When I finally realized the problem and corrected it
the improvement was great.  I now use only named activation groups with my
CGI programs.

2) Originally I was having a problem where the 400 was creating too many
server instances to keep up with demand.  Even though I set the limits at
server start-up, by the end of the day they would still be maxed.  So I
wrote a quick little routine that performs nightly cleanup for the website.
Statistics tracking and the like, so I added a simple server shutdown and
restart.  As a natural side affect, my activation groups are fresh every
day.

3) One thing I've found is that if you perform an override database function
and then call a program outside the Activation Group that relies on that
override it won't work.  Seems that the Activation Groups don't really
communicate with each other, so I started being very careful concerning
which ones I name and which I use *CALLER.

Ciao,

Joel R. Cochran
Director of Internet Services
VamaNet.com
800-480-8810 (va toll free)
540-885-8050 (phone)
540-886-1589 (fax)
www.vamanet.com
mailto:custservice@vamanet.com


>-----Original Message-----
>From: Nathan M. Andelin [mailto:nandelin@relational-data.com]
>Sent: Wednesday, October 03, 2001 4:20 PM
>To: MIDRANGE-L@midrange.com
>Subject: Re: CGIDEV2 performance versus Net.Data
>
>
>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
>
>
>
>
>
>_______________________________________________
>This is the Midrange Systems Technical Discussion (MIDRANGE-L)
>mailing list
>To post a message email: MIDRANGE-L@midrange.com
>To subscribe, unsubscribe, or change list options,
>visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
>or email: MIDRANGE-L-request@midrange.com
>Before posting, please take a moment to review the archives
>at http://archive.midrange.com/midrange-l.
>