|
Responses below. Mel Rothman CGIDEV2 Author IBM eServer iSeries Custom Technology Center (iCTC) http://www-1.ibm.com/servers/eserver/iseries/service/ctc/ Rochester, Minnesota "Nathan M. Andelin" wrote: > > > From: "Mel Rothman" <mel@rothmanweb.com> > > > As Leif points out, what's really being used is virtual memory. > > I don't understand this. Or how it relates to the issue of scalability. > The point is that the amount of virtual storage allocated by activated programs doesn't directly affect performance much. What does is when the demand on real storage significantly exceeds the available real storage. A couple of simplified examples to illustrate the point. It's really a lot more complicated because paging is a lot more granular than I'm using in the example and is influenced by things like activation levels, run priorities, time slice intervals, etc. The system manages storage much better than one might infer from these examples. First, 10 activated programs, each running in a separate job, each having allocated 1MB of virtual storage = 10 MB of virtual storage. At a given instant, if 6 are active, only 6MB of real storage are required. If the system has 8 MB of real storage available for programs, 2 of the 4 non-running programs will have been paged out but the 6 running programs should run fine with no additional paging required. The other 2 non-running programs are ready to run without paging because their pages are in real storage. If 3 more suddenly start running (total 9), 9 MB of real storage are required, 1MB more than available. So, 1 of the 9 running programs would have to be paged out (perhaps one that was already paged out) and wait for real storage to become available at which time it would run. Using the same 8Mb of available memory, if there are 100 activated programs each requiring 1MB of memory, but most of the time no more than 8 are running, paging will occur as one stops and another starts (assuming the one just starting was paged out), but there won't be thrashing. If 20 are trying to run most of the time, there will be a lot more paging, probably thrashing, and performance will suffer. In a case like this with the HTTP server, it would be important to "tune" the number of running programs to some number perhaps a little above 8, but significantly below 20. So, the amount of required virtual storage is not directly related to the amount of required real storage. In the second example, if the number of activated programs was 500 or 1000, but still no more than 8 ran at a time, performance would be similar to what it would be with 100 activated programs or 50 activated programs. So, the critical factor is the real storage required by running programs. In reality, the more real storage, the better. > > this is a problem when activity gets so high that excessive > > paging occurs. > > If CGI programs are active, but not running, would that increase the > occurance of paging? Yes and no, as illustrated in the second simple example above when 8 or fewer of the 100 programs are running concurrently. Yes, paging occurs when a program that had been paged out starts running, but the system can handle this kind of normal paging easily. The more the real storage required by running programs exceeds available real storage, the more paging increases and the harder it becomes for the system to keep up. > > > As previously pointed out, this can and should be controlled > > by throttling the server. > > That makes sense. It's an imposed bottleneck. Yes, but it's much better than allowing thrashing. This is commonly called performance tuning or optimizing. > > It's not clear whether you approach supports a remote > > application server. > > Not presently. But it wouldn't take much to add remote routing via data > queue. That's what I thought. Note that sockets are much faster than data queues. At some point, you might want to offer your customers the choice of data queues or sockets. The iCTC's sockets server is excellent. Read all about it at: http://www-1.ibm.com/servers/eserver/iseries/service/ctc/details/a2_ssrv.htm > The Relational-Web version of my sample application uses about 80% less CPU > time than the Easy400 version, and about 90% less CPU time than the Net.Data > version. This is a nit but you previously said Easy400 and Net.Data used 80% and 90% more than Relational-Web. If so, then Relational-Web would use 44% and 47% less than Easy400 and Net.Data. > I'm not sure how significant those percents are. Is it important to people? > Perhaps not. A tool can only do so much. It's really up to the programmer > to create efficient software with the tools provided. Agreed. > > 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.