Are you having a problem with performance, fragmentation and stuff in
the current memcached version?
On Tue, Jul 28, 2009 at 11:56 AM, Harish Kumarabscond1...@yahoo.co.in wrote:
Is there any one who could help me ?
At least few links which gives little more information. Is it a wrong
place
On Jul 28, 11:56 am, Harish Kumar abscond1...@yahoo.co.in wrote:
Is there any one who could help me ?
At least few links which gives little more information. Is it a wrong
place to ask for this version of memcached ?
I don't think anyone supports that version. We kind of look at it
as a
the
code of facebook-memcached.
You're asking questions about a somewhat uncommon piece of
software. Is there a particular reason you're looking at that version
instead of the community version?
Hi,
I am kinda new to a research group and I am trying to understand the
code of facebook-memcached. Can any one help me out please. I am
unable to understand why flat allocator is used. In the config.h file
the USE_FLAT_ALLOCATOR is commented out. When does the code use slab
allocator and when
On Jan 9, 4:52 am, Arjen van der Meijden a...@tweakers.net wrote:
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
On Sun, Jan 4, 2009 at 23:43, Advt thehaz...@gmail.com wrote:
On Dec 13 2008, 11:24 am, marc kwiatkowski
marc.kwiatkow...@gmail.com wrote:
As some of you may have noticed we've putfacebook'sversion of
memcached up on github
http://github.com/fbmarc/facebook-memcached
We've done
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.
On 12/20/08 4:42 AM, Toru Maesaka tmaes...@gmail.com wrote:
Hi!
I've quickly glanced through the repo and even though I think the idea
of the flat allocator is neat and how it uses mmap (/me loves mmap), I
think the flat allocator itself should belong outside the codebase.
So, what I'm trying to
Hi!
I've quickly glanced through the repo and even though I think the idea
of the flat allocator is neat and how it uses mmap (/me loves mmap), I
think the flat allocator itself should belong outside the codebase.
So, what I'm trying to say is, shouldn't this be a separate storage
engine?
Trond
Toru Maesaka wrote:
oops, clicked send before I finished the email :(
ASFAIK, Trond and Matt has been experimenting quite a bit with what
I've mentioned above.
True, more Trond than I. I've been working on a method of testing, and
have a good workload generator. We're actually not
I re-did facebook-memcached to make it consistent with dustin's github
repository. (No more src subdirectory, and I redid the commit
history so that it appears to be a branch from the original 1.2.3
release at
http://github.com/dustin/memcached/commit/437beab948aec088dac361f27c89f3619fee3228
On Dec 19, 3:27 am, marc kwiatkowski marc.kwiatkow...@gmail.com
wrote:
I re-did facebook-memcached to make it consistent with dustin's github
repository. (No more src subdirectory, and I redid the commit
history so that it appears to be a branch from the original 1.2.3
release at
http
On Dec 19, 9:17 am, Josh Snyder j...@admob.com wrote:
First, we wanted to solve the slab-ghetto problem. That is the
situation where one slab is forcing out hot keys for lack of memory
while another slab holds onto stale objects.
Just wanted to give a +1 that this is an issue for others
Well, there's #3 - rebalance the existing slabs using the slab
reassignment command that nobody knows about. :)
Do tell! :)
On the protocol side: It'd be great to get it added to
http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt
and eventually to the various client
On Sun, Dec 14, 2008 at 3:40 AM, Anatoly Vorobey avoro...@gmail.com wrote:
Tony,
As you mentioned, we don't see any benefit to runtime selection of the
storage engine; thus the indirect call is unnecessary in our environment.
I'm curious about this choice. Have you tried to benchmark the
On 12/14/08 3:40 AM, Anatoly Vorobey avoro...@gmail.com wrote:
Tony,
1. As you mentioned, we don't see any benefit to runtime selection of the
storage engine; thus the indirect call is unnecessary in our environment.
I'm curious about this choice. Have you tried to benchmark the benefit of
As some of you may have noticed we've put facebook's version of
memcached up on github
http://github.com/fbmarc/facebook-memcached
We've done this for a couple of reasons.
First, as far as we know, we run the largest installation of memcached
in the world. We think this is true in terms
Branch friction aside, Paul Saab's description of the interesting
problems is really something worth expanding upon and learning from in
context of a real-world implementation going after C10K scalability.
For example, Paul notes that with thousands of open TCP connections,
memcached can start
+2. Optimism is a welcome change to this discussion, though the proposed
merge-athon is good to hear, as well.
On Sat, Dec 13, 2008 at 12:45 PM, Aaron Stone sodab...@gmail.com wrote:
Branch friction aside, Paul Saab's description of the interesting
problems is really something worth expanding
On Sat, Dec 13, 2008 at 12:45:58PM -0800, Aaron Stone wrote:
For example, Paul notes that with thousands of open TCP connections,
memcached can start using several extra gigabytes of memory for
buffers. Well, that's interesting! I want to know more about that.
What can we learn here?
And at
Hey,
Finally, I produced these branches by running git-svn and git-filter-
branch against our internal SVN repositories. The addition of the
root src directory and the lack of a clear branch from 1.2.3 make
comparison with existing branches unnecessarily difficult. I
apologize for the
I didn't mean anything negative by my post. Please don't take offense.
It was more about confirming the license details in my own head.
On Dec 13, 2008, at 2:53 PM, Todd Berman tber...@gmail.com wrote:
And even if it was GPL licensed
1) They aren't distributing their version of
fyi, Paul Saab's note on facebook's memcached improvements and git
repo (originally pointed out to me by Dustin)
http://www.facebook.com/note.php?note_id=39391378919
+1.
I'm not up for a lecture on how to post patches to a public project right
now, but that isn't the way to go, nor what we've discussed in the past.
-Dormando
I think the results speak for themselves, but I don't know that a
merge can actually occur.
The tree the published is entirely
On Fri, Dec 12, 2008 at 1:46 PM, Dustin dsalli...@gmail.com wrote:
If anyone at facebook is listening, is it possible at all to add
this work onto the codebase where everyone else has been working?
+1
not to mention couldn't that technically be required in the
GPL/whatever license memcached
On Fri, 12 Dec 2008, mike wrote:
On Fri, Dec 12, 2008 at 1:46 PM, Dustin dsalli...@gmail.com wrote:
If anyone at facebook is listening, is it possible at all to add
this work onto the codebase where everyone else has been working?
+1
not to mention couldn't that technically be
Dustin, Dormando:
I must say I am extremely disappointed in your response to our release of our
code base. Perhaps if it were someone with less understanding of our attempts
to merge our changes back, I would be more empathetic.
Let me try to set the record straight:
1. On May 16, 2008, I
27 matches
Mail list logo
