memcacheddotnet-users Mailing List for .NET memcached client library
Status: Beta
Brought to you by:
timiscool999
Menu
▾
▴
memcacheddotnet-users — memcacheddotnet list for those using the library in their own projects
You can subscribe to this list here.
| 2006 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Tim G. <ti...@ge...> - 2007-06-07 15:49:28
|
(from the changelog)
7 June 2007 (TG)
-Bugfix. Applied a patch from a contributer (thanks Dave Peckham!)
that
fixes a bug where we don't get the proper size of the
buffer.
In many cases the code would still work fine, but you may
have experienced periodic errors when working with very
large
objects, or seeing wasted space on your memcached servers.
-Tim Gebhardt
ti...@ge...
|
|
From: Tim G. <ti...@ge...> - 2006-04-12 14:39:57
|
For those of you Windows programmers out there using the C# memcached client library (I'm sure there's a few out there...), recently someone figured out the problems with libevent on the Win32 platform and ported memcached to Windows. It also looks like the author is working with Brad to get his changes into the main memcached source code repository. For now you can find the binaries here: http://jehiah.com/projects/memcached-win32/ -Tim Gebhardt ti...@ge... |
|
From: Tim G. <ti...@ge...> - 2006-04-05 16:28:14
|
From the changelog: -Performance. (TG) Turns out that the thorough (sp?) logging throughout the library was part of its performance downfall :). There was a lot of string concatenation and hashtable lookups, which by themselve don't really do much. However, if you Do 100,000 hashtable lookups (because all the messages are internationalized), and 50,000 string concatenations it starts to all add up. I wrapped every logging statement with a boolean lookup on log4net which can check to see if we're even going to log the message, and if not, don't even do the work involved in logging. If you turn off logging, or turn it up to some high level like "WARN" or "ERROR", then you will see a pretty significant performance benefit, CPU usage down significantly, and network usage up significantly. Tim Gebhardt ti...@ge... |
|
From: Tim G. <ti...@ge...> - 2006-04-05 16:24:31
|
I think I figured out what was wrong with the performance in the 1.1.* line and I'm redeploying a new version. Should be up in 10 minutes or so (Sourceforge file release process is pretty cumbersome). You can check the changelog or the news when it's up for a detailed description of what was wrong, but my benchmarks go something like this now: 1.1.1: 10,000 gets/sets - 9.3s 1.1.2: 10,000 gets/sets - 8.2s The other notable thing is that the CPU usage from 1.1.1 to 1.1.2 is down from 30% to ~10%. Lei and Max, I BCC'ed you and sent this email to the developer's mailing list. -Tim Gebhardt ti...@ge... -----Original Message----- From: Lei Sun [mailto:le...@gm...] Sent: Tuesday, April 04, 2006 12:47 PM To: ti...@ge... Cc: Maxim Mass Subject: Re: memcache exception Hi Tim, We tried to do a stress test on all 3 versions of the client. Conditions: 1) 2 memcached server, both dual cpu, 4 GB memory 2) Client machine is p4 dual core 3.0G hyper threading 3) Basically a unit of our test is consisted of 100 set, 100, get, 100 getmulti, 1 flushall 4) We run a unit of test 300 times and 1000 times across all three versions of the client. Here is what we found: 1.0.3 1.1.0 1.1.1 # of actions sec to finish/exceptions 30,000 26 30 30,000 25 30 30,000 25 29 100,000 81/0 97/30 101/0 100,000 94/0 109/47 102/0 100,000 82/0 111/24 97/0 Result: 1) 1.0.3 is actually the best in performance, network stats are steady and high, and no exceptions 2) 1.1.0 is the worst in performance, network stats are zigzaggy and lower, and lots of exceptions 3) 1.1.1's performance isn't that good, network stats are a little better than 1.1.0, but still very zigzaggy comparing to 1.0.3. but no exceptions Good thing that you have reduced the exceptions from 1.1.1 comparing to 1.1.0! Would you please look into this slower performance issue? Thanks Lei On 3/31/06, Tim Gebhardt <ti...@ge...> wrote: > > > > The new release is up. Let me know if you guys have any more problems. > > > > -Tim > > > > ________________________________ > > > From: max...@gm... [mailto:max...@gm...] On Behalf Of Maxim > Mass > Sent: Thursday, March 30, 2006 7:16 PM > To: ti...@ge... > Cc: le...@gm... > Subject: memcache exception > > > > > We've been getting this exception pretty often in our prod environment. > Seems to happen more as more load gets put on it. There's def. a bug with > the client -- i dont think this is server related at all. > > Here's a partial stack.. Unfortunately, i dont have the full trace. > at System.Net.Sockets.NetworkStream.Write(Byte[] buffer, > Int32 offset, Int32 size) at > System.IO.BufferedStream.FlushWrite() at > System.IO.BufferedStream.Flush() at System.IO.BufferedStream.Close() at > MemCached.clientlib.SockIO.TrueClose() at MemCache > > > The exception.message is > Cannot access a disposed object named > "System.Net.Sockets.NetworkStream". Object name: > "System.Net.Sockets.NetworkStream". > > > Have you been experiencing anything like this? can you tell me the settings > you've been using for the client? > We're still using previous version right before your fxcop changes. Do you > know if that version fixes anything? > > Max > > |
|
From: Tim G. <ti...@ge...> - 2006-03-31 22:27:54
|
31 March 2006 (TG) -Bugfix. There were problems where the busy and available pools were continually being created over and over again. This has been fixed and not only does this solve a very subtle outstanding bug, but it also results in a massive performance increase! -Bugfix. Fixed the code where we treat the input and output stream of a SockIO object as two different objects when .NET just treats them as a single object. This was a hold-over from java. The code isn't in CVS yet (but it is in the file release) because it looks like the sourceforge CVS server is down, or doesn't want me to connect. |
|
From: Tim G. <ti...@ge...> - 2006-01-24 19:05:04
|
23 Jan 2006 (TG) -Huge overhaul of code. Basically ran the client library through FxCop (http://www.gotdotnet.com/team/fxcop/) and tried to fix every error. There are breaking changes, but this should be the one and only time this ever happens. -Internationalized the exception messages and log messages. -Added 2 FxCop projects (one for .NET 1.1 and one for .NET 2.0) and a custom dictionary file to add our custom words for FxCop. -Removed the NestedIOException class because the .NET IOException class can do inner exceptions. -Split off SockIO class into its own source file. -Tim Gebhardt ti...@ge... |
|
From: Tim G. <ti...@ge...> - 2006-01-24 19:04:50
|
After a huge refactoring of the client library to match the coding = standards recommended by Microsoft and some excellent bug hunting by Maxim Mass, I = am confident that the library is not only stable to use, but stable to code against (as in the API shouldn't be changing now very much). I am = changing this project's status to "Beta" so developers that stumble across the project feel a little bit more confident to use it. On a related note, we may get more developers stumbling across it ever = since it has been listed on the Client API's section of the memcached website: http://www.danga.com/memcached/apis.bml w00t! Thanks Max for all your help! -Tim Gebhardt ti...@ge... =A0=A0=A0=A0=A0 Quidquid latine dictum sit, altum sonatur.=A0 =A0=A0=A0=A0=A0=A0Whatever is said in Latin sounds profound.=20 |
