|
See inline comments. Mel Rothman CGIDEV2 Author IBM eServer iSeries Custom Technology Center (iCTC) Rochester, Minnesota "Nathan M. Andelin" wrote: > > 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. Where are you measuring Relational Web's CPU? In the message server? In the application server(s)? Both? It seems that both is what should be measured. What about response time comparisons? I suspect they are closer than the CPU differences you report. I don't doubt that a message-based server plug-in has performance, resource utilization, and probably scalability advantages, but I'm not convinced they are as great as you say. > > > 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. With CGI, named activation groups are the only way to go because *NEW activation groups have such heavy overhead. IBM strongly says so in its documentation. I have discovered the same in more than 5 years of developing CGIDEV and CGIDEV2 and using them in performing contract work for customers. Comments in the newsgroups and mailing lists have consistently agreed. A web site whose CGI programs are hit heavily will die a lot quicker if all its CGIs run in *new activation groups. The overhead is that heavy. > > 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. > Some of my customers have combined CGI and a sockets server (available from the iCTC) to make their sites faster and more scalable. This is similar to your method in that the application logic is performed by never ending programs running in the sockets server, either on the same or a different AS/400. Instead of a server plug-in (which I think is an excellent idea), a small number of CGI programs accept browser input, send processing requests to the sockets server, receive responses from the sockets server, and send responses to the browser. This is extremely fast, extremely scalable, and, when the sockets server runs on a different AS/400, extremely secure. One of my customers is using this approach with only one CGI program to handle all requests. The CGI accepts the browser's inputs and sends them to the sockets server. It doesn't even look at the variables or their values. The sockets server performs the application logic and sends substitution variables and section (fragment) names, etc. to the CGI, which then writes those sections (fragments) to the browser. This is very fast, very slick, and the one CGI program, once written, never has to be touched again.
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.