|
To my surprise, a batch server is hardly any faster than the directly called RPG server. It's about 7% faster, if that. What's interesting is the breakdown in CPU usage during this time: DEFAULT_SE QEJB BCI 45.3 QZRCSRVS QUSER PJ 26.1 QDFTJOBD SERVER BCH 4.8 PBD270W30 QTMHHTTP BCH 3.3 While I'm not exactly sure about all this, I know that the QDFTJOBD is my RPG server program, and PBD270W30 is my HTTP server. QSRCSRVS is my actual servlet and DEFAULT_SE is my web server instance. The trick is breaking down the latter two. My servlet actually calls the methods that do the data queue management, the EBCDIC-ASCII conversion and the HTML formatting, so you'd think that all that activity would be in the QZRCSRVS job. However, these are in jar files which are assigned to the default server, so are there threads that run inside the web server job? My guess is that the QZRCSRVS is the one doing all the actual conversion and DEFAULT_SE is handling the web serving aspect, but I can't determine an easy way to tell and I'm pretty burnt out right now <smile>. If that's the case, though, then over half of the overhead is in pure servlet overhead. This actually makes some sense, because if that were the case, my run times less web serving would be nearly identical to Nathan's ILE approach (that is, if the CPW numbers really represent the representative horsepower of the machine). The only way for me to tell would be to create a persistent CGI program to do the same thing as my servers, and that's frankly a little more work than I care to embark on today. However, I think I've clearly shown that the model 270, at least, is a more than capable web serving platform. Joe > -----Original Message----- > From: owner-midrange-l@midrange.com > [mailto:owner-midrange-l@midrange.com]On Behalf Of Joe Pluta > Sent: Thursday, May 24, 2001 1:28 PM > To: MIDRANGE-L@midrange.com > Subject: RE: Websphere: a resource hog? > > > You gotta love this stuff. Okay, I just moved the I/O out of the servlet > and into an RPG server. I still have to start a session with the > AS/400 and > call the RPG server program for every request, but this still oubles the > througput. I'm now matching your response time, Nathan, of about > .6 seconds > for 5 users, although I'm kicking out 33% more data. > > At this point, WebSphere is running roughly one fourth as fast as your ILE > approach, and I haven't even put the server in batch yet (which will > eliminate RPG initialization time). > > Joe > > > > -----Original Message----- > > From: owner-midrange-l@midrange.com > > [mailto:owner-midrange-l@midrange.com]On Behalf Of Nathan M. Andelin > > Sent: Thursday, May 24, 2001 11:06 AM > > To: MIDRANGE-L@midrange.com > > Subject: RE: Websphere: a resource hog? > > > > > > > Of course, that's basically just measuring WebSphere's > > > capability to generate and output HTML. Using the > > > Java toolbox, a simple application building an 8KB page > > > from a disk file will run 5 sessions at once with a 1.3 > > > seconds response time. That's 230 hits per minute, > > > or over 12,000 per hour. > > > > Those sound like impressive results, Joe. But I guess it all depends on > > what you compare it to. So, I decided to run the JMeter Web Stress tool > > against one of my ILE Web Application Servers. The ILE server reads a > > database file and builds a 6KB response containing HTML and > > fields from the > > database. The average response time is about .6 seconds when serving 5 > > simultaneous clients. > > > > The impressive thing is that this is all done with a model > 170-2290, which > > has a CPW rating of 73. > > > > Nathan. > > > > > > +--- > > | This is the Midrange System Mailing List! > > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > > | To unsubscribe from this list send email to > > MIDRANGE-L-UNSUB@midrange.com. > > | Questions should be directed to the list owner/operator: > > david@midrange.com > > +--- > > > > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > | To unsubscribe from this list send email to > MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: > david@midrange.com > +--- > +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.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.