in reply to Randomization as a cache clearing mechanism

Since you're using MySQL, why don't you use MySQL's query caching mechanism? That's my first question.

The second question is why do you have a separate version table from the nodes table. You have to do two queries anyways ... why not just query the nodes table twice? With an index on (node_id, version) and a query of "SELECT version FROM nodes WHERE node_id = ?", you don't even hit the table because all the info needed is in the index. This is an extremely fast query, made even faster with a query_cache.

Third - would it be possible to cache usernodes separate from thread nodes? I understand that the Everything engine likes to be agnostic about what a node is and does, but if you can cache usernodes separate from thread nodes, then you have a very slight performance hit from having the find the right cache, but each cache thrashes less.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

  • Comment on Re: Randomization as a cache clearing mechanism

Replies are listed 'Best First'.
Re^2: Randomization as a cache clearing mechanism
by waswas-fng (Curate) on Nov 19, 2004 at 21:07 UTC
    MySQL's query cache works differently that you expect or you did not think that through. It keys the cache off the select string, On queries that do not repeat often there is up to a 13% overhead for the cache code (housekeeping). Because they do 100's of hits per page load the cache would fill with low hit % data and just be a liability. MySQL's query cache starts to make sense when you have a complex query that thrashes and only has a few thousand (up to ~ forty or so thousand) select variants that are executed often. It can also be noted that they even state that the theoretical speedup (given ~100% cache hits) is only around 220%. You can tweak the cache size with query_cache_limit but mind you as you increase the size the overhead goes up -- worst case is worst, best case is worse.


    -Waswas
[reply]
      I'm very well aware of how MySQL's query caching works - I built a reporting system around it. With a good 10-50M cache, you can do a whole heck of a lot of good. The important things about it are:
      1. You can just turn it on - there are no code or schema changes. This makes it easy to benchmark.
      2. It handles all the aging for you in very optimized C. You say there's a 13% overhead. I'm guessing that demerphq's plans may end up with a 50-150% overhead in the average case.

      In addition, I'm going to guess that there's going to be a much higher gain that you might think. Many of the hits, I'm guessing, have to do with invariants - monk data, nodelet data, and the like. I know I do at least 400 pageviews/day on this site, and I'm a low-hit regular. If half the queries for just the regulars get to be cached, then that's at least a 13% savings right there.

      So, yes, it does work as I think and I did think it through. It's not the ideal solution, but it's definitely a quick-hit easy one, as well as easy to verify - just turn it on for a week and see how performance plays. If it doesn't work, then turn it off. No harm, no foul.

      Being right, does not endow the right to be rude; politeness costs nothing.
      Being unknowing, is not the same as being stupid.
      Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
      Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]
        I would be interested to see if this makes and net gain on the PM site. I would think that many basically randomized hits against his indexed table is already performing at very close to minimal cost ( O(log n) -- it is indexed). So it would seem to only add extra housecleaning steps to the database (create cache, hook on updates/inserts in to invalidate cache, expire cache, memalloc, losing actual memory to cache indexes) for the population of a cache that by all common sense would have a low hit rate anyways (the items are atom like in nature -- too many/random to cache or cache better than the initial performance of 0(log n) ). I agree that it is an easy test to do, no actual data has to be changed. It would just be very counter intuitive to me if it did enhance performance in this case. I would think a redesign that treats the cache items in a different scope would be an area that would have more profound impact on performance. treat nodes of different types in different specialized ways with a better data structure for caching.


        -Waswas
[reply]

In Section Seekers of Perl Wisdom