- User Since
- Dec 2 2016, 11:15 AM (221 w, 3 d)
- IRC Nick
- LDAP User
- Aleksey Bekh-Ivanov (WMDE)
- MediaWiki User
Apr 5 2019
Aug 30 2018
Results after enabling new formatting for Q1-Q10 000
Aug 28 2018
Results after enabling new formatting for Q1-Q100
Aug 27 2018
Results after enabling new formatting for Q1 only
Aug 23 2018
Aug 22 2018
Aug 16 2018
Aug 15 2018
Found the problem with current solution.
Aug 14 2018
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:
Aug 8 2018
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.
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.
Jul 11 2018
So, 0.6GB of raw data ish?
Jul 10 2018
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.
Jun 18 2018
For a not full cluster you would expect to see no evictions.