Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 145 by bjourne: Items are recycled to soon
http://code.google.com/p/memcached/issues/detail?id=145
This is the output of the stats command on my memcached (1.4.5) instance:
STAT pid 5285
STAT uptime 37314
STAT time
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 146 by perrykrug: Prepackaged Windows binaries don't respect
command-line flags when being installed as a service
http://code.google.com/p/memcached/issues/detail?id=146
What steps will reproduce the problem?
1.Running in
I've seen some FUD from people claiming that memcached doesn't scale
very well on multiple CPUs, which surprised me.
Is there an accepted benchmark we can use to examine performance in more
detail?
Does anybody have any testing results in that area?
Thanks,
--
Simon Riggs
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 147 by perrykrug: Prepackaged Windows binaries use runservice
when being installed as a service
http://code.google.com/p/memcached/issues/detail?id=147
What steps will reproduce the problem?
1.In Windows: memcached.exe -d
I've seen some FUD from people claiming that memcached doesn't scale
very well on multiple CPUs, which surprised me.
Is there an accepted benchmark we can use to examine performance in more
detail?
Does anybody have any testing results in that area?
While we don't have a standard set of
Comment #1 on issue 145 by dorma...@rydia.net: Items are recycled to soon
http://code.google.com/p/memcached/issues/detail?id=145
Can you please provide a script that reproduces this? How are you testing
it exactly? How long are you seeing items cached for before they expire? We
need all
On Wed, Jun 30, 2010 at 11:35:08AM -0700, dormando wrote:
I've seen some FUD from people claiming that memcached doesn't scale
very well on multiple CPUs, which surprised me.
Is there an accepted benchmark we can use to examine performance in more
detail?
Does anybody have any
I've seen load testing benchmarks using memslap which showed linear scaling,
but nothing to the extent that demonstrated locking to be a bottleneck (for the
reasons that domando stated). When I peaked at the code a while back it looked
like the locking on the hashtable / lru chain was coarse,
On 30-6-2010 20:35 dormando wrote:
Most of these are saying that you hit a wall scaling memcached past,
say, 300,000 requests per second on a single box. (though I think with the
latest 1.4 it's easier to hit 500,000+). Remember that 300,000 requests
per second at 1k per request is over 2.5
With what kind of boxes would that be?
With 300-500k/sec you're getting really close to lowlevel limitations of
single network interfaces. With dell 1950's (with broadcom netextreme II 5708
and dual xeon 5150) we were able to produce about 550-600,000 packets/second
with
On 6/30/2010 5:35 PM, dormando wrote:
With what kind of boxes would that be?
With 300-500k/sec you're getting really close to lowlevel limitations of
single network interfaces. With dell 1950's (with broadcom netextreme II 5708
and dual xeon 5150) we were able to produce about 550-600,000
For most hardware memcached is limited by the NIC. I'd welcome someone to
prove a simple case showing otherwise, at which time we'd prioritize an
easy fix :)
Does that mean you should use multiple NICs on the servers and spread the
clients over different networks?
It means you probably
I've submitted a patch to the memcached-tool to my personal fork up on
github. If possible I'd like to contribute it back to the master,
however it will obviously need a few eyes (plus I'll need some
permissions/instructions on contributing as I'm a bit new to this).
Thanks in advance, and I hope
On 1-7-2010 0:49 Les Mikesell wrote:
On 6/30/2010 5:35 PM, dormando wrote:
For most hardware memcached is limited by the NIC. I'd welcome someone to
prove a simple case showing otherwise, at which time we'd prioritize an
easy fix :)
Does that mean you should use multiple NICs on the servers
14 matches
Mail list logo
