Do not nest sub USER_INT objects within your cached USER objects. This will fail because needed information in $GLOBALS['TSFE']->config['INTincScript'] will not be given if content elements with sub-USER_INT's are retrieved from enetcache. If USER_INT's are needed within cached plugins, this must be handled by the plugin itself, probably by building differential arrays of parts of TSFE->config at the beginning and end of the plugin, caching those information and injecting explicitly after successful get.
If using excessive tagging, the 4.3 caching framework backends “memcacheBackend” and “apcBackend” for enet_cache and cache_pages tend to be very slow. This is an architectural problem and will hardly ever change. See http://bugs.typo3.org/view.php?id=12562 for more information on this topic. We had good results with “dbBackend” for enet_cache and cache_pages (default configuration). “fileBackend” might perform well too, but is currently untested by us. We appreciate any feedback on this topic as fileBackend in a RAM disk should theoretically perform very well.
Every tag triggers one INSERT call using “db” as cache backend. This is a missing feature in t3lib_db and reported in the bugtracker at http://bugs.typo3.org/view.php?id=12858 and http://bugs.typo3.org/view.php?id=12859. We are working on an integration of patches for TYPO3 4.4.enetcache already delivers the patch files in its patches/ directory (they apply to 4.3.0), you could choose to hack your TYPO3 source to take advantage of this feature.Warnings: Those patches are experimental and the final solution committed to the next major TYPO3 version will probably change until it is accepted. The patches might even change with new enetcache versions. Furthermore the patches are not DBAL compatible, but it's probably a good idea to not run cache tables through dbal, anyway. Our tests showed some good performance boosts when many tags are inserted, enetcache comes with two test cases to show this.
The current dbBackend uses sub-selects when deleting cache entries by tags. Sub-selects in mysql are very slow because mysql is unable to use keys for the outer query. This issue is handled with core patch #13273, we recommend to apply this patch when using dbBackend or compressedDbBackend, it will give a huge performance boost for reasonable big tables.
enetcache is not aware of starttime / endtime handling of records. If this feature is used, the lifetime given to set() must be handled in the calling plugin.
We are currently unsure if enetcache handles TS config.cache_clearAtMidnight correctly (probably not). If lifetime handling is done right, this TYOP3 core feature is not needed anyway.
