|
I've pretty much come around to accept that the use of named activation groups are a key to CGI scalability. Named activation dramatically cuts CPU time. The concern that remains (perhaps only in my mind) is the issue of memory. We have pointed out that the mechanics are already in place to dynamically add HTTP Servers BCH Jobs to support the user load, up to a configurable limit. Let's say that limit is the system default of 40. Let's also say that your application consists of 100 CGI programs. It seems to me that named activation opens the possibility of 4,000 instances of CGI programs to be running concurrently (100 CGI programs times 40 BCH server Jobs). Running may not be the correct word. In fact, they probably aren't running. But they have memory and files and other resources allocated and opened. The number of program activations could grow from 1 to 4,000 depending on how busy the server was, and how the HTTP Server routed new requests. My observation is that the HTTP Server's BCI Job simply routes CGI requests to the next available BCH Job. There is nothing similar to the Java garbage collector to deallocate the resources. So shutting down the HTTP server appears to be the only practical way to reclaim those resources. By making these points, I hope I'm not offending anyone. I just want to sort all this out, so I can refine my message, and not do a disservice to myself or anyone else. Thanks, Nathan M. Andelin www.relational-data.com
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.