After writing a test module with logging to see just when the module does get loaded and unloaded, it appears the module gets loaded on server startup, once for each apache thread, and shutdown when a child terminates or the server shuts down, at least for PHP 4.3.7 as a DSO on Apache 2.
As shown in 그림 26-1 above, PHP can be extended primarily at three points: external modules, built-in modules, and the Zend engine. The following sections discuss these options.
External modules can be loaded at script runtime using the function dl(). This function loads a shared object from disk and makes its functionality available to the script to which it's being bound. After the script is terminated, the external module is discarded from memory. This method has both advantages and disadvantages, as described in the following table:
|External modules don't require recompiling of PHP.||The shared objects need to be loaded every time a script is being executed (every hit), which is very slow.|
|The size of PHP remains small by "outsourcing" certain functionality.||External additional files clutter up the disk.|
|Every script that wants to use an external module's functionality has to specifically include a call to dl(), or the extension tag in php.ini needs to be modified (which is not always a suitable solution).|
Third parties might consider using the extension tag in php.ini to create additional external modules to PHP. These external modules are completely detached from the main package, which is a very handy feature in commercial environments. Commercial distributors can simply ship disks or archives containing only their additional modules, without the need to create fixed and solid PHP binaries that don't allow other modules to be bound to them.
Listing extensions in php.ini shouldnt avoid reloading the module each time the php script runs. Module startup and shutdown function calls shows that.
Creating dynamic extensions and listing them in your php.ini file should eliminate the overhead of having to issue a call to dl() on every script. Taking this approach gives you the benefit of a separate module without the performance hit.