RE: [WEB400] What happened to rpgenerationx.com?

["Andrew Borts" <Andrewb@xxxxxxxxxxxxxxxxxxx>]

OK - the other thing you MUST think about...

The CGI thread is the ONLY one being requested... the appropriate images cause 
their OWN threads to be used to download stuff.  Hence a "Hit" is something 
happening on that server.

So - to speed up our 400's, we used Akami's 4000 (now 40000 from what I hear!) 
redundant image servers to deliver our graphical content, speeding up our 
server a TON because the ONLY hits on the system were now static HTML and CGI 
calls.  So 10 "hits" on the site with a single CGI program outputting HTML 
isn't an indication of anything BUT the above situation - no graphics being 
downloaded.  That's why image servers can save your tushies sometimes.

As far as efficient software to perform these outputs, the AS/400's matrix is 
.8 something per CPW for a CGI program in V4R4 (last time I saw the matrix on 
performance was in a Redbook!) .3 per CPW if it was in SSL mode.  Static HTML 
pages serve (as long as they are cached!!) at about 1.8 per CPW, un-cached 
stuff serves at about 1.2 per CPW.  NOW - Net.Data SQL is rated at about .4

I'm enclosing the table as an attachment... (if you don't get it - let me 
know!) but it came out of an IBM redbook...)



This was what we used to determine how we could get 25 thousand hits per second 
we needed to serve our average E-mail response...

Our site was NOT static, but reacted per customer...

Andrew Borts / Webmaster
Seta Corporation
6400 East Rogers Circle
Boca Raton, FL 33499

E-mail: Andrewb@setacorporation.com
Corporate web site http://www.setacorporation.com
E-Commerce web site http://www.palmbeachjewelry.com
                              http://www.myfreeitems.com
Voice: 561-994-2660 Ext. 2211 / Fax: 561-997-0774

-----Original Message-----
From: Brad Stone [mailto:brad@bvstools.com]
Sent: Wednesday, July 31, 2002 9:27 AM
To: web400@midrange.com
Subject: Re: [WEB400] What happened to rpgenerationx.com?

I disagree.  If when I was surfing I could strip out the
time that it took to connect that would be great.  I've used
JMeter and I think it "cheats".  I wrote a Java version of
my tool using threads (instead of jobs) and got almost
identical results.

Mine measures from request to completion.  That's how
requests work in the real world.  I've used my tool to load
test many servers, and even the pbA server.  And using it
before and after loading PTFs that help it's CGI performance
it was shown to work.

Anyhow, you shouldn't be worried if I show 3 seconds for a
hit, and you show 800 milleseconds.  You should be worried
about the percentage of difference between 1 request and 10
requests.  Not the actual time.

I'm making the requests from a 170 with 1 gig memory and
average load.  It's also a web server for a LOT of web
sites.  10 users shouldn't make much of a dent unless you
have less than 512k memory, full DASD, 2 arms, etc.

Brad
On Tue, 30 Jul 2002 18:19:11 -0600
 "Nathan M. Andelin" <nandelin@RELATIONAL-DATA.COM> wrote:
> Brad,
>
> Just so we're comparing apples to apples, I have another
> suggestion.
> Download a copy of the JMeter stress test tool from
> www.apache.org to do the
> test.  JMeter instantiates client Threads rather than
> Jobs, and if I
> understand correctly measures the time between the
> request and the first
> byte received in order to strip network time from the
> equation.
>
> Also remember that you're hitting a model 170-2290.  It
> doesn't take much to
> drive the CPU utilization to the wall.  Ten users with no
> delay will peg my
> CPU at +++ utilization.  To be accurate, your tests need
> to let my CPU
> breath, as mine did.
>
> 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.