>> Well, they delivered (I'm guessing) 10x improvement in a month by adding cache

>No, they didn't. That's the problem. No cache gets you 10x.

I was actually being conservative. We had almost 100x increase in some cases.

It was pretty particular app, site took few hundred (IIRC closer to second mark) ms to generate before we started at all.

First it was simple Varnish cache but that had problems, some components never changed, other were updated pretty often (stuff like "current users here")

First it was split to various components, each with different TTLs, then all of that was merged in Varnish ESI.

So you could say invalidate a part of the site and varnish would

* load this component from app server

* load the template it contains from its own cache

* render it.

So

* no refresh would be just direct from cache, single digit ms or lower latency

* refreshing one part of site would have latency of rendering only that tiny part of site on app server

later we also updated that with "grace" feature of Varnish where you could define time interval where cache would be valid but generate request to the backend to refresh

So if said low TTL component was refreshed often

* the component will always go from cache with lowest latency

* if it was on its last seconds varnish would send the request in the background and refresh cache

Now the app itself wasn't very well written in the first place (there is a book of horror stories to write about it) but they (we did ops and testing, they did the app stuff) spent less time than "fixing it properly" and instead rewrote it to a bit more modern architecture. They still use same cache to cache JSON responses to API endpoints tho.

That not even to say how much of DB performance is actually clever caching, after all index is just pre-generated partial cache...

But sure, some apps are better for it than other, 10x is definitely not universal.

> From then on each cache is going to net you less, and less, and less. Only if someone measured wrong or you are blocked by some architecture change that's needed so that caches even make sense, will you see a bigger improvement this year than you did last.

Well, doh, caching something you cached already ain't gonna be that effective. But if you see same request with same done 100 times in a minute, making it take 20ms instead of 100m ain't gonna be as effective as making it take 100us to get from cache. You might want to address it eventually to have lower jitter, but same cache can allow you to make 20 other methods faster on average and that is less code and effort than optimizing 20 other functions..

> I have a couple coworkers who are trying to be clever with a new cache architecture. Irritatingly by taking a statement of fact made by me 3+ years ago and jumping to the wrong conclusion. They promised 50% in 18 months (I was suggesting we target 90% in three years). Now we are somewhere past 30 months and so far they've delivered lower numbers than I did in 5 man weeks spread out from Christmas to mid March, while juggling other priorities and suffering from Seasonal Affective Disorder.

And do you think they would be able to instead go and optimize it better in that time ? That just sounds like incompetent co-worker and not anything to do with cache...