memcached opinions

[Toshio Kuratomi]

On 07/01/2009 05:39 PM, Mike McGrath wrote:
> On Wed, 1 Jul 2009, Stephen John Smoogen wrote:
> 
>> On Wed, Jul 1, 2009 at 6:08 PM, Mike McGrath<mmcgrath at redhat.com> wrote:
>>> On Wed, 1 Jul 2009, Stephen John Smoogen wrote:
>>>
>>>> On Wed, Jul 1, 2009 at 3:33 PM, Mike McGrath<mmcgrath at redhat.com> wrote:
>>>>> I'm not sure if we have any memcached experience on the list but I thought
>>>>> I'd ask.  Can anyone explain this:
>>>>>
>>>>> http://pastebin.ca/1481219
>>>>>
>>>>> Notice how memcached1 has a much higher hit rate and memcached2 has a much
>>>>> lower hit rate?
>>>>>
>>>>
>>>> The time for memcached1 is 5x less than memcached2 being up. That can
>>>> have an effect on caching as right after a system comes up its rates
>>>> are usually much higher and then over time fall off (iirc). I think it
>>>> would take bringing both up at the same time to figure out if there is
>>>> a true disparity over caching.
>>>>
>>>
>>> I thought that exact same thing :)
>>>
>>> memcahed1:
>>> STAT uptime 9143
>>> STAT get_hits 311736
>>> STAT get_misses 11255
>>>
>>> memcached2:
>>> STAT uptime 9144
>>> STAT get_hits 49679
>>> STAT get_misses 11116
>>>
>>
>> Now that shows something not kosher. My guess is some app is not
>> talking to both? What apps use memcached for what?
>>
> 
> I was just talking to ricky about this a bit in IRC.  So here's the scoop.
> 
> We've got mediawiki using memcached for a couple of things, including
> session data (which is weird and wrong but fast).
> 
> The recent addition to the group is Fedora community, specifically in it's
> implementation of beaker.  I'm going to get ahold of luke tomorrow to
> verify and test some stuff but I think this line in the config:
> 
> beaker.cache.url = memcached1;memcached
> 
> I'm not sure how beaker reads that, but I suspect it might be only sending
> information to memcached1 and ignoring memcached2 altogether.  If this
> theory holds it'd explain why memcached1 not only has a higher request
> rate but also a higher hit rate because I suspect fedoracommunity requests
> some of the same info over and over again compared to the wiki which
> probably has a broader data pool it pulls from.
> 
easy test: reverse that:

beaker.cache.url = memcached2;memcached1

and see if the cache hit ratio reverses itself.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20090701/d8b2fb42/attachment.bin