Let's play CacheGraph?

    imageSuppose you have a website. Suppose you optimized it the most “can’t”, but still want more.
    Personally, I wanted to, but for a long time it did not work out.
    When I defeated database slowdown by query caching, block
    slowed down by block caching, and I could not cache entire pages ... The site, of course, began to work much faster, but it started to slow down already ... memcached?


    How many database queries did you have?


    Probably after the start of using caches, requests became few.
    How many cache requests do you have?
    Further only apply to systems using multiple memcached servers. If you do not have memcached, or one server - the effect will be minimal.

    A bit of background


    As philosophers say, everything develops in a spiral.
    Three years ago I was a regular game developer in a small studio, 70% of the time I spent optimizing to catch delays with VTun.
    As you know, one of the main problems in developing video games is minimizing DIP . If in Russian - you render something on the video card, and the processor at the same time waits for synchronization or an answer, in general it’s idle ...
    It turned out that the monster was rendered into 10k triangles and 1k triangles in time the same.
    There were many different ways and tricks to avoid synchronization, or to reduce delays ...
    One of the helpers in this matter was SceneGraph - a rendering tree.
    The bottom line is simple - if possible, render similar objects together so that between the renderings we can change as few different variables as possible.

    Three years have passed, I'm sitting on a hub and reading how Facebook downloaded my memcached ...
    Suddenly, my eyes catch on an expression ... and implement application-level flow control for multi-gets (gets of hundreds of keys in parallel)
    It got me hooked ...

    How it usually works template engines?
    They take a template and QUEUE replace the necessary places with the values ​​that previously QUEUE values ​​were set.

    Imagine the following

    <a href='{OBJECT_HREF►'> {OBJECT_LABEL} </a>

    and it is desirable in a cycle of 100 times ...
    We will also assume that we take variables from the cache.
    Will it be mmmm 200 queries?
    If with different tricky tags (thanks again smira ) - then 400+
    If you didn’t like the task and you would put the entire given block in the cache - then let's assume that we have 5 such blocks on the page, and one suddenly decided to regenerate ...

    Let's make a render of our page, as game engines like to do it - a lot of checkpoints ...
    Pass1 - collect the template, collect the keys used, replace their "places" in the template with some anchors ...
    Pass2 - request all keys with one packet (muti-get).
    Pass 3 - collect the key tags, request a bundle.
    Pass 3 - determine which cache is alive, which is not. For inanimate BUNCH we launch passage 1

    How it works


    We have 5 blocks, 100 elements each.
    In pass2 we ask for 5 keys - the values ​​of 5 blocks
    In pass3 we ask for their tags (we will count them more than five)
    we will assume that two blocks are expired
    Pass3 starts pass1 for two blocks. Then there will be pass 2, which will immediately request 200 keys from two blocks ...

    The result is if all the blocks are “alive” instead of 10 (5 blocks +5 tags) we make 2 requests, 5 in a pack.
    If the block cache is dead we make two requests (100 values ​​+ 100 tags (if any)) instead of 200 ...

    But how to wrap it up.
    You can wrap this in a regular tree. In Count. In CacheGraph.
    We go around the tree, collect unknown keys, as long as they are, request a bundle and crawl along the tree further.
    At the end of a large str_replace of anchors in the template for the received values ​​(or another tree traversal with the substitution of values, as you like)

    The result is minimization of calls to asynchronous sources, minimization of the timeout for synchronization and response. Acceleration of work.
    VERY serious acceleration of work in some tasks

    Bonus: if the cached elements are made standalone, then the tree can be serialized and bypassed, for example, with C ++ ...
    If the cache expires, you can again run a bunch of php with a request to generate standalone blocks ...

    What can I personally say about this?


    Somehow Kashchei the Immortal went to drown. He rushed into the stormy river from the highest bridge ... Then under the train ... Then he jumped from a skyscraper ... Then he kicked into the pool with hydrochloric acid ... Then he swallowed cyanide potassium ... Kashchei had fun , in general, as best he could!

    Also popular now: