-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Azure storage account queue scaler should allow users to select peek or approximate method #3555
Comments
Can't this issue be resolved by using the accurate strategy for sclaed job configuration? |
I believe that feature is for |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. |
Leaving a comment to prevent the issue from being closed as stale. This is still critical to use Azure storage queues effectively. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. |
Issue has been resolved with the above PR! |
Proposal
Azure storage account queue scaler supports users defining the "peek" or "approximate" methods for evaluating the queue length.
Use-Case
Using Azure storage account queues to trigger a mix of short and longer running jobs using the Azure Functions runtime.
Anything else?
I have encountered a problem where KEDA ignores invisible messages (messages currently being processed) when evaluating the queue length for an Azure storage account queue. This gives a few outcomes:
A few issues have been raised in the past:
Scaled jobs have been suggested instead for long running tasks, but this doesn't necessarily solve the issues of:
Based on the discussion in Issue 2385, it would be good if a user has the option to select the peek method, or approximate method.
As noted on Issue 2385, when using Azure functions on an App Service Plan, you can scale based on storage queue length. The implementation Azure has used for this is approximate message count, and does not offer any other method of scaling based on queue length.
A screenshot from the app service plan scale rules GUI:
The text was updated successfully, but these errors were encountered: