It's been over 2 years since support for using eAccelerator to cache the datasore was removed. Does the current version (9.5.2) still have the same issue that caused it to be removed:
Changes in this version (from 0.9.4):
- This version brings full php 5.1 support, which has as side-effect that eAccelerator won't work anymore with php 4 on windows, but on other platforms this isn't a problem.
- The shared memory functions, session handler and content cache are disabled by default now. They are only used by a small amount of users and they could allow local users to fill up the memory, if they aren't secured properly.
- The old web control panel and the disassembler have been removed from the code. They have been replaced with a set of php functions that allow the same functionality to be implemented in a PHP script. The control.php and the dasm.php files are such scripts. More information about this can be found in the README.
- Memory footprint should be reduced because redundant information in the cached scripts is no longer stored. Keeping this information cached can be done with --with-eaccelerator-doc-comment-inclusion
- File hashing in the cache directory has been added to improve performance with a large amount of cache files.
Unfortunately, due to a design issue with eAccelerator
we must disable this module at this time.
The reason for this is that eAccelerator does not distinguish
between memory allocated for cached scripts and memory allocated
as shared memory storage.
Therefore, the possibility exists for the administrator to turn
off the board, which would then instruct eAccelerator to update
its cache of the datastore. However, if the memory allocated is
insufficient to store the new version of the datastore due to
being filled with cached scripts, this will not be performed
successfully, resulting in the OLD version of the datastore
remaining, with the net result that the board does NOT turn off
until the web server is restarted (which refreshes the shared
memory)
This problem affects anything read from the datastore, including
the forumcache, the options cache, the usergroup cache, smilies,
bbcodes, post icons...
As a result we have no alternative but to totally disable the
eAccelerator datastore module at this time. If at some point in
the future this design issue is resolved, we will re-enable it.
We still recommend running eAccelerator with PHP due to the huge
performance benefits, but at this time it is not viable to use
it for datastore cacheing. - Kier
we must disable this module at this time.
The reason for this is that eAccelerator does not distinguish
between memory allocated for cached scripts and memory allocated
as shared memory storage.
Therefore, the possibility exists for the administrator to turn
off the board, which would then instruct eAccelerator to update
its cache of the datastore. However, if the memory allocated is
insufficient to store the new version of the datastore due to
being filled with cached scripts, this will not be performed
successfully, resulting in the OLD version of the datastore
remaining, with the net result that the board does NOT turn off
until the web server is restarted (which refreshes the shared
memory)
This problem affects anything read from the datastore, including
the forumcache, the options cache, the usergroup cache, smilies,
bbcodes, post icons...
As a result we have no alternative but to totally disable the
eAccelerator datastore module at this time. If at some point in
the future this design issue is resolved, we will re-enable it.
We still recommend running eAccelerator with PHP due to the huge
performance benefits, but at this time it is not viable to use
it for datastore cacheing. - Kier
Comment