On Oct 4, 2022, at 9:45 AM, Winfield, Alister (Senior Solutions Architect) via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Remember that the query may take <1s but the time for the query response at the client can be >5s. Its often because there is a queue built up of requests and the DB is too slow to service them thus the ‘enqueued’ ones are around for too long. Fixing is mostly make the DB faster eg by adding another server and synchronising the data, fixing indexes, ensuring queries aren’t idiotic (eg full table scans). Sometimes it’s the network eg TLS using a dumb slow random number source that’s not getting enough entropy so blocking or perhaps might be packet loss, etc etc etc.
What happens in most of these discussions is the advice to specifically check about 5 different things. DB size, indexes, etc. When the response is "I only checked one thing", that's a recipe for continued problems.
Sadly, this is all about analysing the system bit by bit until you find the real issue and fixing that.. For your sanity start at the bottom of the stack and work up. FreeRadius is highly unlikely to be the problem. It comfortably handles 30K requests per second and without much effort can do much more.
Yup/ It's not that the "SQL slow query log" is lying. It's not. But it's also not testing end-to-end functionality. There's a lot more going on in the network, SQL database, etc. The FreeRADIUS "SQL module is blocked" message *is* testing end-to-end functionality. It's testing *all* of the time from "FreeRADIUS asked SQL a question" to "SQL returned an answer 10 seconds later". That log message *never* lies, and it *always* indicates a problem. Alan DeKok.