Hi,
Yes, the only thing that could work is doing async I/O. Using threads
or the basic async model of the framework can deplete the thread pool
very fast in web applications, and I did not see any big performance
gains from it.
Moreover, there are (should be) far more Gets than Sets (in my app
it's a 20:1 ratio), but Gets cannot really benefit from the async
processing (only Sets). True, if the Get would take a significant time
to execute you could fire a get request, do some work then wait for
the results, but it's not the majority.
Or is it for others?
Anyway just submit a patch and we'll see :)
a.
On Jan 16, 2008, at 9:21 PM, Ciaran wrote:
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
