Results after enabling new formatting for Q1-Q10 000

Results after enabling new formatting for Q1-Q100

Results after enabling new formatting for Q1 only

Found the problem with current solution.

More fine grained results

To summarize current results for "Get without cache":

• Number of samples: 314
• Average response time, ms: 350
• Std. deviation, ms: 117
• Median response time, ms: 309
• 90% percentile, ms: 524
• Min, ms: 38 Seems wrong, probably hit the cache. Should be at least greater than 100-150
• Max, ms: 1002

These are preliminary test results using following data set:

Patch is merged - should be fixed.
I think we should wait, lets say, for a week and if nothing pops up close the ticket.

Both solutions don't work for test when 0 is given as TTL. Special case is needed.

Solution 2:
Add 1 to the result of time() and $date->getTimestamp(). In this case effective TTL will always be up to 1 second greater than the given one. In production it will not matter; Tests already sleep for 2 seconds when TTL is 1 second, which is always enough.

The failure happened in code where we store a value with TTL 1s and next line try to get it back. The value was considered expired, so null was returned.

So, 0.6GB of raw data ish?

Apparently, the "prefetching"/buffering is done for LabelDescriptionLookup services, so that when the label/description of particular item/property is to be shown multiple times (e.g. the item appears several times on a page), the label/description is only fetch ones from the storage, and then kept in a in-memory buffer until the end of request.

For a not full cluster you would expect to see no evictions.