4 ms·

> throw out "we should add a caching layer" as their first instinct, without considering whether it's really appropriate or not Could be worse: you could have

by lucb1e 2y ago

> throw out "we should add a caching layer" as their first instinct, without considering whether it's really appropriate or not Could be worse: you could have met me! I used to laugh at caching and thought that if your website is so slow that you need a caching layer (Wordpress comes to mind), you're just doing it wrong: perhaps you're missing indexes on your database or you simply can't code properly and made it more complex than necessary (I was young, once). Most of my projects are PHP scripts invoked by Apache, so they have no state and compute everything fresh. This is fine (think <30ms typical page generation time) for 95% of the types of things I make, but in more recent years I had two projects where I really struggled with that non-pragmatic mentality and spent long hours experimenting with different writing strategies (so data wouldn't change as often and MariaDB's built-in optimizations better), indexes on low-cardinality columns, indexes on combined columns in specific orders, documenting with each query which index it requires and maps to, optimizing the query itself of course, in one experiment writing my own on-disk index file to search through some gigabytes of data much faster than the database seemed to be able to do for geospatial information, upgraded the physical hardware from HDD to SSD... Long story short, I now run Redis and the website is no longer primarily bound by computation power but, instead, roughly equally by bandwidth I'm still very wary of introducing Redis to projects lest I doom them: it'll inevitably outgrow RAM if I indiscriminately stick things in there, which means turning them off (so far, nearly no links or tools on my website ever turned 404 because they're all on a "keep it simple" WAMP/LAMP stack that can do its thing for many years, perhaps search-and-replacing something like mysql_query() with mysqli->query() every five years but that's about the extent of the maintenance) So anyway I think we're in agreement about "apply where appropriate" but figured I'd share the counter-example of how one can also be counterproductive in the other direction and that there is something to be said for the pragmatic people that consider/try a cache, which often does help even if there's often a different underlying problem and my perfectionism wouldn't like it

JamesSwift 2y ago
I appreciate that you came around, but I think its important to highlight this common misunderstanding of the role of caching in achieving scaling beyond certain hard boundaries. You previously thought caching was bad, and instead should look at your indexes.... which are just a different kind of cache! I see this disconnect a lot, especially when in ruby/rails world when people think that the bottleneck is going to be the framework, while ignoring that the actual solution to scale is caching in various forms.
- lucb1e 2y ago
  Hmm, I was thinking about that while writing the post but I'm not sure that a data structure is the same as a cache, at least not in the standard meaning of the word where you save a pre-rendered version of something like a website (like what Wordpress needs), or store data closer to where you need it (like a CDN). Some databases, I think SQLite is one of them, don't even have a plain format but store all data in the b-tree. I guess that, to me, a cache must always be redundant: you can delete its contents and lose no data, i.e., start again 'cold' and get back to the warm state algorithmically. That would make the sqlite thing (if I remember it correctly) definitely not a cache to me because the tree == the data. If I add a secondary btree in a database (also in sqlite), however, then that could be emptied with no loss of the original data, and I guess I can see the argument that it prepares the data for quicker consumption (if I'm wording that right) and so it's kind of a cache? Not sure about it though :D but I see what you mean!
  - JamesSwift 2y ago
    A traditional cache is one form of the cache I'm referring to. What I'm arguing, is any form of "cheating" an algorithm is caching. In this case, the base case is full-table scan. If I "cheat" and pre-calculate specific queries and store that ahead of time, thats a cache.

by lucb1e 2y ago

JamesSwift 2y ago

I appreciate that you came around, but I think its important to highlight this common misunderstanding of the role of caching in achieving scaling beyond certain hard boundaries. You previously thought caching was bad, and instead should look at your indexes.... which are just a different kind of cache! I see this disconnect a lot, especially when in ruby/rails world when people think that the bottleneck is going to be the framework, while ignoring that the actual solution to scale is caching in various forms.

lucb1e 2y ago
Hmm, I was thinking about that while writing the post but I'm not sure that a data structure is the same as a cache, at least not in the standard meaning of the word where you save a pre-rendered version of something like a website (like what Wordpress needs), or store data closer to where you need it (like a CDN). Some databases, I think SQLite is one of them, don't even have a plain format but store all data in the b-tree. I guess that, to me, a cache must always be redundant: you can delete its contents and lose no data, i.e., start again 'cold' and get back to the warm state algorithmically. That would make the sqlite thing (if I remember it correctly) definitely not a cache to me because the tree == the data. If I add a secondary btree in a database (also in sqlite), however, then that could be emptied with no loss of the original data, and I guess I can see the argument that it prepares the data for quicker consumption (if I'm wording that right) and so it's kind of a cache? Not sure about it though :D but I see what you mean!
- JamesSwift 2y ago
  A traditional cache is one form of the cache I'm referring to. What I'm arguing, is any form of "cheating" an algorithm is caching. In this case, the base case is full-table scan. If I "cheat" and pre-calculate specific queries and store that ahead of time, thats a cache.