× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: Websphere: a resource hog?
  • From: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
  • Date: Thu, 24 May 2001 15:04:12 -0500
  • Importance: Normal

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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.