Understanding web caching (Redis)
Asked Answered
E

1

8

I'm working on a web app that receives data from an API provider. Now I need a way to cache the data to save from calling the provider again for the same data.

Then I stumbled on Redis which seems to serve my purpose but I'm not 100% clear about the concept of caching using Redis. I've checked their documentation but I don't really follow what they have to say.

Let's suppose I have just deployed my website to live and I have my first visitor called A. Since A is the first person that visits, my website will request a new set of data over API provider and after a couple seconds, the page will be loaded with the data that A wanted.

My website caches this data to Redis to serve future visitors that will hit the same page.

Now I have my second visitor B.

B hits the same page url as A did and because my website has this data stored in the cache, B is served from the cache and will experience much faster loading time than what A has experienced.

Is my understanding in line with with the concept of web caching?

I always thought of caching as per user basis so my interaction on a website has no influence or whatsoever to other people but Redis seems to work per application basis.

Expletive answered 15/10, 2015 at 21:13 Comment(0)
M
9

Yes, your understanding of web caching is spot on, but it can get much more complex, depending on your use case. Redis is essentially a key-value store. So, if you want application-level caching, your theoretical key/value pair would look like this:

key: /path/to/my/page
value: <html><...whatever...></html>

If you want user-level caching, your theoretical key would just change slightly:

key: visitorA|/path/to/my/page
value: <html><...whatever...></html>

Make sense? Essentially, there would be a tag in the key to define the user (but it would generally be a hash or something, not a plain-text string).

There are redis client libraries that are written for different web-development frameworks and content-management systems that will define how they handle caching (ie. user-specific or application-specific). If you are writing a custom web app, then you can choose application-level caching or user-level caching and do whatever else you want with caching.

Malformation answered 15/10, 2015 at 22:45 Comment(4)
Thanks for taking time to explain this. It's helping a lot. Is application-leve caching more of a common choice for web? What would be the pros and cons of those choices?Expletive
I would guess application-level caching is more common because it generally gives better performance improvements than user-level caching. A user-level caching is really only effective if you get the same user hitting the same resource-intensive pages over and over. Application-level caching is just plain easier, and you get significant caching benefits (because all users benefit); but the minute the content differs between users, you have to drop to user-level caching. You can cache by page section, too, where some divs are cached for all users and some are user-specific. Hope that helps!Malformation
There are also other types of caching out there that speed things up. For example, PHP has APC caching, which is a bytecode-level caching of the code itself, and that can cut latency in half easily, while allowing user-specific experiences. Really easy to use, and there a bunch of others out there.Malformation
Thank you. It helped a lot.Expletive

© 2022 - 2024 — McMap. All rights reserved.