On Jan 16, 2008 7:36 PM, Kevin Amerson <[EMAIL PROTECTED]> wrote: > I wonder if the benefit in a production web application would really be > that great. For instance, each web request already runs in its own thread, > so if each request in reality only submits a handful of sets then this won't > really add any performance to a production web site. > > 50 web servers > 100 users per server > > 5000 simultaneous sets to memcached, does each one need to do theirs > asynchronously? > > Can someone else reply with how other libraries are doing sets? Would you > see a benefit in a production environment?
For me *personally* I use the pseudo namespace approach to invalidate whole chunks of my cache (massively in-efficient I know!), so when I 'inc' my namespace key, all of a sudden (for a particular request there may be many tens of sets that suddenly occur ) I get number of sets x 5ms hits added onto my request where I don't I *need* to wait for them to complete. I'm not proposing a seperate thread for each async request, far from it, ideally given how rare sets should really be I'd do it with just one or two threads accessing a work queue (my test implementation actually uses the ASP.Net/App Domain ThreadPool) So I guess its personal preference, but for me it reduces the time for a particular response when an update 'request/post' causes a cache invalidation to return :) Cheers - Ciaran > > > Kevin > > > On Jan 16, 2008 6:06 AM, Ciaran <[EMAIL PROTECTED]> wrote: > > > > > On Jan 16, 2008 11:50 AM, Kieran Benton <[EMAIL PROTECTED]> > > wrote: > > > > > Hi Ciaran, > > > > > > I think this is definitely something that would be of benefit, as > > > you're right, if you've architected your app correctly most SETs can be > > > asynchronous. I'd argue for a BeginStore / EndStore standard pattern > > > though > > > like in the rest of the BCL. > > > > > As I understand it, this is simply a naming convention and adding a > > parameter that implements IAsyncResult (and then using it correctly? ) Is > > this correct ? > > - ciaran > > > > > > > > > > > Cheers, > > > > > > Kieran > > > > > > > > > > > > *From:* [EMAIL PROTECTED] [mailto: > > > [EMAIL PROTECTED] * On Behalf Of *Ciaran > > > *Sent:* 16 January 2008 11:41 > > > *To:* [email protected] > > > *Subject:* Re: Enyim.Memcached and asynchronous sets > > > > > > > > > > > > > > > > > > On Jan 16, 2008 9:45 AM, Ciaran <[EMAIL PROTECTED]> wrote: > > > > > > HI, > > > Am I better modifying the Enyim.Memcached client to support an Async > > > Set [clearly a workqueue around the normal set command] (and provide you > > > with another patch), or just wrap the existing client in my own facade to > > > provide this functionality, i.e. what would 'a' (Enyim) prefer. > > > > > > On the off-chance that someone's interested, the following code : > > > IList<IEndPoint> servers = new List<IEndPoint>(); > > > servers.Add(new Enyim.Caching.Configuration.Code.EndPoint > > > ("127.0.0.1", 11211)); > > > MemCachedClientConfiguration configuration = new > > > MemCachedClientConfiguration(servers); > > > MemcachedClient client = new > > > MemcachedClient(configuration); > > > DateTime before = DateTime.Now; > > > for (int i = 0; i < 10000; i++) > > > { > > > Guid guid = Guid.NewGuid(); > > > client.Store(StoreMode.Set, guid.ToString(), guid); > > > } > > > DateTime after= DateTime.Now; > > > Console.Out.WriteLine(String.Format("Took {0}ms to do > > > 10000 stores", ((TimeSpan)(after-before)).TotalMilliseconds)); > > > DateTime beforeAsync = DateTime.Now; > > > > > > for (int i = 0; i < 10000; i++) > > > { > > > Guid guid = Guid.NewGuid(); > > > client.StoreAsync(StoreMode.Set, guid.ToString(), > > > guid); > > > } > > > after = DateTime.Now; > > > Console.Out.WriteLine(String.Format("Took {0}ms to do > > > 10000 stores", ((TimeSpan)(after - beforeAsync)).TotalMilliseconds)); > > > > > > Prints the following timings: > > > Took 1734.3861ms to do 10000 stores > > > Took 62.5004ms to do 10000 stores > > > (Interestingly the *actual* time to do the 10000 stores > > > asynchronously, came out at about 1200ms, because many stores occurred in > > > parallel fwiw) > > > > > > Thanks > > > - Ciaran > > > > > > > > > -- > > > - Ciaran > > > > > > > > > > > -- > > - Ciaran > > > -- - Ciaran
