#28977: Change Local Memory Cache to Use LRU
-------------------------------------+-------------------------------------
Reporter: Grant Jenks | Owner: Grant
| Jenks
Type: New feature | Status: assigned
Component: Core (Cache system) | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Grant Jenks):
One more set of benchmarks. The above results benchmark in a single-
process and single-thread environment. There's therefore never a time when
the locks contend with one another for access. I thought it would be
useful to observe performance with more contention and my development
machine has eight logical processors so here's the results in a single-
process and eight-thread environment.
The current implementation:
{{{
========= ========= ========= ========= ========= ========= =========
=========
Timings for locmem
-------------------------------------------------------------------------------
Action Count Miss Median P90 P99 Max
Total
========= ========= ========= ========= ========= ========= =========
=========
get 712648 85412 14.067us 863.075us 2.461ms 14.337ms
160.973s
set 71226 0 204.563us 238.180us 282.288us 7.419ms
12.356s
delete 8118 0 201.941us 235.081us 281.811us 410.080us
1.395s
Total 791992
174.724s
========= ========= ========= ========= ========= ========= =========
=========
}}}
The new implementation:
{{{
========= ========= ========= ========= ========= ========= =========
=========
Timings for locmem
-------------------------------------------------------------------------------
Action Count Miss Median P90 P99 Max
Total
========= ========= ========= ========= ========= ========= =========
=========
get 712637 84222 146.151us 165.224us 201.225us 9.591ms
106.855s
set 71241 0 149.012us 167.847us 204.802us 9.604ms
10.875s
delete 8114 0 144.958us 163.078us 195.026us 552.893us
1.200s
Total 791992
118.930s
========= ========= ========= ========= ========= ========= =========
=========
}}}
The results overall display less variation but the median "get" time is
10x slower (14 microseconds vs 146 microseconds). Despite that large
slowdown, the total time for "get" operations is ~33% faster (160 seconds
vs 106 seconds). The "set" and "delete" operations have comparable
performance.
The LRU eviction policy turns every read into a write which obsoletes the
django.utils.synch.RWLock used in the current implementation. The RWLock
was capable of giving multiple readers concurrent access but with the
additional overhead. Therefore we see in the "no contention" scenario that
the overhead is less by using threading.RLock. In the "high contention"
scenario the additional overhead gives reads an advantage at the median
but a larger penalty at the 99th percentile.
I think these tradeoffs are easy to accept. Note that the benchmark does
not include a miss-rate penalty which the LRU-eviction policy will almost
certainly improve compared with the current random-eviction policy.
--
Ticket URL: <https://code.djangoproject.com/ticket/28977#comment:6>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/068.018ba6c1d5800e6209316e19316044a6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
