|
These are neat ideas, especially the socket server. But I don't understand how a socket server improves performance, I can't picture the architecture... Traditional CGI: 1. web browser request is sent to 2. http server, which calls 3. custom CGI program, which generates output back to 4. HTTP server, which sends the page to 5. web browser So I can see that each time the CGI program is called, there is a lot of activation overhead, unless you're in named activation groups and returning with LR off (if using RPG). Based on your comments, I picture the process as this: 1. web browser request is sent to 2. http server, which calls 3. "generic" CGI program, which sends requests to 3a. socket server, which evaluates the request and calls a 3b. custom CGI program to generate the response ??? back to 3c. the socket server, forwards the response to ??? 3d. the generic CGI, back to ??? 4. HTTP server, which sends the page to 5. web browser I guess I fail to see where the performance benefits occur. Is 3a a neverending socket server job? Is 3c a thread program in the 3a job, or is 3c a full program job call by 3a? For the typical pages we process (reading realtime from databases), somewhere file opens and initialization takes place. I can imagine a single request taking a little longer, due to more program calls. Our AS/400 is not connected to the internet, and probably won't be (at least directly). We do have a requirement to develop inquiries for our suppliers to see vendor rating/supplier assessment information, but those requests will probably be funneled through a corporate portal. Since we're doing traditional CGI, with CGIDEV2 and e-RPG, it would be interesting to know how other solutions work and tie together. Are there any white papers or FAQs for understanding the architectural differences between traditional CGI and message/data queue/socket server based approaches to web requests? Loyd -----Original Message----- From: Mel Rothman [mailto:mel@rothmanweb.com] Sent: Thursday, October 04, 2001 8:49 PM To: midrange-l@midrange.com Subject: Re: CGIDEV2 performance versus Net.Data <snip> Regarding design: - many CGI programs can and should be replaced by static pages - many CGI programs can be combined into fewer CGI programs - multiple CGI programs can run in the same named activation group. - infrequently used CGI programs can run in *NEW activation groups. Since they are not used often, the performance hit of creating and destroying the activation group is not a big deal. - a more difficult but very fast and efficient as previously mentioned, is a single CGI program that - accepts browser inputs without examining them, - sends the inputs to a sockets server running application logic on the same or different AS/400, - receives from the sockets server the output variables and HTML section names, and - sends the HTML to the browser. With this last scenario, every CGI server job runs only one program in one activation group. This is similar to your approach except that multiple CGI programs are used instead of a multi-threaded server plug-in and communications to the back end is via sockets instead of data queues. It's not clear whether you approach supports a remote application server. I have experience with back-end application servers communicating to CGIs through sockets and know they are very fast and efficient. In theory, your approach should be fast and efficient too. <snip> Mel Rothman CGIDEV2 Author IBM eServer iSeries Custom Technology Center (iCTC) Rochester, Minnesota
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.