Welcome! Log In Create A New Profile

Advanced

Re: Avoiding Nginx restart when rsyncing cache across machines

Quintin Par
September 13, 2018 02:16AM
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 <quintinpar@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 <lucas@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
Subject Author Posted

Avoiding Nginx restart when rsyncing cache across machines

Quintin Par September 11, 2018 07:46PM

Re: Avoiding Nginx restart when rsyncing cache across machines

Maxim Dounin September 12, 2018 10:46AM

Re: Avoiding Nginx restart when rsyncing cache across machines

Quintin Par September 12, 2018 03:42PM

Re: Avoiding Nginx restart when rsyncing cache across machines

Lucas Rolff September 12, 2018 04:08PM

Re: Avoiding Nginx restart when rsyncing cache across machines

Quintin Par September 12, 2018 07:24PM

Re: Avoiding Nginx restart when rsyncing cache across machines

Peter Booth via nginx September 12, 2018 07:32PM

Re: Avoiding Nginx restart when rsyncing cache across machines

Quintin Par September 13, 2018 02:16AM

Re: Avoiding Nginx restart when rsyncing cache across machines

Lucas Rolff September 13, 2018 02:40AM

Re: Avoiding Nginx restart when rsyncing cache across machines

Quintin Par September 13, 2018 02:46PM

Re: Avoiding Nginx restart when rsyncing cache across machines

Lucas Rolff September 13, 2018 04:04PM

Re: Avoiding Nginx restart when rsyncing cache across machines

Peter Booth via nginx September 13, 2018 09:24PM

Re: Avoiding Nginx restart when rsyncing cache across machines

itpp2012 September 14, 2018 02:20AM

Question

Saint Michael September 14, 2018 08:08AM

Re: Avoiding Nginx restart when rsyncing cache across machines

Maxim Dounin September 13, 2018 06:48AM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 95
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready