Changes between Initial Version and Version 7 of Ticket #33625


Ignore:
Timestamp:
Jun 30, 2022, 1:22:04 PM (2 years ago)
Author:
Anders Kaseorg
Comment:

We don’t need a new pool. Both ​pylibmc and ​pymemcache already have one.

It seems to me it’d be best to leave pooling up to the backend library, because it’s in a better position to know what kinds of concurrency are safe.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #33625

    • Property Keywords asgi async added
    • Property Triage Stage Unreviewed → Accepted
    • Property Owner changed from nobody to Pablo Montepagano
    • Property Status new → assigned

  • Ticket #33625 – Description

    initial v7  
    1 When I run an application that uses `django.core.cache.backends.memcached.PyMemcacheCache` with WSGI under Gunicorn, it makes a single connection to memcached and leaves it open, as I expect.
     1When I run an application that uses `django.core.cache.backends.memcached.PyLibMCCache` with WSGI under Gunicorn, it makes a single connection to memcached and leaves it open, as I expect.
    22
    33But when I run it with ASGI under uvicorn, it makes a different connection to memcached for every request and immediately closes it. That is, #11331/#15324 has returned. This at least adds undesirable latency, and may also eventually lead to connection failures as described in #11331.
Back to Top