We're experiencing bottlenecks in our performance testing which we narrowed down the lock wait in xmemcached plugin.
We tried switching to spymemcached, but it didn't make a significant difference.
Upon further investigation we uncovered an unexpectedly large amount of L2 cache activity, most of which are for JDO classes which are marked as cacheable=false in the metadata.
It looks like the cache puts are guarded by cacheable=false, but not the gets.
If this is not intended or otherwise necessary, could the code be optimized to assume a cache miss if the class is not cacheable?
We made a test case we will be uploading.