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

[Thorbjoern Ravn Andersen <ravn@xxxxxxxxxx>]

 Den 06/10/10 23.40, Aaron Bartell skrev:
> Take a look at the Drawbacks and Alternatives section at the following URL:
>
> http://en.wikipedia.org/wiki/Common_Gateway_Interface
>
> It would appear that we don't have some of the issues.  We have a
> compiled language: RPG, we have processes that, once started, stay
> running for as long as the server is up.  That's where IBM i OS steps
> in because it has, in my opinion, a more refined approach to managing
> large workloads and other systems aren't built with the same thing in
> mind.
>
> Note also the stated comment on that page concerning J2EE.  They
> basically say the advantage of J2EE is that instead of creating a
> process (aka Job), they are able to instead create a smaller unit - a
> thread.  I would be curious to know how much CPU time is required to
> create a new J2EE thread vs. have Apache hand-off a "CGI" request to
> an existing job?
Threads are actually expensive objects, but not as expensive as a new 
process.  They are just very easy to use in a Java program (even a 
Enterprise Application Server), but for any high load system you will 
pool the threads and use them for whatever jobs are needed.  Also 
threads in modern JVM's are normally impemented by the underlying 
operating system allowing them to spread over multiple cpus (while still 
being able to easily talk to each other).  The multi-task capability of 
Java programs is getting more and more important as modern CPU's get 
more and more cores which - I understand - is not as easily done from 
with C or other programming languages on the i.

Due to the bulk of the JVM the small programs get quite a head start but 
in the really long run the JVM catches up.  Much like bulk carrier ships 
where you really need to go across oceans to beat small ships but do not 
want to use them for habor ferries.

> Which begs the question, are we really doing CGI programming, or do we
> just call it that because it sort of feels like it?
CGI refers to the original way to call external programs from the 
webserver process and getting the result back.  It originates on Unix 
where this usually means forking a process which is a somewhat expensive 
operation especially for small programs, and several means was quickly 
found to essentially allow the webserver to pull in external code 
snippets for execution.  This is, however, web server specific.

If the CGI implementation on the i keeps prestarted jobs for this exact 
purpose, the overhead from process invocation is most likely negleticble 
and the penalty for doing so is suitable small.  This should also allow 
for quite good scalability on a single box.

In the Java world the code snippets are called servlets and are standard 
(instead of webserver dependent) which has caused this approach to be 
almost universally adopted.