Where did you learn how all these innards work? Not that I don't believe
you, but the part about the second Apache server instance has me curious.
Also, when I am running RPG there is a lot of complexity going on under the
covers that I am not concerned with. I wonder if the PHP circle of
execution is the same in that the implemented it so it is very robust and
wont break. Seems like a lot of moving parts just to make PHP work on the
i5. I suppose they did that so they could get to market faster and not have
to rely on IBM (or Zend) to change code for each release that is specific to
IBM. Who knows, maybe that time to "do it right" wasn't taken in the first
approach so they could test the market and see how many people really want
to run PHP on the i5. Going to Lukas Beelers point, why the i5 if you don't
already have i5 in-house?
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [
mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Nathan Andelin
Sent: Tuesday, June 05, 2007 5:19 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Recommendations of web development
architecture/toolfor diverse i5 access...
Dave O. wrote:
Nathan, you're great. Just what I thought.
i5-PHP architecture is rather complex. Browser requests are first received
by an instance of the i5 Apache based HTTP server running under the native
virtual machine. Then an HTTP server plug-in forwards PHP requests to
another job which is hosting an instance of PASE along with another instance
(and version) of Apache supported under PASE, which forwards the request to
one or more CGI server jobs, each of which are hosting their own instance of
PASE and their own instance of PHP.
PASE and PHP are fairly robust virtual machines, where PHP is an
interpretive runtime environment for scripts. It's likely that PHP scripts
will instantiate one or more database connections, each of which will likely
launch a corresponding DB server job. The flow-chart looks like:
Job # 1: Apache based server (native virtual machine) -> Job # 2: Apache
server (PASE virtual machine) -> Job # 3: PHP server (PASE virtual machine)
-> Job # 4: DB server (native virtual machine)
so at least four (4) jobs are servicing each browser/database request.
I suspect Job #3 is a behemoth because it's running 2 virtual machines (PASE
and PHP).
If one instance of Job #3 is busy when a new request arrives, the request
will be routed to the next available instance, according to the CGI
specification.
The runtime environment of PHP must be big. It's so robust. A script might
be simple, but the runtime environment isn't.
Say you deploy a product of 500 scripts. The runtime engine loads each one
into memory as they're requested, and probably uses some algorithm for
swapping them in and out of memory according to use. Over time, on a busy
server, each instance of the PHP runtime jobs will likely load each script
into memory. Some architects would call that a memory leak.
The part where developers have control is in the architecture of their
scripts, but robust applications might use Model-View-Controller, HTML
template, DB connection pooling, object-relational mapping frameworks, and
so forth. The design can get rather complex.
Nathan.
midrange.com
