Caching is, in general, a good thing. But it's worth thinking about how you do it. I recently sped up a large system by dropping the use of redis entirely - because it was being badly used.
During a single request there might be 50+ cache-lookups, each taking a round-trip to a remote redis server to fetch a single key at a time. Batching those up to a set/hash would have been more efficient, but the codebase had evolved in such a way as to make that difficult.
Instead of making 50+ redis fetches it turned out that just fetching all the stuff from the database was faster.
(There will be refactoring to batch up the key fetches, but for the moment there was a measurable increase in performance under current loads just by removing redis.)
Perhaps, yes. It was the latency of the network calls that was killing performance, so something local, or even redis on localhost, would have been better.
During a single request there might be 50+ cache-lookups, each taking a round-trip to a remote redis server to fetch a single key at a time. Batching those up to a set/hash would have been more efficient, but the codebase had evolved in such a way as to make that difficult.
Instead of making 50+ redis fetches it turned out that just fetching all the stuff from the database was faster.
(There will be refactoring to batch up the key fetches, but for the moment there was a measurable increase in performance under current loads just by removing redis.)