Cache hit rate dropped from 98% to ~70% after 1.10 => 1.11 upgrade

Thanks for the data but this number by itself doesn't mean too much. That release introduces some new caching for i18n strings and it is possible that it just made your cache hit some limit.

If you can share more data on which are the cache misses, etc, that would be nice.

I can confirm performance issues on node/add in secondary language, about 3x more time.
reverting to 1.10 fixes the issue

Ok, so we'll assume it was the new caching introduced in 7.x-1.11

It may be related to this one.. #2431017: Cache non translated strings

That should be fixed in next release.

We see something similar (thousands of cache_get()'s that never have anything "set"). On our site, we see something close to 25/sec cache_get()'s that "miss" (an active site with 5 languages enabled). We use memcached and the keys that are missing look like:
i18n:string:obj:menu:item:167725:title

The patch mentioned above caches textgroup's but not objects.

Is this intended? Why do we make so many cache_get()'s, never expecting to get anything back?
(Running 7.x-1.14)

@gwynnebaer, can you please try the patch 1 from this related issue:

#2431017: Cache non translated strings

if this helps , please report back your findings.

between 7.x-1.10 and 7.x-1.11 this issue was included, lots of new cache functions. Performance profiling would have to be done to compare the difference to see whether an actual improvement was made here.
#776146: A simple cache for i18nstrings_cache() to reduce queries

so I'm not sure if 7.x-1.11 was an actual performance improvement (or degregation).

However 7.x-1.12 introduced a table index , this was in all likelihood more of drastic improvement than the cache changes (or cache regressions depending on what a performance profiling analysis with xhprof would say), maybe compensated for what was added to 7.x-1.11

#1940532: Missing database index in locales_source for textgroup and context

if you really want to be a performance guru, you need to set up xhprof , a php performance profiling utility heavily improved by facebook engineers, it only works on Linux (or maybe mac) but if you're on windows, no xhprof for windows and if there is, good luck getting windows to work with xhprof.

The patch does not change the behavior for our site. I can run xhprof but what am I looking for?

With xhprof you are looking at latency stats, number of function calls, and if you have configured the image UT put it will highlight your bottleneck in a big red box , each box represents a function and lines to and from callers.

Essentially you run the xhprof before and after patching and compare statistics, this will tell you right away if the performance is improved or degraded before and after patch or code changes