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

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.