-
Notifications
You must be signed in to change notification settings - Fork 8
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
Less optimal performance in QueueStatisticsCollector #188
Comments
Related: - swisspost#583 Json serialization blocking EventLoop for too long - [QueueStatisticsCollector takes up to 10 minutes for ONE SINGLE request](swisspost/vertx-redisques#188) - [Performance Excuses Debunked](https://m.youtube.com/watch?v=x2EOOJg8FkA)
Related: - swisspost#590 - swisspost#583 - [QueueStatisticsCollector takes up to 10 minutes for ONE SINGLE request](swisspost/vertx-redisques#188) - [Performance Excuses Debunked](https://m.youtube.com/watch?v=x2EOOJg8FkA)
Related: - swisspost#590 - swisspost#583 - [QueueStatisticsCollector takes up to 10 minutes for ONE SINGLE request](swisspost/vertx-redisques#188) - [Performance Excuses Debunked](https://m.youtube.com/watch?v=x2EOOJg8FkA)
Analysing the different Redis commands used, it looks as if hvals is the one taking the most of the time on the system. And it is only executed once during one statistic retrieval. See SDCISA-16512 |
Turned out that there were very much keys within the corresponding hash table on Redis. Therefore, the delay observed here is quite logically and was caused by one single hvars call to Redis to retrieve the full Hashtable content. |
(relates to (internal): SDCISA-16512)
Another 5'925 examples are available in attached log.
I could imagine that this can lead to timeouts in some callers.
Update (2024-06-21):
Today I could observe some even more obscure ones. For whatever reason those took between 5 and 10 minutes to complete:
The text was updated successfully, but these errors were encountered: