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