3 ms·
I'm surprised I haven't heard it mentioned yet, but Varnish can ward off an awful lot of request floods. If these pages aren't changing frequently (particularly
by cheald 13y ago
I'm surprised I haven't heard it mentioned yet, but Varnish can ward off an awful lot of request floods. If these pages aren't changing frequently (particularly if they are outdated or shouldn't be accessible), then Varnish should be able to cache and respond with them trivially. This will take a tremendous amount of load off of your actual app servers.
Additionally, Varnish has ACLs which make it possible to reject requests based on whatever patterns you choose (source IP, request structure, etc). While it puts you into an arms race, if you can identify a pattern in the bad traffic, you can short-circuit it before it ever becomes an actual problem. Black-holing poorly-behaved clients is very easy, and can let you absorb very high request concurrency with extremely little effort.
Varnish also makes it very easy to locate URLs and IPs being used in these sorts of things, via varnishtop and varnishlog. For example, `varnishlog -i RxURL` gets you a constantly-updated list of the URLs being hit most frequently, or `varnishlog -i SessionOpen` will get you a list of the most common client IPs. With that kind of information, doing reactive filtering becomes very easy.