PHP Application Server

For a long time, I've been thinking about performance issues in PHP. One of the things that distinguishes PHP from other web-dev languages, is that PHP architecture is build around the "share nothing" concept.  Practically, it means that whenever a user opens a request to the server, a new PHP process is invoked which retains a distinct "user-space" environment. No matter how hard you try, memory of one PHP process is never shared with another process. This allows the developer to focus on developing the app for one user at a time and not worry about scalability.
Though simple and strait-forward, this concept is also very wasteful in terms of performance. Every user access requires a new PHP process, which then loads all necessary function and classes, connect to DBs and other resources and perform similar bootstrap and termination tasks. 
This has already been approached by some firms and individuals, creating acceleration layers on top of PHP that basically cache the compiled PHP files in RAM thus allows PHP scripts to run without the need to recompile the sources over and over again. Those tools are known to boost performance dramatically in a starting factor of 3. See here and here.
This is awesome!
But still something is missing...Even when accelerating PHP apps, including function and classes and other bootstrapping processes still cost execution time. 
In an attempt to deal with this situation, I've created a tiny project called PHP Application Server (PHAS). This aims to simulate an application server, a concept that is heavily used in other platforms such as J2EE, .NET and others. App servers are mainly into computation and performance. Their whole purpose is to execute the app itself as fast as possible and return a result to the requester.
The whole idea with PHAS is to launch a PHP process, include all needed function and classes, execute all required bootstrapping and wait for requests. When a request finally arrives, it executes only that specific task, return the result and waits for a new request. 
More specifically, this is how it works:

  1. First, the "Server" is launched, which then launched "Workers" that listen on a queue (Gearman).
  2. A worker that boots automatically execute the "bootstrapping" section in the user's app. This section should include classes and functions loading, DB connections and other "one-time" tasks.
  3. A new request arrives on the "entrance" or "gateway" script which pushes the request into the queue.
  4. One worker pulls the request from the queue, creates a "Virtual Environment" in preparation to running the user's app and launches the app. 
  5. The result of the user's app is transferred back to the "entrance" script which echos it to the HTTP response. 

Surprisingly, this actually works... More astonishing fact is that it boosts performance by a starting factor of 4!
I hope to have some real benchmarking soon... I would appreciate if someone could spare an example scripts, preferably "heavy" scripts with lots of functions\classes, to benchmark on.
I invite you to read more about it here: