#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.