-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make RADIUS timeout value configurable #3185
Comments
Could you further, how such a high ping could happen? |
@CommanderStorm for basic scenarios the Radius will verify access quickly using internal means. |
So basically the avg number you would expect for Laltency is below the current value, right? Is the Usecase you are talking about not better solved via the |
@I71d0r is 100% spot on. While most RADIUS requests should take less than 2.5 seconds to complete, there are instances where this simply takes more time. It's not 'Down', as the response is eventually set. Sometimes that takes as much as 10 seconds, but this is normal and expected behavior, even if it's not optimal. That means you shouldn't receive an alert for something that is normal/expected behavior. That's what causes alert fatigue and causes people to ignore alerts because they're not confident they are accurate. Retries as I understand them aren't going to solve the problem if the response is going to take 10 seconds to complete. What retries are doing is 'continue retrying X number of times, or until the response takes only 2.5 seconds' That's not the same thing as a configurable timeout value. Especially for other instances where the normal average response time is greater than 2.5 seconds. You could retry forever, but it might not ever complete in 2.5 seconds. |
@aLTeReGo-SWI please answer all my questions So basically, the avg number you would expect for Latency of What you say would be a good helptext in the monitor setup to distinguish between |
@CommanderStorm Latency varies based on the request. If a request comes in that has cached data, the response is relatively quick. Less than a second on average. Requests that are not cached take longer to be served. Upwards of ~10 seconds Increasing the retries simply results in hammering the same request stacking up these requests in the queue, causing further delaying the response. A 'retry' is.. this was down.. E.G. it exceeded the timeout value. That timeout value right now is 2.5 seconds, but it might come back so try again. A 'timeout' is how long should I wait for my request to be responded to before giving up, and retrying if a retry value is configured. Also, I may be mistaken but the little bits of yellow on my availability charts suggest that retries count against overall availability. An extended timeout value should not if the request was serviced within the user-definable timeout period. |
🏷️ Feature Request Type
UI Feature
🔖 Feature description
The RADIUS monitor appears to have a hard-coded 2500ms timeout, though it could be two 1-second and another 30-second timeout.
We have instances where RADIUS requests can take as much as 10 seconds to respond. It's not performant, but it isn't 'down' either. Making this value configurable would alleviate a lot of the false positives I'm seeing.
✔️ Solution
Add a new UI element to monitor that allows for the input of a user-defined integer timeout value
❓ Alternatives
Increase the hard coded timeout values to be higher. Not a good solution, but it is an alternative.
📝 Additional Context
No response
The text was updated successfully, but these errors were encountered: