I would be very much interested in a Windows Binary that didn't eat up one of our cores.
-Stephen On Wed, Jul 2, 2008 at 5:34 AM, Henrik Schröder <[EMAIL PROTECTED]> wrote: > On Fri, Jun 6, 2008 at 12:27 AM, Henrik Schröder <[EMAIL PROTECTED]> > wrote: > >> On Thu, Jun 5, 2008 at 8:01 PM, Jeff Rodenburg <[EMAIL PROTECTED]> >> wrote: >> >>> Henrik - can you elaborate on what you've found with this? I'm not >>> looking to resolve the issues, just trying to get a better picture of where >>> the bodies are buried, and to convince an all-windows shop that it's OK to >>> run a few linux instances to support certain application services. >>> >> >> On our current project, we run memcached on two servers that are also web >> servers, and on both machines the memcached process consumes exactly 25% >> CPU. The weird thing is that those two servers have different hardware. One >> is a two-processor dual core Xeon at 2,5GHz, and the other is a >> two-processor dual core Xeon at 1,6GHz. The first one runs Windows Server >> 2008, the other Windows Server 2003. But the memcached process on each takes >> up exactly 25% CPU all the time. I can also see on the stats that the second >> server gets more memcached traffic than the first one, so the second server >> is slower than the first and gets more traffic, but the CPU use is 25% on >> both servers. >> > > Ok, thanks to Brodie Thiesfield who managed to produce working Visual > Studio projects of Libevent 1.4.4 and Memcached 1.2.5, I've compiled my own > version. I took his project, added the old memcached icon (These things are > important! :) ), fixed a file version number, and compiled everything in my > Visual Studio 2005 with whatever optimizations it can do, and finally got to > deploy this version live. > > It's been running for a day now, and so far it looks good, still at 0% CPU > utilization so hopefully whatever problems the older windows versions of > memcached had are gone. I'll let it run for a week, and if it's still > behaving after that time, I'll try to make available our binary for those > that are interested. > > > /Henrik Schröder >
