RE: CGIDEV2 performance versus Net.Data

Sorry if I over reacted Mel.  You know how sometimes the written word just
hits you the wrong way... no harm done.

Anyway, I could have been more clear... the 170 was throttled.  By hitting
MAX I meant that it was hitting the throttle limit I had set (once I learned
about doing so).  The problem was that I couldn't use the throttle limit IBM
suggested (1.5) to support the kind of traffic we were getting, so I had it
set at 25.

I began the reset procedure long before I had an inkling what was going on,
but at least at the beginning of everyday I had fewer jobs out there. It
made sense at the time, but again I freely admit I didn't know a lot about
what I was doing.  As one of those personal choice things, I found myself
taking advantage of the scheduled downtime (less than 3 minutes in the
middle of the night) to do some traffic analysis and the procedure has
simply stuck.

I like knowing that I'm starting with a clean state everyday, and since the
procedure was already in place I just kept it up when I moved to the 270
which is NOT throttled and has NEVER added an additional job.  That machine
is simply amazing!

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: Mel Rothman [mailto:mel@rothmanweb.com]
>Sent: Thursday, October 04, 2001 9:51 AM
>To: midrange-l@midrange.com
>Subject: Re: CGIDEV2 performance versus Net.Data
>
>
>Sorry, Joel, no offense was intended.
>
>The ONLY part of your approach I was referring to was your
>daily ending and
>restarting the server to clean up activation groups, threads,
>etc.  I certainly
>didn't mean to imply that this is wrong; only that it isn't necessarily
>required.  Nathan, in support of his belief that CGI does not
>scale well,
>suggested that since you were doing it once a day, busier
>sites would therefore,
>have to do so even more often.  I was saying, "not necessarily so."
>
>I should have made it more clear that I was referring only to
>the daily ending
>and restarting of the server; not your entire approach, which
>is sound and has
>worked well for you.
>
>The difficulty I perceived you had was when you said "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."  For some reason, you were not
>able to throttle the
>server.  Maybe this was a server bug?  In any case, it was a
>difficulty for you
>at the time.  No judgment was implied.
>
>With your current 270, it is no longer a problem.  With the
>170, if the server
>had been throttled, you might not have had to end and restart
>it every day, at
>least not for that reason.
>
>With the server properly throttled and CGI programs well
>written, no one should
>have to end and restart the server daily for the purpose of
>cleaning up threads,
>activation groups, etc.  For other reasons?  Individual choice.  Common
>practice?  Perhaps.  Any harm done?  Other than the site being
>unavailable for a
>short time, no.  Absolutely necessary?  No.  Required more
>often for busier
>sites?  No.
>
>Again, I apologize for unintentionally offending you.
>
>
>
>
>
>Mel Rothman
>CGIDEV2 Author
>IBM eServer iSeries Custom Technology Center (iCTC)
>Rochester, Minnesota
>
>
>
>"Joel R. Cochran" wrote:
>>
>> Jeez... no wonder my ears were burning last night...
>>
>> >Joel Cochran's approach isn't necessarily what other CGI users
>> >do or should do.
>> >
>> What's so unusual about my approach?  I run named activation
>groups, use
>> standard CGI techniques, and the last I checked nightly
>cleanup routines
>> were pretty commonplace... All I did was what this list is
>about, shared
>> with Nathan some of my experiences in the hopes that it
>might be helpful.
>>
>> >Again, well written CGI named activation group programs should
>> >consume a
>> >constant amount of storage over their running life.  And,
>although Joel
>> >apparently had difficulites with it, one can, and should,
>> >throttle the number of
>> >threads the server uses to match the system's configuration in
>> >order to maintain
>> >performance under heavy load.  See the Webmaster's Guide
>for details.
>> >
>> The only problems I had (at the time) were lack of
>experience and training.
>> We were experimenting on a 170 with 73cpw which also
>happened to be a full
>> time production machine.  When we took 250,000 hits in one
>month then YES we
>> had "problems".  If you follow the guidelines in the
>documentation, there is
>> a formula that tells you how many threads you should use.
>Based on our CPW
>> ours should have been 1.5... obviously that wasn't going to
>cut it and at
>> that point I couldn't take the site down, so I let it go and
>fill out it's
>> max number of threads everyday, and then started the nightly
>routine to kind
>> of reset everything.
>>
>> Today, that simply isn't a problem.  I've got a dedicated
>270 with over
>> 1,000 CPW that does nothing but run the website.  Not to
>mention that I
>> learned an awful lot over the last year about this stuff.
>While I don't
>> claim the knowledge base that you and the other CGI gurus
>can, I think I can
>> hold my own when it comes to efficiency, productivity, and
>writing "well
>> written CGI named activation group programs".  And you can't deny our
>> success: we originally went from concept to delivery in less
>than 3 months,
>> and included in that time were learning RPGIV, ILE, HTML,
>JavaScript, HTTP,
>> CSS, SSI, and enough Java to do Applets!  So please, make
>all the comments
>> you want about my approach, just don't patronize me.
>>
>> 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
>_______________________________________________
>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.
>