in reply to Re^4: Randomization as a cache clearing mechanism
in thread Randomization as a cache clearing mechanism

I see. We've got a large webmail installation here. Millions of users. All our backend web servers cache complex objects to a dedicated box with memcached, so we "spoil" cache on update as you say. And even if there's no dedicated cache box, I think it's worthwhile to at least try this strategy. In the case of current PM it will involve either propagating the "spoiling" to all neighbours via tcp/ip or storing the cache inside mysql database instead of web server RAM. I realize that these are big infrastructural changes and are hard to implement, though.

Also, I'd try to invest more time in increasing complexity of objects in the cache. Nodes seem to be "atoms" on PM. Too primitive and numerous to cache separately. There could be ways to cache whole threads with all nodes glued together to form a more high-level object. Nodelets are good candidates too. Do I make sense? I've implemented it for whole MIME structures and mailbox listings here in our webmail system. That payed off.

By "trying" I always mean "benchmarking a simple prototype" :)

P.S. The buttons on my calculator (old soviet Electronica) are ln, log and lg -- for natural, arbitrary and decimal logarithms, so perl (and C) log confuses me too.

  • Comment on Re^5: Randomization as a cache clearing mechanism

Replies are listed 'Best First'.
Re^6: Randomization as a cache clearing mechanism (races)
by tye (Sage) on Nov 20, 2004 at 19:17 UTC

    I looked at memcached quite a while ago (seems like 2 years but probably hasn't been that long). My immediate impression was that they needed to get rid of the biggest race condition in their design.

    I wrote the authors and they noted that they had gotten the same request (support a revision field in the data and prevent old data from overwriting new data). It appears that they still haven't managed to implement this simple and, IMO, important idea.1

    Without that, I wouldn't use memcached for the more difficult PM caching problems, that is, things that get updated frequently such as the CB.

    Of course, adding this to the open source project would probably not be that difficult of a task. And memcached could still be useful for PM without it.

    - tye        

    1 Preventing old data overwriting new data still allows for races, but it is much better and is the best PM will ever do.

    memcached should also be fixed to support optimistic locking which can be race-free but any update might fail and have to be presented to a supervisory function (usually the user) to figure out how to handle the failure (and such for PM would suck more than the limited race conditions possible without going to optimistic locking).

    To support optimistic locking, memcached would need to allow updates that say "here is the new data and it replaces revision X" and cause the update to fail if revision X isn't the current revision (and do updates atomically, which shouldn't be hard and I think is already the case based on my understanding of their design).

    But in any case, memcached is in serious need of a way for it to track revisions (such as a version number like PM's node cache uses or a timestamp -- I'd just support any byte string where a simple 'cmp' determines which is newer and possibly also support variable-length digit strings).

[reply]

      Hm. The memcached API has five principal commands: get, add, set, replace & delete. Distinct add which fails in case the key is already present in the cache along with a deletion delay helps prevent races (not completely). I think that developers' intention is to avoid introducing locks or versions by all costs.

      And yes, I wouldn't use memcached in a banking environment, it seems to be a MySQL-type product -- speed ahead of reliability.

      Thanks for bringing it up. Doing things which will not do much harm to humanity in case of failure tends to shift priorities :)

[reply]
[d/l]
[select]
        speed ahead of reliability

        In fact, if a cache were to handle concurrency and data integrity perfectly, it would be pretty durn close to being an RDBMS, which would be much beside the point.

[reply]
Re^6: Randomization as a cache clearing mechanism
by demerphq (Chancellor) on Nov 20, 2004 at 12:13 UTC

    I have to say this really interesting. Unfortunately im flying off on holiday in a few hours so I wont be able to look into it further until I return.

    And yes, part of the compiled code caching stuff ive been tinkering with does things like that. Anyway till later, thanks. :-)

    ---
    demerphq

[reply]

In Section Seekers of Perl Wisdom