lot of new members

[Brad Fitzpatrick]

James,

That Debian package is incredibly old... over a year.  Even libevent 0.7b
(released a couple weeks ago) is buggy:

It works perfect with kqueue, almost perfect in epoll mode (LJ uses this),
not at all in rtsig (which is off by default), reportedly horribly in poll
mode (which you're using, I imagine), and also reportedly bad in select.

Anybody using memcached for serious uses is running with epoll or kqueue.
(kqueue is BSD, epoll is Linux 2.6 or patched 2.4... and patching is easy)

However, I've never tested myself if libevent-0.7b sucks with poll (the
Linux 2.4 default), so let me make a new binary and get back to you.

- Brad


On Fri, 17 Oct 2003, James Mastros wrote:

> On Thu, Oct 16, 2003 at 03:37:25PM -0700, Brad Fitzpatrick wrote:
> > I've seen a whole bunch of new members to the mailing list over the past
> > week.
> Wow, nifty.  I seem to have been the straw that broke the camel's back, as I
> just subscribed last night.
>
> > Anybody care to say hi?
> <voice repituar="The Simpsons" type="Hi, Dr. Nick">Hi, Brad!</voice>
>
> > Say what you're using memcached for?  Ask some questions?
> I was planning on using memcached to accelerate the node cache of
> perlmonks.org.  We're dying of an overloaded DB server, and while traffic is
> increasing nearly exponentialy over time, and we're running as a nonprofit,
> any hardware increase we could possibly make would just push the curve back
> a couple months.  Unfornatly, there's quite a bit of political complexity,
> so I'm attempting to take the smallest possible change that will have a
> large effect.
>
> The node cache, in order to tell that the cached version of the node is
> current, is constantly doing a "SELECT version FROM version WHERE
> version_id=?".  There's no reason to do this on the slow, overloaded DB,
> some sort of shared psudoflatfile would work just as well.  I think
> memcached can be that psudoflatfile.  Making the change here means I need to
> change just one sub, and using memcached means that I'm minimising new code
> that hasn't been tested in a very-high-load production environment.
>
> BTW, in case you were wondering, we've got two web servers and a db server,
> all running freebsd.  I'd give more details, but I don't actualy know them
> -- I'm just a pmdev, not a god, I don't have any direct access.
>
> Unfornatly, in initial testing on my desktop, I've gotten horrible times.
> (The lines with Foo: absurdly-
> New: 0.000163078308105469
> $VAR1 = bless( {
>                  'bucketcount' => 0,
> 		 'stats' => {},
> 		 'active' => 1,
>                  'compress_threshold' => undef,
>                  '_single_sock' => '127.0.0.1:11211',
> 		 'compress_enable' => 0,
> 		 'buckets' => undef,
> 		 'debug'=> 1,
>                  'servers' => [
> 		               '127.0.0.1:11211'
>                               ]
>                }, 'MemCachedClient' );
> MemCache: set 42 = test (STORED)
> Set: 0.0524049997329712
> MemCache: got 42 = test
> testGet: 4.37252199649811
>
> Uh, 4.4 seconds for a get?  The desktop is a PIII-600MHz, 640MB RAM, mostly
> idle CPU, but running normal desktopish stuff, Linux 2.6.0-test7, libevent
> 0.6-5 (debian pacakge), newest memcahed and MemCachedClient.  (BTW, putting
> the perl interface on CPAN and renaming it Cache::Memcached would probably
> get it somewhat more attention.)  This is a somwhat bad run, but I havn't
> seen the get be lower then 1.5s yet.
>
>     Thanks,
>     -=- James Mastros
>
>