significant release of the in-memory data caching system , which operates on data in key/value format and is easy to use. Memcached is usually used as a lightweight solution to speed up high-load sites by caching access to the DBMS and intermediate data. Code under the BSD license.
The new version stabilizes the implementation of the storage "", which is now built by default (to disable in the configure script, the option "-disable-extstore" is provided), but requires explicit activation at startup (old installations will continue to work without changes after the update). Although extstore is generally considered to be stable, caution is advised when implementing it on very large systems.
Extstore allows you to use SSD/Flash drives to expand the cache size. As with RAM, Flash storage is not permanent and is reset upon restart. The scope of the new mode is to ensure efficient caching of large data. When using "extstore", keys and metadata are, as before, stored only in RAM, but large data associated with keys, the size of which exceeds a set threshold, is stored in external storage, and only the pointer remains in RAM.
If the key is associated with small data, then Memcached works as usual, keeps the data in memory and does not access external storage. If there is a lot of free memory, then the most needed data can additionally be completely located in the cache in RAM (for example, you can specify that only objects larger than 1024 bytes that have not been accessed for 3600 seconds are reset to Flash).
The implementation is optimized to ensure maximum performance and minimal CPU load, at the expense of storage efficiency (high level of fragmentation). To extend the life of Flash drives, data is buffered and flushed to storage sequentially. To save the cache state between restarts, you can use the ability that appeared in release 1.5.18 to dump a cache dump to a file. At the next startup, you can restore the cache from this file to eliminate peaks in the load on content processors due to the cache being empty (the cache immediately becomes βwarmβ).
The second important change in Memcached 1.6 was the reworking of the network communication code, which is adapted to automatically process batch requests within a single system call. Previously, when sending multiple GET commands in a single TCP packet, memcached would send the results with separate system calls. In Memcached 1.6, responses are aggregated and returned by sending a single system call. As a result, there is now an average of 1.5 keys per system call, which in tests demonstrates a reduction in CPU load by up to 25% and a reduction in latency by several percent.
The redesign of the network subsystem also made it possible to move to dynamic allocation of buffers as needed, instead of statically assigning buffers. This optimization reduced memory consumption while waiting for new commands through a client-established connection from 4.5 KB to 400-500 bytes, and also made it possible to get rid of many calls to malloc, realloc and free, which lead to unnecessary memory fragmentation on systems with a large number of connections. Each worker thread now handles its own pool of read and write buffers for active client connections. To adjust the size of these buffers
the options β-o resp_obj_mem_limit=Nβ and β-o read_buf_mem_limt=Nβ are provided.
Branch 1.6 also announced the deprecation of interaction with the server. Binary protocol maintenance and bug fixes will continue, but new features and updates to existing features will not be ported. will continue to develop without changes. The binary protocol has been replaced by a new protocol (a text version of the protocol with compact meta-commands), demonstrating the optimal combination of performance and reliability. The new protocol covers all operations previously available through text and binary protocols.
Source: opennet.ru