Thanks for the season summary Bob Costas :-)
Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site:
http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT
------------------------------
message: 4
date: Wed, 5 Jan 2011 04:29:12 -0800 (PST)
from: Nathan Andelin <nandelin@xxxxxxxxx>
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
midrange.com
