Not yet J
I'm going to try and take a look over the weekend. From: Ciaran [mailto:[EMAIL PROTECTED] Sent: 17 January 2008 09:51 To: Kieran Benton Cc: [email protected] Subject: Re: Enyim.Memcached and asynchronous sets On Jan 17, 2008 9:38 AM, Kieran Benton <[EMAIL PROTECTED]> wrote: Ciaran, You will get a fully parallelized approach using the article, its showing you basically the easiest way to implement Begin... & End... for an operation. Delegate Begin/End Invoke queues a job on the current AppDomain's threadpool in exactly the same manner you seem to be doing - but probably saves you a lot of extra code. True, but to actually control how the asynchronous tasks work I *think* I need that extra code, did you get the patch I posted last night ? Either way you're right, I don't think directly using the same pool as the one used for http requests is a particularly wonderful idea as we've had thread starvation issues similar to your experiences with web services in the past. Maybe queuing internally and dispatching a few sets at a time to the threadpool or even to a few specialized threads would be a better idea. I make use of http://www.yoda.arachsys.com/csharp/miscutil/ CustomThreadPool in some special circumstances (longer running jobs than a few seconds). Maybe this could be incorporated? Thanks, I'll take a look I re-implemented my own for sorting this problem out internally, I'm sure they've done a better job! :) - Ciaran Cheers, Kieran From: Ciaran [mailto:[EMAIL PROTECTED] Sent: 16 January 2008 20:21 To: Kieran Benton Cc: [email protected] Subject: Re: Enyim.Memcached and asynchronous sets On Jan 16, 2008 7:29 PM, Kieran Benton <[EMAIL PROTECTED]> wrote: Take a look at http://aspzone.com/blogs/john/articles/521.aspx. That seems to be the simplest way to implement just using a delegate and letting the framework do the heavy lifting J Thanks, don't worry I can use the built-in ThreadPool implementation in a similar fashion, but will gain parallelisation, I don't *think* you get that with the approach in that particular article, my problem is more trying to make sense of the 'Begin/End' *convention* in the 'BCL' [new term for me] For example, on the 'Socket' class the EndSend method, appears to cancel a pending async send, but on most other Begin/Send methods (Webservice methods for example), it seems to provde a 'helper' method to get hold of the async result, but again it isn't clear to me what the correct approach is in this case :) (the article appears to suggest the latter)! - Ciaran From: Ciaran [mailto:[EMAIL PROTECTED] Sent: 16 January 2008 12:07 To: Kieran Benton Cc: [email protected] Subject: Re: Enyim.Memcached and asynchronous sets 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 -- - Ciaran
