Re: Which scales better? J2EE, PHP, or CGIDEV2?

[Nathan Andelin <nandelin@xxxxxxxxx>]

Robert,

I have a copy of a benchmark study run some years ago that details attempts to 
stress test a JEE application on a 32-CPU IBM i server.  No matter how many 
threads they allocated to WAS, they could NOT drive CPU past 10%, until they 
deployed their application across 32 WAS instances.  This study has 
been corroborated by every formal standard published benchmark ever since; Spec, 
SAP, whatever.  There is always a strong correlation between the number of app 
server instances and processors.

I was responsible for writing a multi-threaded robotic simulator in Java.  I 
have experience in what it takes to protect a singleton's memory when it is 
accessed by multiple threads concurrently, and it appears to me that most 
Servlet authors don't think twice about it. It appears to me that if app servers 
didn't synchronize access then we'd be hearing a lot more stories about JEE 
application failures.  I admit that I haven't analyzed app server code.  But 
benchmarks and experience support the conclusion.

-Nathan




----- Original Message ----
From: "Dean, Robert" <rdean@xxxxxxxxxxxx>
To: Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
Sent: Wed, October 6, 2010 9:31:49 PM
Subject: Re: [WEB400] Which scales better? J2EE, PHP, or CGIDEV2?

Which studies?  Most of the studies I've read that reached such a conclusion
are from when the platform was actually called J2EE.  Since Java SE and Java EE
5 and 6 came out, concurrency support is vastly improved.

Most of the stuff you've written about servlets and request handling appears
based on a second-hand understanding that isn't entirely true.  Java EE app
servers manage requests using a thread pool.  Some app servers don't even
tie up a thread while handling a request.  While threads are waiting for I/O, 
they're moved to a wait state until their request is satisfied (should sound 
familiar).

Servlets are typically singletons on each appserver instance, with concurrent
access permitted unless the developer has specifically overridden it.  These
calls are not serialized.  

IBM i scales WebSphere very well, both horizontally and vertically.