EZP-29659: As a v2 Cluster Admin & Developer I want support for InMemory SPI cache

[andrerom]

Question	Answer
JIRA issue	EZP-29659
New feature	yes
Target version	2.5 master
BC breaks	no
Tests pass	yes
Doc needed	yes, for global YML params

Introduces time limited (3sec) and object limited (100 items) In-Memory caching to meta data elements; for now Language, ContentType (inc groups) & UserHandler (user meta data, roles, role assignments).

This can be built upon further later (see inline example), but this should already help solve the performance issues we have with Cluster setups.

For comparison here is admin/dashboard on 2.4 ezplatform-ee-demo:

	Cache lookups	Response time locally	Estimated Response time Cluster*
Base	~6k	1.2 sec	12-32 sec
+this PR	~1.2k	7-800ms	2.4-7 sec
+optimized adapter	~600	~600ms	1.2-3 sec

* Numbers estimates a latency of 2-5ms per call to Redis (in cluster setup Redis is often on another server as per nature of a cluster). If RedisCluster is used then it will need Symfony 3.4.23, otherwise base setup will have 17k lookups to Redis nodes and about 34-85 sec response time.

Done:

• Added methods to be able to add more stats on SPI cache calls and improved eZ tab
• Added a simple in-memory cache pool + tests
• Exposed a new abstract for that takes advantage of both things
• Refactored Legacy SE cache to reuse cache pool to avoid cache issues and make sure cache efficiency is good, even for logic inside legacy storage engine
• Refactored ContentLanguage-, ContentType-, and User-hander for the new Abstract to simplify code

Improvements to SPI Persistence/Cache logging, here on admin/dashboard:

TODO:

• Impl
• Implement tests for in-memory pool
• Fix new code according to Coding Standards ($ composer fix-cs).
• Ask for Code Review.

Review notes:

• Tip: Look at changes in tests in order to see when validation logic has been attempted to be improved (a few methods where from what I could see clearing too much)
• Open questions:
  • Should the design be different? aka use for instance PSR-6, or use PSR-6 / Symfony Cache interface for handlers where we want in-memory cache only, to not change handlers at all? (then loose out of the simplifications to them + the improved logging), or ... ?
  • Should we find a different way (more abstracted) way for integration tests and others, to clear cache? Also be able to disable cache as well for scripts that want that (for the running process).

Followup:

• Own cache clearing service for clearing cache across inMemory, symfony pool, and http
  Also requested by Community to expose a command to clear this also (with option to specify which once)
• https://jira.ez.no/browse/EZP-30298
• LRU, unless limit is increased, adding cache on more handlers will increase chances of cache being aggressively wiped. So stating to count reads and sort on that in vacuum() to make sure to prefer to 1. evict non used or just once used cache objects before 2. starting to evict the oldest items if still needed.

[andrerom]

On request by @lserwatka added all of you to review ;)

[gggeek]

The mandatory OT comment from orbit:

it seems to me that this is based on what our german developer friends used to call an "identity-map" cache, i.e. we are not serializing objects for storing them to memory, but instead just putting a ref to them into an array, which is as fast as anyone can get, which I strongly agree with - at least for value-objects, which hold no refs to other objects/resources.

Without having looked at the code, my main question is: what about expiration? Apart from the TTL thing, which seems more or less to be a measure introduced for cli scripts which are supposed to live longer than 1-2 seconds, is the in-memory cache subject to transparent expiration when the script itself does an update of the relevant entity? Ie. if a web page updates, say, a ContentType, will the php code running within the context of that same page transparently see the new version coming from the in-memory cache after the (single?) expiration call done by the kernel?

[gggeek]

Another silly question: I imagine that you have explored usage of ymfony\Component\Cache\Adapter\ArrayAdapter and Cache\Adapter\PHPArray for the base in-memory caching logic?

[andrerom]

Symfony\Component\Cache\Adapter\ArrayAdapter and Cache\Adapter\PHPArray for the base in-memory caching logic?

Does not have limit last time I checked. Also serializes the object (but configurable like global ttl) to avoid issues if being written to which is not relevant here. It also is global unless we go for different adapters (proxy, or w/o) per handler, and if allowed to be global for cache pool means it will be used for cases where it really shouldn't, like having same ttl and limits enforced for meta data as well as for Content for instance. See closed PR that was first attempt at POC for this: #2453

Without having looked at the code, my main question is:

.... ;)

is the in-memory cache subject to transparent expiration when the script itself does an update of the relevant entity? Ie. if a web page updates, say, a ContentType, will the php code running within the context of that same page transparently see the new version coming from the in-memory cache after the (single?) expiration call done by the kernel?

Same process yes. So within single script execution or single request. If your process update it, you are guaranteed to get fresh objects of it straight after (assuming you re-load it after change, as was the case before).

For other processes (in progress) the update will propagate to Symfony cache and Database immediately like before, and the script will get it after the ttl expires, hence why the TTL should never be set very high. It's only a Request /burst cache, where it's down to probability of what can be somewhat safely cached for short bursts.

All script / request processes started after the change will get fresh version of it immediately.

[adamwojs]

Results looks impressive!

[andrerom]

@alongosz @adamwojs @ViniTou Fixed and rebased, expected failure is on remaining Twig 2.7.1 break.

[adamwojs]

I'm not sure if this is worth it but $this->limit / 5 could be calculated only once and stored in property e.g. bulkLoadLimit. As a bonus it will improve code readibility ;-)

[adamwojs]

What about "0" as $listIndex value, is it possible?

[andrerom]

Does not make much sense, as key/indexes needs to be same as used in symfony cache given this is only meant to be used inside abstract in-memory handler.

[adamwojs]

$this->limit / 3 also could be calculated only once.

[andrerom]

For this and the / 5 comment:

1. I haven't seen this being called very often.
2. I don't expect the match here to take much ops compared to array_slice.

[adamwojs]

As an improvement would be great have VO instead of arrays with fixed keys (also in terms of memory usage)

final class PersistenceLoggerCall 
{
        /** @var string */
	private $method;
       /** @var array */
	private $arguments;
        /** @var \eZ\Publish\Core\Persistence\Cache\PersistenceLoggerStats */
	private $stats;
        /** @var \eZ\Publish\Core\Persistence\Cache\PersistenceLoggerCallTrace[] */
	private $traces;

	// ...
} 

final class PersistenceLoggerStats 
{
    /** @var int */
    private $uncached;
    /** @var int */
    private $miss;
    /** @var int */
    private $hit;
    /** @var int */
    private $memory;

    // ... 	
}  

final class PersistenceLoggerCallTrace 
{
    /** @var string[] */
    private $trace;
    /** @var int */   
    private $count;
}

[andrerom]

This looks like a followup if you want to work on it before final ;)

[alongosz]

Coming late to the party, +1. Thanks for addressing my callable type-hints remarks :)
Found one typo:

[andrerom]

QA passes will as agreed with Lukasz be done on rc2, thanks for all the reviews and let’s make 2.5 the fastest release yet 😉