Re: Recommendations of web development architecture/tool for 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.