As I mentioned before, the developer said the fixes that
brought the pbA server's CGI performance up to parity were
those released last September/October.

So, if you install the latest V5R1 CUM AND group PTFs,
you should be there.

The lab has already done performance testing with the
results published in the Performance Capabilities manuals.

For V4R5 the book is
  http://publib.boulder.ibm.com/pubs/pdfs/as400/V4R5PDF/AS4PPCP3.PDF
and the numbers published are for the classic server.

For V5R1, the book is
  http://publib.boulder.ibm.com/html/as400/v5r1/ic2924/books/as4ppcp4.pdf
and the numbers published are for the pbA server.

The CGI numbers in the V5R1 book are slightly better than those in the V4R5
book.  As far as classic versus pbA in V5R1, the V5R1 book says:

  V5R1 provides the new HTTP Server (powered by Apache)
  and continues to support the HTTP Server (original).
  The performance information provided in the tables
  represents HTTP Server (powered by Apache). In general,
  the performance of the two servers is fairly similar,
  so at a high level, the tables also reflect the
  performance of the HTTP Server (original). In order
  to achieve the best possible performance, especially
  with the HTTP Server (powered by Apache), make sure
  that you get the latest PTFs:
  http://www.ibm.com/eserver/iseries/software/http

I don't plan on offering any excuses regardless of the results you
get.  I believe that you will do everything you can to set up as
equivalent as possible server configurations and test scenarios, and you
will run them as fairly as you can.  If you don't find roughly equal
performance, I predict the developers will welcome any
input you would provide to help them figure out why.  That, of course,
is putting the horse before the cart.  Let's see what happens first.

Like you, I feel that roughly equal CGI performance would be a fine
result.


Mel



Brad Stone wrote:
>
> The latest CUM has been ordered.  But, I still have two
> problems.
>
> 1.  If I test with the latest CUM and performance is no
> better (or only slightly better), then there's the "you must
> not have installed the correct PTF(s)" excuse.
>
> I don't want this to be an issue, and I'm sure others don't
> as well.  I really want pbA CGI performance to be on par
> with Classic.
>
> 2.  I find it hard to believe IBM can't load test a web
> server.
>
> I searched the cover letters you mention earlier.  There
> were quite a few for V5R1 and pbA server.  I had thought
> that you said the developer said there were specific PTFs
> that increased the performance.  Maybe I read it wrong.  I
> can understand if the developer doesn't know which PTF his
> fix gets applied to, so we'll just have to wait and see.
>
> Thanks for your assistance, Mel.
>
> Brad
>
> On Thu, 21 Feb 2002 17:48:26 -0600
>  Mel Rothman <mel@rothmanweb.com> wrote:
> > Brad, I don't have any problem with your data.
> >
> > However, saying unequivocally that pbA CGI performance
> > "*IS* horrific," rather than "*WAS* horrific when I
> > measured it x months ago..." would be of much greater
> > value to all.
> >
> > Our developers neither need nor want the hassle that
> > comes with "bending" the truth.  And, I got the
> > developer's agreement to post what he said onto the
> > Web400 list, so he knew it would get wide distribution.
> >
> > I didn't mention which PTFs are needed.  The latest CUM
> > and all applicable group and HIPER PTFs should be
> > sufficient.  I would also search the cover letters at
> >   http://www-912.ibm.com/supporthome.nsf/home/PTF+Cover+Letters
> > for the string HTTPSVR sorted by date.  Sometimes a gem
> > is found
> > there that has not yet made it into the group PTF.
> >
> >
> > Mel


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.