Todos APC 4.0

Task Status Schedule Contributors Description
Multiple cache support Done 4.0.0a shire Rework configuration , code, and apc.php, and API to support multiple user and file caches. INI configuration will not require changes as part of the 3.x->4.x upgrade path, however the API will not require any changes unless multiple user caches or file caches need to be specified. Some changes may be necessary for the apc_cache_info() functionality.
Plug-able Expunge Methods In-Progress 4.0.0a shire Add ability to easily switch out and configure different expunge methods on the C level, consider PHP space
LFU Expunge In-Progress 4.0.0a shire Add Least Frequently Used Expunge method
None Expunge Done 4.0.0a shire Add “None” Expunge option to fail on new inserts rather than expunging entries
CSV Export Done 4.0.0a lucas, shire Add ability to dump CSV cache values from the apc.php browse page
Moving window statistics In-Progress 4.0.0a shire Add generic window statistics tracking mostly for use with the apc.php page. ie: hit/miss rates etc
Windows Compatability In-Progress 4.0.0a kalle, pierre, shire Ensure we have windows compatability and testing
mmap replacement for windows ?? ?? pierre, kalle Implement a replacement for mmap on windows
TSRMLS_FETCH() In-Progress 4.0.0a shire, kalle Remove as many TSRMLS_FETCH() calls as possible or in perf. critical regions to improve TS performance.
Documentation Not Started 4.0.0a shire Need to update documentation both in code (TECHNOTES) as well as in the official PHP documentation (location?) or wiki so users know about changes and can better get up to speed with APC. Should also put together an upgrade quickstart guide.
apc.php cleanup Not Started 4.0.0b shire apc.php page still needs lots of fixing, additional features etc. If you're interested in helping I have a detaild list ;-)
on-disk cache (.phpc) In-Progress/Experimental 4.0.0b shire Ability to dump compiled opcodes to disk per file (ie: .phpc files) so large code-bases such as CLI can get a speed improvement, as well as being able to distribute .phpc files as part of a push process to production servers so source code isn't on the remote machine.
Spin-lock stabalization In-Progress 4.0.0b shire Spin locks are stable except for a signal handling problem in Zend. A patch has been prepared and needs to be tested/integrated into a PHP release. We need to test further on windows, finalize the patch, and get it into core. If this will be delayed including a patch with APC may be useful for some looking to get gains from this.
Windows locking Not Started 4.0.0b shire, pierre, kalle Sounds like we need to look at our options for windows locking so we have a good, stable, efficient option that works on both Win and Unix flavors. Spin locks would be my first choice, but we need testing of support on windows and improvement of the signal handling problem for stability.
Virtual Host/Location In-Progress/Partial 4.0.0a shire With multiple cache support, the idea of separating files or user cache values based upon the virtual host or location became easier to support. Add a location or virtual host option to the per-cache configuration, essentially what the file cache filters option currently supports on the 4.x branch. This will automatically limit or direct file/user entries to the appropriate cache.
Hash stats/improve file hash Not started 4.0.0b shire We currently don't have stats for our hash collisions/performance, so we should add some stats that can be enabled/disabled here without affecting performance. We should then eval. the performance of the hash() function used for file device/inode and see if it should be more robust or if it's current performance is acceptable


Task Status Schedule Contributors Description
Multi-Server synchronization Researh n/a shire If we could determine an acceptable behavior it would be advantageous to have a multiple-server synchronization either directly between APC installs, or more likely to some backend server such as memcached. This would allow, for example, taking the top-X hits from memcached and placing them in an APC cache. This scenario would probably also require a write-thru to memcached or other back-end.
Key Groups Researh n/a shire There are two lines of thought with grouping keys in APC, one is a high level multiple-cache grouping where each cache serves as a pool of keys for seperation/expunge purposes. Another options it have a lower-level grouping within the cache that controls behavior such as priority in an LFU list or to control items all falling out of the cache at the same type if they are associated. ie: if X is expunged also remove cache items A, B, and C. One way to obtain this behavior is through cache key prefixes. A more advanced API is alos an option, but it's less visible and will only further complicate the API. It also remains to be seen if this will be necessary with multiple-cache support in place.
no-copy Research/In-Dev n/a shire Currently we spend much effort copying values out of the cache and making sure we don't cause corruption into shared memory when opcode data is written to etc. Ideally we would reference the shared memory directly, and remove the cost of copying, especially for user variables that may never actual be modified. By modifying both Zend and APC we can create a no-refcount flag for zvals that disables both refcount inc/dec race conditions and forces copy-on-write behavior. This would also remove the need for other optimizations such as Lazy-loading, as this behavior would be more efficient.
Phar integration Not Started n/a shire Phar integration with apc_bindump API would be nice
Memory usage Not Started n/a shire Currently memory usage per key is pretty significant, we should investigate ways to improve this
Binary Serialization Not Started n/a shire Currently we do a very logic based copy of data in APC, with allocations per struct, and memory pointers that are not sequential. Ideally every key's data would be sequential and could be compressed and de-serialized by unswizzling pointers rather than re-creating the structures in process memory. This is related in ways to pool allocation, as well as possibly conflicting with memory fragmentation and no-copy optimization
fine-grained locking Needs verification/testing n/a shire Locks are current per-cache, we've already optimized locks down to pthread locks and spin locks which have very good performance, so the next level optimization would be either lock-free algorithms or finer-grained locking (or some combination of both). A patch has been developed for per-slot based locking, however my tests have yet to prove that this can provide any substantial performance gains. This should be-reverfied.
pecl/apc/todo/40.txt · Last modified: 2017/09/22 13:28 by