are zend engine globals share memory across processes?

Question

I've been going through PHP's source code and the mysql_pconnect function and noticed it's using some kind of HashTable persistent_list which is defined in zend_globals.

The question is, how are this globals and variables are preserved across requests when PHP is set as mod apache/fcgi. If it's a new PHP process spawned for every request those variables should not be preserved.

Answer 1

The question is, how are this globals and variables are preserved across requests when PHP is set as mod apache/fcgi.

As apache module, they are shared because apache httpd itself is still running. That running process had spawned PHP and will spawn other PHPs in the future. As the child threads can relate to their parent, it can and is stored in the parents memory space.

As FCGI, this could be technically possible as long as the binary is already running, however this has not been implemented with the FPM. I would also say, it makes no real sense for FCGI, too, because it's per script and also timeouts are involved, so the life-span is much shorter as with the whole webserver.

Answer 2

PHP-FPM reuses contexts, allowing persistent connections to work in FCGI. Something to consdier though is PHP-FPM initially creates more than one process, so you still end up with multiple connections, one for each process or context.

Something to consider is, "persistent connections do more harm than good" is a sentence said a LOT in #php.pecl. The overhead of connecting is light, and PHP lends itself to this kind of processing. In languages that are designed to run constantly the overhead of connecting might be greater ( usually because, simply connecting impacts many more objects than the one the prorgram is directly manipulating ), so a persistent or pooled connection makes sense. PHP is designed to do everything as quickly as it can and to hell with how much resources it uses doing it - everything has to run in around 250ms - connecting to mysql doesn't fire a bunch of hooks throughout the framework as it might in other languages, so the overhead is very small. Additionally, a persistent connection for each process does not amount to a pool of managed connections like it might in other languages, if the receiving machine does not have it's mysql instance configured ( with ridiculous settings ) then the connections will go stale and upon *_pconnect PHP has to first invalidate the old connection before creating a new one, which is less efficient and slower than just creating a new connection to begin with.