6 ms·

Maybe I'm missing something here, but I was under the impression Redis is one of the fastest data stores out there. What do you mean it would blow the latency

• amalag 15y ago
  He means it is being compared to CPU cache (from the article), so there is tens of orders of magnitude difference. From this summary on stack overflow: http://stackoverflow.com/questions/433105/exactly-how-fast-are-modern-cpus http://stackoverflow.com/questions/433105/exactly-how-fast-a... CPU registers (8-32 registers) – immediate access (0-1 clock cycles) L1 CPU caches (32 KiB to 128 KiB) – fast access (3 clock cycles) L2 CPU caches (128 KiB to 12 MiB) – slightly slower access (10 clock cycles) Main physical memory (RAM) (256 MiB to 4 GiB) – slow access (100 clock cycles) Disk (file system) (1 GiB to 1 TiB) – very slow (10,000,000 clock cycles) Remote Memory (such as other computers or the Internet) (Practically unlimited) – speed varies
  • pkulak 15y ago
    But if you have a Redis cache on the same box (he says he only has one box anyway) it's still in the same category: "Main physical memory", with maybe some communication overheard.
    • willvarfar 15y ago
      "maybe some communication overheard" is orders of magnitude slower than L1/L2. Hmm, there is something very wrong here. I'll try and explain in a blog post.
      • pkulak 15y ago
        But we're not talking register caches. 800 megs stashed in a giant Java hash are not going to be in L1 or L2 cache.
        • willvarfar 15y ago
          http://williamedwardscoder.tumblr.com/post/18065079081/cogs-bad#comment-446733732 http://williamedwardscoder.tumblr.com/post/18065079081/cogs-... might be interesting
    • willvarfar 15y ago
      http://williamedwardscoder.tumblr.com/post/18065079081/cogs-bad http://williamedwardscoder.tumblr.com/post/18065079081/cogs-...
• gizzlon 15y ago
  There is a HUGE overhead when going through the network. Even if you don't (localhost), there's overhead when using TCP/IP. Even if you don't, there's a overhead when using UNIX sockets or whatever you use for Inter-process-communication. It probably doesn't matter though.. And yes, Redis is very fast and you gain a lot when using it compared to just a Hash in the same process.
  • tfb 15y ago
    So are you saying that because of the overhead involved with "talking" to redis, the fastest datastore would actually be an implementation of my own version (or a readily available version like node-lru-cache) of an LRU cache in my node app script - the datastore would essentially be a simple JSON object embedded directly in the script with methods specific to LRU data sets, gets, and backup?
    • gizzlon 15y ago
      well, the point is only that In-process is the fastest there is. By using something like Redis you give up a some speed but gain features: ques, pub/sub etc etc.. But that doesn't mean you have to implement those features yourself, they might be available as a library for your language of choice as well. The bigger win, IMHO, is that you gain flexibility: Since Redis (or whatever) is decoupled from you process it can run on another processor, another machine or perhaps run on many machines etc.. Not sure how in-process cache would work in node, being async and all, but yes in-process is faster. But then you have to think about stuff like: - how do you avoid loosing everything when node crashes / restarts? - what if another process needs to read write to the cache? - what if you need more memory than a single machine provides (probably not going to happen). - implementation bugs In-process: Faster but probably harder to scale. But then again, it might be so fast you don't have to.
      • willvarfar 15y ago
        Would Redis evicting something from the LRU make some older mails unreadable?