Well its just theoretical but my thinking is as follows:
Its always best to keep your page requests down in terms of request time. This is because for a page to be built and sent a single thread is required out of the worker pool (which is configurable in size). The shorter page requests take on average, the fewer worker threads that are required to allow a server under load to operate normally. This has the side effect of reducing the number of potential context switches on the server and potentially shaving some CPU time off as well. So, anything that reduces the length of time that a page request takes seems to me would be a performance benefit (and certainly no harm). Of course reducing the length of time of page requests also makes individual connections snappier to the client. Admittedly I'm not sure whether the async jobs will be run on the same threadpool as the ASP.NET page requests or not, can anyone answer that? This could be solved by using async I/O internally in the SET operator which would wind up using IO completion ports which are very lightweight and scalable and are definitely not part of the standard page request threadpool. Cheers, Kieran From: Kevin Amerson [mailto:[EMAIL PROTECTED] Sent: 16 January 2008 19:37 To: Ciaran Cc: Kieran Benton; [email protected] Subject: Re: Enyim.Memcached and asynchronous sets 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? 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
