The manpage says:
-k Lock down all paged memory. This is a somewhat
dangerous option
with large caches, so consult the README and memcached
homepage
for configuration suggestions.
README says:
Also, be warned that the -k (mlockall) option to memcached migh
Qiangning Hong wrote:
The manpage says:
-k Lock down all paged memory. This is a somewhat
dangerous option
with large caches, so consult the README and memcached
homepage
for configuration suggestions.
README says:
Also, be warned that the -k (mlockall)
Not sure FNV is available in PHP, at least a quick search on google
didn't result in much.
More commonly available hash functions:
http://us3.php.net/manual/en/function.hash-algos.php
Seems the cheapest out of these would be md2
http://us3.php.net/manual/en/function.hash.php#89574
Might b
We ported it over quite a ways back and to be honest I don't remember
what we did to make this all work. The code is public domain (as per
fnv.h) I _think_ this version has the correct int size for 64 bit.
We ran into a problem with the end result being calculated different
on 32 bit v
Thanks for the link. Where did this package come from? (can't seem to
find it's home)
Doesn't compile in its current state:
In file included from /home/zyounker/Desktop/fnv/fnv.c:1:
/home/zyounker/Desktop/fnv/php_fnv.h:1:3: error: invalid preprocessing
directive #Ported
make: *** [fnv.lo] E
Well, the code to handle FNV is from http://isthe.com/chongo/tech/comp/fnv/
Packaging it into PHP was done by 2 of our engineers. We never had
a chance to release it, I am going to see if I can post it as a google
project.
That first line was my fault. I wanted to make sure they got cr
Is this bug present in 1.2.8?
Evan
On Thu, Apr 2, 2009 at 12:56 PM, Dustin wrote:
>
>
> On Apr 2, 1:03 am, Toru Maesaka wrote:
>
>> So we've been testing memcached-1.3.2 beta at mixi.jp for
>> a week and we found an issue in the stats code.
>>
>> The problem is that the server segfaults if we
Shouldn't be ... the allocation is the same, but no new stats have been
added into stats slabs under 1.2.8, so the allocation is still "correct".
-Dormando
On Mon, 13 Apr 2009, Evan Weaver wrote:
>
> Is this bug present in 1.2.8?
>
> Evan
>
> On Thu, Apr 2, 2009 at 12:56 PM, Dustin wrote:
> >
>
It would be great if you could get this released, specifically a pecl or
pear package would be nice.
I'd love to include it in brutis as it is obviously a much faster hash
then the ones available.
If you need any help getting it packaged up, feel free to contact me
directly and I can help
memcached-prefix is an experimental fork off of the memcached 1.3
development branch. It adds commands pget and pdelete that operate on
ranges of keys having a common prefix. The new commands can be used as
a simple namespace mechanism. It also adds a memcachedb compatible
rget command.
Performan
Interesting... have you tested it with multiple clients? Do you think
there's any reason to believe that more clients would cause degradation?
Have you considered making this an option? I'm assuming the most common
response to this will be "Memcached works very well for what it was
designed. Don't
Hi!
Dustin and I were talking about adding this sort of command as an
option to the protocol description for Memcached. If we could come up
with a standard, I would love to add it to libmemcached.
Cheers,
-Brian
On Apr 13, 2009, at 9:26 PM, Mike Panchenko wrote:
Interesting... ha
The benchmark numbers on the page were done with 4 client threads. I
did a little testing with more and there wasn't any problem. I didn't
expect that it would given that there were no changes to the
networking code, locking or thread management.
I plan on making memcached-prefix into a plugin en
Basically whatever you guys make standard I'll put into the branch.
The pget and pdelete were just the simplest thing I could come up with
that would do the job. What do you think?
The rget command I copied from memcachedb. The only thing I don't like
about it is that I think the end key should
Hi,
I recently shifted to using the memcached_get/set_by_key APIs. The trouble
is that even after warming the cache with all of the content, a subsequent
query to fetch the key/value pair fails with a not found error. I am seeing
this behaviour in a 2-node memcached cluster.
Its occurring consist
15 matches
Mail list logo
