what about using shared memory?

http://www.php.net/manual/en/ref.sem.php
http://www.php.net/manual/en/ref.shmop.php

Thinking at Shared memory data-interchaning comes to my mind. (OK SSJS can interchange data via the project-variable. But, at leat in our project, i can't see the point for this.)

For our project a global and persistent variable is important for SPPPPPEEEEEDDDDDD (and cost. We don't have to buy more frontend-machines to compensate the performance losse of PHP compared to SSJS). Having to parse the configuration for every request just kills the performance.

I'm suprised why something along these lines isn't incorporated into PHP such that there's an application process that could handle application scope variables (and query caching). It seems this kind of issue would make it match up better with ASP and Cold Fusion. Is anyone aware of such an effort?

2004 and still nothing showing up for this issue.  I am a newbie, but even I (less than one month of PHP experience) understand the importance of this issue.  One could do something with shared memory and msession, but these solutions are overkill for small projects (and shared memory does not work on Windows).  What we need is a simple global array named $_PERSISTENT.  Anything stored in this array lives until unset or the server goes down.

And as for the implementation, can't this be done easily?  I mean, $_SESSION exists already and the only difference between $_SESSION and $_PERSISTENT is that $_SESSION is associated with a session (cookie or URL based).  Just reuse the same code for $_SESSION, but without the user association code and voilà, a new feature is born.

$_PERSISTENT would be so intuitive to use to newbies, as $_SESSION is.

I agree that a persistent variable functionality would 
be useful; however, this does require an additional 
level of configuration to allow ISPs soem leeway in how 
this is deployed;
a) availabilty of feature AT ALL determined by 
configuration
b) separate scopes for different applications (as 
several may be running on the same server and there 
needs to be some way to prevent collision); these 
scopes may be determined by name (low inter-application 
security), automatically by domain/URL path (higher 
security) or by some other means
c) timeout periods (i.e. how often the application 
variables need to be refreshed) need to be determined 
on a per-server, per-application basis
d) some sort of locking mechanism to prevent corruption 
issues during writing (assuming that multiple 
concurrent PHP requests have similar shared-memory 
issues to concurrent threads); this could be automatic 
and/or manual, depending on performance needs...

The various opcode caches tend to implement this.  mmcache and ZPS have ways to do this easily.  And I will be submitting a patch to pecl/apc to support this as well shortly.  That is, you can do:

  $var = apc_fetch('var');

And:

  apc_store('var',$var);

We definitely don't want PHP to require a standalone marshalling process as someone suggested and as someone else suggested, no, the $_SESSION code is nothing like what would be needed for this.

The main argument against using something like this is that your horizontal scalability is destroyed if you use it incorrectly.  Ideally you want to architect your solution such that every request is sandboxed from every other so that you can handle an entire browsing session on any of dozens of servers behind a load balancer, for example.  If you store state on a single machine like this, much like many Java apps do by storing state in the JVM, then you have a scalability nightmare on your hands.

By the way, if it is just read-only config file key/value type stuff you are worried about, you can use cfg_get_var() to read custom .ini directives that will only be read on startup.  With the new --with-config-file-scan-dir mechanism you can even configure a directory that will be scanned for ini files, so every application that needs config entries can simply drop their config ini file in that dir and the configuration will be read once on server startup.

PHP has a shared-nothing architecture on purpose. Adding global variables introduces locking issues, issues when scaling to multiple machines etc. apc_store()/apc_fetch() or memcache as well as others provide solutions depending on your environment and needs.