RE: What happened to rpgenerationx.com?

Well you've hit the head on the nail with the limitations to CGI - serving up 
static pages is EASY.  CGI - well - my commerce site is pure CGI - so stinks to 
be me.

That took a 270 with 2000 CPW down to about 800 CGI connections (simultaneous) 
per second according to the IBM calculations - which I was only able to 
simulate (using load testing software) 500 simultaneous connections per second, 
which the server would clutch it's buttocks and poop (sorry - bad visual!).  So 
then it came to "How do we solve this issue" and that became a search for a 
bigger system... landing me into the 820's - but the 820's were like about 400K 
to 500K and we had MAXED out that line of server screwing us on the next 
upgrade to buying a WHOLE new one.  OK - so it's off to 830 land.  That's when 
I settled into the notion of buying about 700K of server, and load balancing 
them together, an investment that would have made us REALLY look dumb if the 
SAME problem happened (we also had 4Gigs of memory on the 270!)

So - doing the SAME thing today requires - what ONE or TWO load balanced PC's 
running Linux?  Linux is VERY stable from what I hear AND SEE!!!

Now talk to me about serving up B2B and you got a deal.  Outsourcing this on an 
AS/400 is just plain DUMB - the 400 can handle this traffic, and will be 
reliable as anything out there, without the stress of a GAZILLION users hitting 
it to see the latest fashions.

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: Nathan M. Andelin [mailto:nandelin@relational-data.com]
Sent: Tuesday, July 30, 2002 2:53 PM
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.