Minotar.net Ideas.md

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)