On 9/26/2012 11:23 AM, Maciej Liżewski wrote:
Well.. many things changed during last 30 years. Cobol is not
mainstream, we have got OOP, Java, Python, Ruby, Google and other
great things :)

I am talking about stateful application server. There are plenty
examples in other programming languages: Java has Jetty, Tomcat, Ruby
On Rails, Python and Passenger WSGI.
All of them have one common thing: application persist in memory
between requests. Even for interpreted languages (such Ruby) - this
has advantage of loading sources only once, parse it only once and
initialize memory structures for those definitions only once. On the
opposite - PHP loads EVERY single resource on every request. This is
why it needs op-code cachers, accelerators etc.
Another advantage of using stateful application servers is that you
can simply keep gloabal state of your application (global variables,
static object properties) in memory. It simplifies many tasks which in
PHP require sessions, writing files with serialized data and
deserialize them on every request...

Just imagine such scenarios:
now PHP acts like this on every request:
  1. locate resources (source files in this case), parse and load them
(possibly with op-code cache)
  2. initialize global context ($_SERVER, $GLOBALS, $_POST, $_GET, etc)
  3. run code
  4. destroy all resource and free memory for next request

persistent application servers load resources only on startup (or when
needed) and keep them in memory until programatically freed or until
end of application (server shutdown). So every request looks like
  1. initialize global context
  2. run already parsed code

is that makes whole thing clear?

Another nice example - simple counter. In PHP you have to:
1. read file with counter
2. increment value
3. write serialized value to file
...on every request.

in Java (for example) you just write class:
class Counter {
   static private counter = 0;

   public void increment() {

and because class definition persists in application server - static
member is maintained between requests and whole things works as

2012/9/26 Jim Giner <jim.gi...@albanyhandball.com>:
On 9/26/2012 5:58 AM, Maciej Liżewski wrote:


Maybe this topic have been already on board, but I could not find nothing
in google, so my question to PHP maintaneers (and other users too) is:

Why there is no possibility to run PHP in "application server" way among
other SAPI modules and other possibilities to run PHP? PHP would encounter
great performance boost and became more "enterprise" :) Just look at Ruby
which is slow as hell compared even with PHP.

By "application server" I mean scenario when there is statefull
on server side not only by session mechanizms but all classes definitions
maintained in memory (no need to load class definition on every request),
static class members (and their changes) persistent, background threads,
etc. This way any op-code cachers won't be necessary...

sounds great, huh? others have it already, so why doesn't PHP? are there
any cons? problems too hard to solve (one can be memory leaks, thread safe
coding, etc)? I mean it - I am realy curious why there is no such
possibility and is there any hope we could get it?

TIA for any answers on this topic.

Thirty+ years as a professional application designer, developer and manager
and I don't have a clue about what you are proposing.  I must have been in a
different world.  :)

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Sounds to me like you'd need more hardware to support such a concept. I realize that memory can be mapped to disk to avoid the need to have HUGE amounts of ram in your server(S!) but with ever-increasing processor speed, is it really necessary to go this route?

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to