caching - APC with TYPO3: high fragmentation over time -
using apcu typo3 6.2 extensively, high fragmentation of cache on time. had values of 99% smaller shm_size.
in case typo3 admin, switched caches cache_pagesection
, cache_hash
, cache_pages
(currently testing purposes moved db again), cache_rootline
, extbase_reflection
, extbase_opject
other extension caches apc backend. switching cache_hash
away db sped menu rendering times dramatically (https://forge.typo3.org/issues/57953)
1) apc fragmentation matter @ or should watch out never runs out of memory?
2) typo3 admins: happen have idea tables cause fragmentation , bit in apcu.ini configuration relevant usage typo3?
i tried using
apc.stat = 0
,apc.user_ttl = 0
,apc.ttl = 0
(as in t3 caching guide http://docs.typo3.org/typo3cms/coreapireference/cachingframework/frontendsbackends/index.html#caching-backend-apc) , increaseshm_size
(currently @ 512m around 100m used). shm_size job @ reducing fragmentation, i'd rather have smaller full cache large 1 unused.
3) apc(u) admins: updating cache entries change in size cause of fragmentation? or there other misconfiguration i'm unaware of?
i know there lot of entries in cache (mainly json data remote servers) of them update every 5 minutes , different size each time. if indeed cause, how can avoid it? btw: apcu info shows there lot of entries taking 2kb each fragmented spacing of 200 bytes.
4) typo3 , apc admins: apc has great integration in typo3, more updating , many small entries, advise different cache backend apc?
this no longer relevant us, found different solution reverting mysql cache. though if comes here via search, how did in end:
leave apc cache alone , use preconfigured extbase_object
cache. 1 less 1mb, has few inserts @ beginning , yields high hit / miss ratio after. stated in install tool in section "configuration presets", cache backend has been designed for.
i discovered bug https://forge.typo3.org/issues/59587 in process , reviewed our cache usage again. resulted in huge cache entries used tag-to-ident-mappings. conclusion is, after trying out fixed cache, apcu great storing accessed key-value mappings yields when lot of inserted or tagged entries around (such cache_hash
or cache_pages
).
right now, mysql cache tables have better performance extended usage of mysql server memory cache (but in contrast apcu disc backup). magic setup our my.cnf (found here: http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/):
innodb_buffer_pool_size = 512m innodb_log_file_size = 256m innodb_log_buffer_size = 8m innodb_flush_log_at_trx_commit = 2 innodb_thread_concurrency = 8 innodb_flush_method=o_direct innodb_file_per_table
with additional mysql server setup, default typo3 cache tables job best.
Comments
Post a Comment