|
No. Java is multi threaded, so it uses the same instance of code, but has 900 different "pointers" to the code. Am I correct (besides poorly explaining)?? -----Original Message----- From: Walden H. Leverich [mailto:WaldenL@TechSoftInc.com] Sent: Tuesday, July 30, 2002 2:12 PM To: 'web400@midrange.com' Subject: RE: [WEB400] What happened to rpgenerationx.com? >From: Nathan M. Andelin [mailto:nandelin@RELATIONAL-DATA.COM] >The engine just synchronizes requests to one Servlet rather than creating 900 separate instances of the same. Do I understand "synchronize" correctly? Are you saying that if my servlet takes, say .1 seconds to run, the first person will be .1 second response time, but if a second person hit at exactly the same time he would get .2 second response time (.1 seconds waiting for the first person to finish then .1 seconds for the second person to run?) If 900 users hit at exactly the same time the last one would have a 90 second wait? Granted 900 users won't all hit enter at the same time, but with a .1 second run time I'd guess 50 users could. That's a 5 second wait time for the poor 50th user to hit enter. Please tell me I don't understand your comment. -Walden ------------ Walden H Leverich III President Tech Software (516) 627-3800 x11 (208) 692-3308 eFax WaldenL@TechSoftInc.com http://www.TechSoftInc.com Quiquid latine dictum sit altum viditur. (Whatever is said in Latin seems profound.) -----Original Message----- From: Nathan M. Andelin [mailto:nandelin@RELATIONAL-DATA.COM] Sent: Tuesday, July 30, 2002 14:53 To: web400@midrange.com Subject: Re: [WEB400] What happened to rpgenerationx.com? > From: "Andrew Borts" > We actually worked with the IBM folks to try and resolve it, and set > thread count accordingly to their suggestions - which varied greatly. In my experience, the thread requirement is roughly 2-3 times the number of concurrent users. 300 users would need 600-900 available threads, for example. Activating that many threads however poses a big problem for the CGI interface. Eventually 900 instances of every CGI program become active, and remain active, if (like Net.Data) they run under a named activation group. It's like a perpetual memory leak. Eventually, system resources become exhausted, and the only solution is to reboot the HTTP Server. > but the HTTP server isn't as reliable, and darn close > to sub-par in it's reliability. Folks need to distinquish between the HTTP Server and the CGI Interface. While the HTTP Server is both scalable and reliable, CGI has its limits. It takes little system resources to support 900 HTTP Server threads. But 900 BCI (CGI support) Jobs is a whole different matter. > Is fiddling with the controls of the dang thing the > option? Is switching to Apache the option? The Apache based server uses an equivalent CGI interface, so Apache doesn't solve the problem. Just because something works great with five (5) users, doesn't mean it will work with five hundred. IBM's answer is a Servlet engine that never instantiates more than one instance of a Servlet. The engine just synchronizes requests to one Servlet rather than creating 900 separate instances of the same. The same thing can be done with ILE, of course. But developers need to be aware of the problem in order to address it. I addressed the problem with the design of Relational-Web, which is an ILE framework. Nathan M. Andelin www.relational-data.com _______________________________________________ This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To post a message email: WEB400@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/web400 or email: WEB400-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/web400. _______________________________________________ This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To post a message email: WEB400@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/web400 or email: WEB400-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/web400.
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.
midrange.com
