|
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. >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.