Can't you do something with outside profiling tools? For instance oprofile?
http://oprofile.sourceforge.net/
That's a (linux) kernel-level profiler that can gather fairly useful
bits of information without having to run a modified version of
memcached and without having to run it permanently.
I can understand a set-up with replication rather than "sharding". In
our situation we have only about 800MB of data in memcached, so there is
hardly any need to have more than one instance... But it does get a fair
amount of work, the average cmd_get's per second works out to about 1500
and it
On 26-11-2011 22:31 Les Mikesell wrote:
On Sat, Nov 26, 2011 at 3:19 PM, Arjen van der Meijden
wrote:
On 26-11-2011 19:28 Les Mikesell wrote:
In the first one you may end up with 16 different tcp/ip-connections per
client. Obviously, connection pooling and proxies can alleviate some of
On 26-11-2011 19:28 Les Mikesell wrote:
On Sat, Nov 26, 2011 at 7:15 AM, Arjen van der Meijden
wrote:
Wouldn't more servers become increasingly (seen from the application) slower
as you force your clients to connect to more servers?
Assuming all machines have enough processing powe
Wouldn't more servers become increasingly (seen from the application)
slower as you force your clients to connect to more servers?
Assuming all machines have enough processing power and network
bandwidth, I'd expect performance of the last of these variants to be best:
16x 1GB machines
8x 2
Am I reading you correctly, in that you want to set up a hot spare
memcached-daemon on the same machine?
To what purpose would you do that? Memcached is very stable (ours is
running for a year now), so it basically won't die by itself. I don't
really understand why you would want to kill it, b
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 an
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 gig
What other rules are there in your iptables? I.e., aren't you just
actually limiting connections via iptables or rules with similar
behavior on other levels?
Apart from that, it would be interesting to see what happens if you were
to flip the roles of the two memcached-servers, to determine whet
On 19-4-2010 14:19, Brian Moon wrote:
Oh, the FUD of SEO "plugins". They have you by the nuts now. Never
ever change anything, or you will fall off of Google.
But it really isn't a good idea to just throw away all old urls without
at least a redirect to the new ones. That obviously doesn't mean
On 3-3-2010 10:10, simon wrote:
Hi there
I am experimenting with using memcache for storing PHP sessions in a
www cluster environment. But due to latency in network, I have noticed
slight performance drop in application as opposed to just direct
access.
Has anyone played with changing MTU on th
On 9-1-2009 5:22 Du Song wrote:
It's already there.
in PECL-memcache 3.x
http://pecl.php.net/package/memcache
Regards,
Du Song
That code is still beta, which afaik it should be, since at least we
repeatedly run into segfaults in php, which dissappear when using the
stable 2.2-version.
Unfor
12 matches
Mail list logo
