Performance of serialization

Problem/Motivation

When the cache data amount increases, the cache API becomes a bottle-neck, due to network delays and issues in D7/8 core with cache item size (that leads to cache item splitting, from memcache version 1.5+, or worse - permanent miss, before it).

Currently using the memcahce demon with max item size 8 MB with the idea to lower the cases where item splitting will cause overhead in PHP.
All servers are using 1GB NICs.

I have pages on a portal that report this ranges from xhprof:

MemcachePool::get
count: 84
wall time (s): 0.3-0.6
wall time (%): 15-25
wall memory (bytes): 40-75m
wall memory (%): 20-45

TOP 7 cache_get offenders on a sample page can be seen in the attached XHProf screenshot.
They are slow only due to data (huge menus, many fields, many tables, multilingual (15 languages), etc.).
The delay is co-related with item size and thus network.

Proposed resolution

There is a PHP extension called igbinary that provides serialization primitives that are reported as faster and to also produce better results in terms of serialized size. In the redis issue (https://www.drupal.org/node/2143149) there are many testing scripts that prove this roughly 2x improved item size and parse speeds with the cost of about 10% serialization overhead. There is also this: https://www.drupal.org/project/igbinary_cache for inspiration.

So if we add a layer that will be configurable in the settings.php that will allow the usage of igbinary_(un)serialize instead of the (un)serialize that is used now. This should lead to better memory utilization of memcache storage space + better networking times for transferring the information to the web-servers.

It might be something very simple like $conf['memcache_(de)serializer'] = '(un)serialize'; in the default case and allow the use of $conf['memcache_(de)serializer'] = 'igbinary_(un)serialize';.

Maybe - add a run-time requirement check for the extension (and PHP versions) and also update docks accordingly at some point.
Note that the extension support for PHP 7 is still under development.

Site that is switching between to the available storage encoding primitives will have to sacrifice old cached data in the clusters.

Remaining tasks

POC patch / discussion, benchmarks, final patch, RTBC, commit.

User interface changes

None.

API changes

API addition - new configuration, old installs will not be affected, as they will use the serialize/unserialize default (as it is now).

Data model changes

None.