Add estimated wait time #26

New Issue

henry · 2025-06-25T23:32:56Z

henry commented

2025-06-25 23:32:56 +00:00

Potential implementation for rough estimate:

Add property AccessGrantedOn to User object
Set AccessGrantedOn = DateTime.UtcNow whenever user is granted access
Define a constant for sample time SAMPLE_PERIOD
int usersAddedRecently = accessTickets where AccessGrantedOn < UtcNow - SAMPLE_PERIOD
const avgReleaseTime = SAMPLE_PERIOD / usersAddedRecently
estimatedWaitTime = avgReleaseTime * requestsAhead

Estimating avgReleaseTime will require iterating entire access dictionary
For performance we should do this periodically and cache avgReleaseTime

Also, there should be a threshold for when an estimate is given. Estimate shouldn't be given if there isn't enough data to make a good guess. Maybe at least 2 users in SAMPLE_PERIOD

This is a poor estimate but would be quick to implement

For a better estimate I would have to track how long each user spends active once they get access. This still isn't perfect because there isn't a definite end to a session. If user A goes inactive, user B gains access, then user A comes back, the number of simultaneous user exceeds capacity, which the algorithm doesn't account for. Unsure how often this would happen, but it would inflate queue time.

Potential implementation for rough estimate: Add property AccessGrantedOn to User object Set AccessGrantedOn = DateTime.UtcNow whenever user is granted access Define a constant for sample time SAMPLE_PERIOD int usersAddedRecently = accessTickets where AccessGrantedOn < UtcNow - SAMPLE_PERIOD const avgReleaseTime = SAMPLE_PERIOD / usersAddedRecently estimatedWaitTime = avgReleaseTime * requestsAhead Estimating avgReleaseTime will require iterating entire access dictionary For performance we should do this periodically and cache avgReleaseTime Also, there should be a threshold for when an estimate is given. Estimate shouldn't be given if there isn't enough data to make a good guess. Maybe at least 2 users in SAMPLE_PERIOD This is a poor estimate but would be quick to implement [For a better estimate I would have to track how long each user spends active once they get access.](https://docs.rocket.chat/docs/estimated-wait-time-ewt-algorithm) This still isn't perfect because there isn't a definite end to a session. If user A goes inactive, user B gains access, then user A comes back, the number of simultaneous user exceeds capacity, which the algorithm doesn't account for. Unsure how often this would happen, but it would inflate queue time.

henry added the

enhancement

label 2025-06-25 23:33:05 +00:00

Sign in to join this conversation.

No Label

bug

enhancement

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: henry/AccessQueueService#26