I'd like to detect heavy load and dynamically enable rate limiter code (crafted out of some great (old) code by J Moberg/Arehart). (Can't use IIS request restrictions - not granular enough) I'm running lucee 5.3.10.., with IIS 3/4 times a week my servers get hammered for ~40mins by a pretty sketchy crawler of sorts (runs ~10 IPs (regularly changing IP, plus changes his user agent every call & is not cookie-less) out of AWS, hitting me with 50+ requests/s on complex/resource intensive pages. I see there's some fantastic 'Protection' features in FR to help manage the load, as well as the FRAPI. I will use the WebRequest quantity protection with queue strat, but ideally I would like to throttle the bad IPs, rather than just queue everything so that legit users don't have to wait behind all the garbage requests. Wondering what the best way to detect load is. Looking at the historic FR metrics from when my servers are facing high req/s - seems like the the earliest sign is a high running request count - say > 75. CPU and Memory are not maxed. I see FRAPI has getRunningRequests() - is that too expensive to call often to check load? Any better options? thanks!!

5.3.10 has it's out built in rate limiting

That's fantastic! I missed that new feature. I will need to refactor to be able to use that new Lucee feature as my (inherited) site has pages that serve multiple images thru back end cfm calls - unless there's a way to isolate the rate-limiting to certain page/s, or exclude a couple pages. Will also check out Cloudflare WAF and see if I can get Ops team on board with that. thanks!!

the rate limiting in Lucee is per IP

understood, but if I have a page that triggers 22 other super lightweight cfm calls - to get secured images etc.. then it will trigger the rate-limiting for every user that hits that triggering page

the rate limiting is just downgrading the thread priority, so it depends on the load

ok, good point. I will test it out and then spin it up on one prod node to see how it plays out. you are the best!

setting LUCEE_REQUEST_LIMIT_CONCURRENT_MAXNOSLEEP to like 50 or 100, should avoid that problem. not sure what the concurrent browser limits are these days anyway per host

Oh yeah - forgot about that. Came across that a couple months ago when I was troubleshooting those multiple request pages.. and figured out the AJP connector was running with 127.0.0.1 instead of ::1 - between Chrome's 6 limit and the connector delay - those pages were dog slow 🙂

there's another chrome quirk we hit recently, the same url can only be opened once between tabs

@zackster What do you mean about the same url in multiple tabs? I just opened this page in two tabs no problem.

concurrently with a slow page

Ah, noted.