Just to clarify, I started the discussion because I wanted to try IceBreak as an alternative to Apache for Renaissance. I have been working on this for about a day and I am pretty close to getting it working. IceBreak does not use Apache as a front-end - I am not sure where that assertion comes from. I am using Icebreak with Renaissance (and therefore all the underlying CGIDEV2 procedures) without any Apache server in the equation at all. I am not using any of the nice Icebreak runtime compilation stuff at all at the moment - I simply tell it to call my own routing program via the URL which uses the Icebreak procedures to get the request data and return the response (instead of the normal stdin/stdout procedures).
It is too early to tell if this will be a worthwhile exercise or not, but given that our largest customer has some odd things happening with Apache (on a very large box under extreme load), and IBM have not been able to understand why, I am keen to see if there is a viable alternative.
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: 05 January 2011 12:29
To: Web Enabling the AS400 / iSeries
Subject: [WEB400] Summing up the Icebreak discussion
We've just returned from vacationing in Spain with family, so I'm just catching
up with the list. There appears to be a lot of misinformation shared in the
Icebreak discussion that is causing confusion. It appeared to begin with Jim T.
asserting that Icebreak included its own HTTP server as an alternative to
Apache, and implying that it performed 10 times faster than CGIDEV and other web
frameworks. Scott. challenged that claim, and so would I. Niels finally
admitted that Icebreak uses Apache on the front end. And I'd bet that Icebreak
performance is fairly in-line with CGIDEV2. I'd suggest running a benchmark if
anyone feels strongly to the contrary. I wouldn't mind collaborating on a
simple benchmark.
There was some discussion about scalability. Aaron Bartell indicated that he ran
into a TCP limit and Joe Pluta followed up with some rather vague comments about
a limit of 256, and a couple hundred jobs before things go casters up, and a
need for horizontal scaling. I was confused by that, at least.
Then discussion erupted over stateful vs stateless architecture where state may
be managed automatically by giving each user their own job vs. many users served
by a few jobs. Some people seemed to understand that saving and restoring
session state in multi-user jobs was resource consuming while others expressed
concern over giving each individual user their own job and having IBM i allocate
memory, CPU and other resources to each; they seem to understand intuitively
that allocating memory to and swapping thousands of jobs in and out of the CPU
could be resource consuming too. More uncertainty.
The metaphoric likeness between Icebreak, JEE Application servers, and ASP .Net
was confusing. Maurice and Richard didn't seem to catch the metaphor at all,
initially. Giving allowance, the comparison was vague. Under stricter
interpretation, it was misleading. For example, under JEE and ASP .Net a
potentially large number of disparate applications run within a single container
- a single process - a single job - multiple threads. Under Icebreak, each user
may have their own job, evidently. If that's the case, why label Icebreak a
"container" and say it's like JEE and MS runtime environments?
-Nathan
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/web400.
NOTICE: The information in this electronic mail transmission is intended by CoralTree Systems Ltd for the use of the named individuals or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone, so that the sender's address records can be corrected.
--------------------------------------------------------------------------------
CoralTree Systems Limited
25 Barnes Wallis Road
Segensworth East, Fareham
PO15 5TT
Company Registration Number 5021022.
Registered Office:
12-14 Carlton Place
Southampton, UK
SO15 2EA
VAT Registration Number 834 1020 74.
midrange.com
