Re: get_cache and multiple caches

On Mon, Sep 23, 2013 at 5:55 AM, Anssi Kääriäinen wrote: > On 09/20/2013 06:29 PM, Tom Evans wrote: >> >> On Fri, Sep 20, 2013 at 4:13 PM, Florian Apolloner >> wrote: It seems more sensible to hook something that has the lifetime of the

Re: get_cache and multiple caches

On Saturday, September 21, 2013 2:12:31 AM UTC+2, Curtis Maloney wrote: > Is there anything else? > Ain't that enough? :p -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it,

Re: get_cache and multiple caches

OK. So the goals of this effort are: 1) to avoid resource over commitment [e.g. too many connections] 2) to help relieve the burden of concurrency from the cache backends. Issues to avoid are: a) TLS is "slow" (citation, please?) b) New API better damn well be worth it! Is there anything else?

Re: get_cache and multiple caches

Hi Tom, On Friday, September 20, 2013 5:04:41 PM UTC+2, Tom Evans wrote: > > On the other hand each call to get_cache('foo') now requires access to > TLS. TLS is slw. Going through something slow to get to something > that is supposed to be a speed up... > You are making a good point,

Re: get_cache and multiple caches

On Fri, Sep 20, 2013 at 4:13 PM, Florian Apolloner wrote: >> It seems more sensible to hook something that has the lifetime of the >> request to the request, rather than stick it in TLS, keyed to the >> thread serving the request. > > > Jupp, sadly I don't see a sensible

Re: get_cache and multiple caches

On Fri, Sep 20, 2013 at 3:10 PM, Florian Apolloner wrote: > The main issue here isn't recreating the objects on demand, but the impact > they have, eg a new memcached connection. Now imagine a complex system where > each part issues get_cache('something') to get the cache

Re: get_cache and multiple caches

Hi Tom, On Friday, September 20, 2013 3:29:03 PM UTC+2, Tom Evans wrote: > > Before you > go too far down the thread local route, could you verify that > retrieving cache objects from a thread local cache is in any way > faster than simply recreating them as demanded. > The main issue here

Re: get_cache and multiple caches

On Wed, Sep 18, 2013 at 12:29 PM, Curtis Maloney wrote: > I started working on a CacheManager for dealing with thread local cache > instances, as was suggested on IRC by more than one person. > The problem that Florian identified was that recreating cache instances

Re: get_cache and multiple caches

Yeah... simpler solution is simpler :) -- C On 20 September 2013 17:04, Florian Apolloner wrote: > > > On Friday, September 20, 2013 8:58:25 AM UTC+2, Curtis Maloney wrote: >> >> I guess the remaining question to address is : close() >> > Leave it as is I think. > >

Re: get_cache and multiple caches

On Friday, September 20, 2013 8:58:25 AM UTC+2, Curtis Maloney wrote: > > I guess the remaining question to address is : close() > Leave it as is I think. > Thinking as I type... it wouldn't hurt, also, to allow a cache backend to > provide an interface to a connection pool, so the manager

Re: get_cache and multiple caches

I guess the remaining question to address is : close() It looks like it was added to appease an issue with memcached, which may or may not still be an issue [comments in tickets suggest it was a design decision by the memcached authors]. Thinking as I type... it wouldn't hurt, also, to allow a

Re: get_cache and multiple caches

Hi, On Wednesday, September 18, 2013 1:29:25 PM UTC+2, Curtis Maloney wrote: > > 1) Can we share "ad-hoc" caches -- that is, ones created by passing more > than just the CACHES alias. > Imo no, you probably have a good reason if you create ad-hoc ones > 2) What to do about

Re: get_cache and multiple caches

I started working on a CacheManager for dealing with thread local cache instances, as was suggested on IRC by more than one person. Firstly, I propose we remove the schema://backend... syntax for defining cache configs, as it's no longer even documented [that I could find quickly] Secondly,

Re: get_cache and multiple caches

Hi, On Monday, September 2, 2013 6:39:09 AM UTC+2, Curtis Maloney wrote: > > Whilst it's conceivable some cache backend will have the smarts to > multiplex requests on a single connection, I suspect that's more the > exception than the case. > Agreed > Obviously, the default would be one

Re: get_cache and multiple caches

Bit of a rambling, thinking-out-loud-ish post... Whilst it's conceivable some cache backend will have the smarts to multiplex requests on a single connection, I suspect that's more the exception than the case. However, that doesn't mean the cache backend can't be left with the opportunity to

Re: get_cache and multiple caches

Hi, On Sunday, September 1, 2013 4:34:54 AM UTC+2, Curtis Maloney wrote: > > I've a possible solution - > https://github.com/funkybob/django/compare/simple_caches > > Basically, the existing API and behaviours are still available through > get_cache, but you can avoid duplicate instances of

Re: get_cache and multiple caches

I've a possible solution - https://github.com/funkybob/django/compare/simple_caches Basically, the existing API and behaviours are still available through get_cache, but you can avoid duplicate instances of caches using django.core.cache.caches[name] -- Curtis On 31 August 2013 15:44, Curtis

Re: get_cache and multiple caches

As a simple short-term solution, why not cache calls to get_cache that don't pass additional arguments? That is, ones that only get pre-configured caches. -- Curtis On 25 August 2013 23:26, Florian Apolloner wrote: > Hi, > > so when reviewing