Skip to content

Instantly share code, notes, and snippets.

@LukeHandle

LukeHandle/Minotar.net Ideas.md

Created October 27, 2015 23:25
Show Gist options
  • Save LukeHandle/218ff96b3a344636edc9 to your computer and use it in GitHub Desktop.
Save LukeHandle/218ff96b3a344636edc9 to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. LukeHandle created this gist Oct 27, 2015.
    70 changes: 70 additions & 0 deletions Minotar.net Ideas.md
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,70 @@
    # Minotar.net Ideas

    ## Caching

    Is there another alternative to `Redis` that may offer supplier cache retrieval?

    Where possible splitting off into different Redis instances also offers advantages. We can attempt to multi-thread the process.

    ### Key System:

    Different caching methods which we could use for getting a skin based on UUID or USERNAME.

    #### Idea 1:
    ````
    SKIN HASH => GOB of minecraft.Skin object
    (this not unique to a user)
    UUID => SKIN HASH
    USERNAME => SKIN HASH
    ````


    #### Idea 2:
    ````
    UUID => GOB of minecraft.Skin object
    USERNAME => UUID
    ````

    The chances are, most users will have a unique skin. Will the gain from caching the non-unique ones be advantageous over the cost of then caching the SKIN HASH 2 extra times within Redis?

    Number of Cache Lookups to get Skin:
    * Idea 1:
    * UUID: 2
    * USERNAME: 2
    * Idea 2:
    * UUID: 1
    * USERNAME: 2

    Idea 2 should result in a quicker skin retrieval from Cache.

    #### Maybe an Idea 3:

    ````
    OBJECT HASH => GOB of minecraft.Skin object
    (this *is* unique to a user)
    UUID => OBJECT HASH
    USERNAME => OBJECT HASH
    ````

    Worst usage of space as we cause every skin to be stored, AND we then cache the HASH twice more. Each retrieval still requires 2 lookups:
    * Idea 3:
    * UUID: 2
    * USERNAME: 2

    The minor advantage gained is that we can perform "isset" on Redis when receiving "If-None-Match" headers. We know that if it's in the cache, it's still valid. A 304 can then be generated in record time and we don't need to do a full retrieval, just a check whether the hash is there (skipping UUID or USERNAME lookups).

    If we ever implemented a stale (grace) caching feature, this functionality would be lost. Also, probably not worth the minor gain to butcher the cache system.

    ___Probably prefer Idea 2___

    ### Varnish

    * Add regex checks similar to imgd for routing and early error detection
    * Look to normalize strings to optimize for caching
    * Change case to lower
    * Remove hyphens from UUID
    * Add collectd stats monitoring
    * Potentially could implement a Redis lookup feature (basic check for 304)