Re: Dropping the AS/400 as a Web serving platform -- MIDRANGE-L

>That doesn't sound too big.  I'd estimate that a 1100 CPW 820 could serve
>about 40 dynamically generated pages per second.  Or 144,000 hits per hour.

I may have screwed up - hour nope - my bad.  We're getting bursts that could
peek @ 3200 per second.

40 per second sounds great.  I average between 70 and 200 per second.  I'm
still talking 500 to 3200 per second when my marketing team bursts an E-mail
of 1 million.  The traffic generated is 25% within the first hour - which is
3200 per second by my calculation.  CGI - happens to be the fastest
interactive web technology on the 400, followed by JSP's & Java, followed by
Net.Data, Followed by the rest.  We're good there.  As far as messaging with
an NT box - straight sockets with an AS/400 is pretty cool.  On an internal
network, why not direct SQL calls?  My whole site is dynamic, and one of the
thoughts was to generate static Html pages based off of templates, and
pumping out everything but the checkout process.  We thought that up a year
ago, but we have 20 web sites right now, all reading the same data
(different calculations!), and performing generally the same functions.  One
of the thoughts was to Load-balance to the SAME AS/400 since the http server
was our bottleneck.  The server wasn't even clicking over (2000 CPW...)
which would have been fine.

>Did I misunderstand the model you proposed?  To front-end an iSeries
>database server with multiple Web servers?  In either case, the database
>server could have some downtime.  How would the front-end Web servers
>prevent that?

YUP!  The scale which we have expanded was exponential. (Please pray that it
keeps up!!) So to scale with the IIS platform, I buy a one inch thick WEB
server for $3,000, load it up, update the load balancer, and BAM another
2000 people per second hit my web site.  Were I to think the thicker servers
in the AS/400 world, it gets expensive because I need to mirror the data and
the disk.  Anyway - the back end "Database server" could be a mirrored
system.  The HTTP servers need to look @ the Data in a central place.
Anyway, since most E-commerce solutions involve the linking to a back end
system, what is the point of having a upscale mirrored system, when every 5
minutes everything is taken from the system, and the back end is updated.

As far as management, since I was outsourced to a company that will provide
this, including the communications to the internet (ie the T1/T3 etc...) for
half the price of our current ISP, I'm still screwed.

Remember - I can solve the problems of the damn box, I can't solve the
problem of the people.  You and I are the rare birds in the US that plays
WEB on the AS/400.  Since I can scale people far easier (or easier in the
eyes of my marketing staff...) the decision was clear, after looking at the
increasing backlog of work.

>After your new system goes into production, I hope you'll provide a report.
>Since it's competing against CGI and Net.Data, then it may offer more
>scalability.  I don't know.  But I'd bet you'll be fiddling with it more
>often than your OS/400 hosted solution.

Again - I was outsourced.  WHICH STINKS!!  CGI kicks butt on the AS/400 - I
can prove that by serving up to 30,000 visitors every day.  Bring up the
site now & you'll see.  Within one hour, I served 3,000 visitors.  Bottom
line - there is a way of making the AS/400 work within our intense needs -
but @ what cost.  My scalability is questionable since I started with the
2000cpw Model 270.  From there, I need to skip the 820's and go to the
830's - with the capacity on demand just to get a significant difference in
performance to what I have now.  So now ask the CEO for 1.5 million in
servers, when the site is still new, and we're still in our first year, and
we still have some growing to do.  Wait - the last time we asked for money
for servers, we only needed 1 100th that amount.  If I had the ability to
cheaply add servers to my current environment, point it to my database like
an obedient dog, and get capacity for my on-rushing web visitors - then I'm
sure my boss would be happy.

In the meantime, call me Mr. B2B where I'll be helping out one of the most
aggressive B2B projects I've ever seen - on our remaining AS/400's.


From: "Nathan M. Andelin" <nandelin@relational-data.com>
To: <midrange-l@midrange.com>
Subject: Re: Dropping the AS/400 as a Web serving platform
Date: Mon, 1 Oct 2001 14:57:15 -0600
Reply-To: midrange-l@midrange.com

> From: "Andrew Borts"
>
> we were finding problems scaling the architecture.
> The current sites (www.palmbeachjewelry.com and
> www.myfreeitems.com ) are running mostly custom
> written CGI scripts, and Net.Data macros's with
> Net.Commerce back end.

Right.  Net.Data and CGI are not known for scalability.  It's too bad you've
learned that the hard way.

> The model I quoted IS the correct web model - what ever
> the platform... you MUST plan for this down time, planned
> or unplanned...

Back in college, my Operations Management professor stressed the importance
of having backup system when uptime was critical.  When one system is down,
the other takes over.  He stressed that if a system had a 1% failure rate,
and a backup was available, then the probability of downtime was 1% of 1% -
or 1 out of 10,000.  In the case of planned downtime, then just route
traffic to the mirrorred system.

Did I misunderstand the model you proposed?  To front-end an iSeries
database server with multiple Web servers?  In either case, the database
server could have some downtime.  How would the front-end Web servers
prevent that?

My point was to address your scalability issue.  Some people think that
using IIS to generate the HTML from data retrieved from the iSeries is more
scalable.  They reason that much of the work is offloaded to low-cost Intel
computers.  Maybe it is more scalable than CGI and Net.Data.  But it's not
more scalable than a message architecture, such as the one I used to build
my product.

If you want to move some of the work to low-cost Intel servers, may I
suggest that you (or people, in general) use IIS to serve static pages,
while using the AS/400 to dynamically generate HTML?  It streamlines the
development and deployment environments, offers equivalent scalability, and
costs less overall.  As I mentioned before, it takes about as much work to
generate an ODBC or JDBC formatted stream as it does to generate an HTML
stream.

After your new system goes into production, I hope you'll provide a report.
Since it's competing against CGI and Net.Data, then it may offer more
scalability.  I don't know.  But I'd bet you'll be fiddling with it more
often than your OS/400 hosted solution.

> More un-planned downtime seems to exist in the IIS world,
> but with 15 other servers where the one that went down came
> from, who cares.

Sounds like you should.  The people who have to manage 15 other servers will
eventually care.

> The scale I'm talking about is between 500 and 3000 visitors
> per hour.

That doesn't sound too big.  I'd estimate that a 1100 CPW 820 could serve
about 40 dynamically generated pages per second.  Or 144,000 hits per hour.

> Apache looks promising to bring the AS/400 into more
> interesting worlds, but the benchmarks are published for everything
> BUT the iSeries.

I agree that an AS/400 offers poor price/performance in comparison to Intel.
But I'm more interested in total cost of ownership.

Nathan M. Andelin
www.relational-data.com