In case anybody is interested in playing with an example 'working' demo (this isn't quite what I would propose as I don't think using the app-domain's threadpool is wise here), please find attached an svn diff for the current source code cut.
(to use it apply with patch -p0 -i patchfile.patch) Take Care :) - Ciaran (the code here 'borrows/steals' heavily from http://msdn.microsoft.com/msdnmag/issues/07/03/ConcurrentAffairs/ , a rather excellent article on such matters :). The Asyncresult class is a little heavyweight for the needs here, but its very complete ;) ) - Ciaran On Jan 16, 2008 7:42 PM, Kieran Benton <[EMAIL PROTECTED]> wrote: > 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 > > > -- - Ciaran
BeginStoreDemo.patch
Description: Binary data
