Hi Peter,
Here are my stats for this week: https://imgur.com/a/JloZ37h . The Bypass is only because I was experimenting with some cache warmer scripts. This is primarily a static website. Here’s my URL hit distribution: https://imgur.com/a/DRJUjPc If three people are making the same request, they get identical content. No personalization. The pages are cached for 200 days and inactive in proxy_cache_path set to 60 days. This is embarrassing but my CDNs are primarily $5 digital ocean machines across the web with this Nginx cache setup. The server response time averages at 0.29 seconds. Prior to doing my ghetto CDNing this was at 0.98 seconds. I am pretty proud that I have survived several Slashdot effects on the $5 machines serving cached content peaking at 2500 requests/second without any issues. Since this is working well, I don’t want to do any layered caching, unless there is a compelling reason. - Quintin On Wed, Sep 12, 2018 at 4:32 PM Peter Booth via nginx <nginx@nginx.org> wrote: > Quintin, > > Are most of your requests for dynamic or static content? > Are the requests clustered such that there is a lot of requests for a few > (between 5 and 200, say) URLs? > If three different people make same request do they get personalized or > identical content returned? > How long are the cached resources valid for? > > I have seen layered caches deliver enormous benefit both in terms of > performance and ensuring availability- which is usually > synonymous with “protecting teh backend.” That protection was most useful > when, for example > I was working on a site that would get mentioned in a tv show at known > time of the day every week. > nginx proxy_cache was invaluable at helping the site stay up and > responsive when hit with enormous spikes of requests. > > This is nuanced, subtle stuff though. > > Is your site something that you can disclose publicly? > > > Peter > > > > On 12 Sep 2018, at 7:23 PM, Quintin Par <quintin...@gmail.com> wrote: > > Hi Lucas, > > > The cache is pretty big and I want to limit unnecessary requests if I can. > Cloudflare is in front of my machines and I pay for load balancing, > firewall, Argo among others. So there is a cost per request. > > > Admittedly I have a not so complex cache architecture. i.e. all cache > machines in front of the origin and it has worked so far. This is also > because I am not that great a programmer/admin :-) > > > My optimization is not primarily around hits to the origin, but rather > bandwidth and number of requests. > > > > - Quintin > > > On Wed, Sep 12, 2018 at 1:06 PM Lucas Rolff <lu...@lucasrolff.com> wrote: > >> Can I ask, why do you need to start with a warm cache directly? Sure it >> will lower the requests to the origin, but you could implement a secondary >> caching layer if you wanted to (using nginx), so you’d have your primary >> cache in let’s say 10 locations, let's say spread across 3 continents (US, >> EU, Asia), then you could have a second layer that consist of a smaller >> amount of locations (1 instance in each continent) - this way you'll warm >> up faster when you add new servers, and it won't really affect your origin >> server. >> >> It's a lot more clean also because you're able to use proxy_cache which >> is really what (in my opinion) you should use when you're building caching >> proxies. >> >> Generally I'd just slowly warm up new servers prior to putting them into >> production, get a list of top X files accessed, and loop over them to pull >> them in as a normal http request. >> >> There's plenty of decent solutions (some more complex than others), but >> there should really never be a reason to having to sync your cache across >> machines - even for new servers. >> >> _______________________________________________ >> nginx mailing list >> nginx@nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx > > _______________________________________________ > nginx mailing list > nginx@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx > > > _______________________________________________ > nginx mailing list > nginx@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
