4 ms·

This has been PHP’s approach to memory management during its best decades. It’s a fantastic idea for short-running processes, which there should be more of anyw

This has been PHP’s approach to memory management during its best decades. It’s a fantastic idea for short-running processes, which there should be more of anyway.

tonyedgecombe 3y ago
Are you saying PHP creates a new process for each request?
- SPascareli13 3y ago
  It's been a while since I used PHP, but this is something controlled by the server used. If you use Apache then it used to create a new process for each request, yes.
  - zokier 3y ago
    Even in the classic prefork model (and mod_php), Apache did recycle worker processes. Only CGI operated on this new process for each request.
- jbboehr 3y ago
  It depends on the SAPI. The php-fpm approach is a pool of processes that are reused for multiple requests. Virtually all of the state visible to plain PHP code is reset between requests, however some interpreter/runtime state is kept, e.g. in-memory bytecode cache, initialized extensions, some persistent network connections, etc. In terms of memory management, PHP has both reference counting and garbage collection. Internally, an arena per request is used[0], so leaking memory over long periods of time is fairly rare and usually limited to native extensions. [0]: https://www.phpinternalsbook.com/php7/memory_management/zend_memory_manager.html https://www.phpinternalsbook.com/php7/memory_management/zend...
- skrebbel 3y ago
  Depends on the setup, but even when it doesn't, it mallocs a huge chunk of memory at the start, lets the script run, allocate away and never free anything. Then, when the script is done, it frees the whole chunk in one fell swoop. So for some definition of “process” it holds regardless - it’s just not always a real OS process. They added GC at some point to allow scripts to run longer (eg for websocket servers) but even then last I checked you had to manually enable it.
- pjmlp 3y ago
  Depending on the configuration, yes. It used to be a quite common approach in UNIX server programming.

This has been PHP’s approach to memory management during its best decades. It’s a fantastic idea for short-running processes, which there should be more of anyway.

tonyedgecombe 3y ago

Are you saying PHP creates a new process for each request?

SPascareli13 3y ago
It's been a while since I used PHP, but this is something controlled by the server used. If you use Apache then it used to create a new process for each request, yes.
- zokier 3y ago
  Even in the classic prefork model (and mod_php), Apache did recycle worker processes. Only CGI operated on this new process for each request.
jbboehr 3y ago
It depends on the SAPI. The php-fpm approach is a pool of processes that are reused for multiple requests. Virtually all of the state visible to plain PHP code is reset between requests, however some interpreter/runtime state is kept, e.g. in-memory bytecode cache, initialized extensions, some persistent network connections, etc. In terms of memory management, PHP has both reference counting and garbage collection. Internally, an arena per request is used[0], so leaking memory over long periods of time is fairly rare and usually limited to native extensions. [0]: https://www.phpinternalsbook.com/php7/memory_management/zend_memory_manager.html https://www.phpinternalsbook.com/php7/memory_management/zend...
skrebbel 3y ago
Depends on the setup, but even when it doesn't, it mallocs a huge chunk of memory at the start, lets the script run, allocate away and never free anything. Then, when the script is done, it frees the whole chunk in one fell swoop. So for some definition of “process” it holds regardless - it’s just not always a real OS process. They added GC at some point to allow scripts to run longer (eg for websocket servers) but even then last I checked you had to manually enable it.
pjmlp 3y ago
Depending on the configuration, yes. It used to be a quite common approach in UNIX server programming.