On Wed, 1 Jul 2009, Stephen John Smoogen wrote:
> On Wed, Jul 1, 2009 at 6:08 PM, Mike McGrath<mmcgrath@xxxxxxxxxx> wrote:
> > On Wed, 1 Jul 2009, Stephen John Smoogen wrote:
> >
> >> On Wed, Jul 1, 2009 at 3:33 PM, Mike McGrath<mmcgrath@xxxxxxxxxx> 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.
-Mike
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
