Replies: 2 comments 9 replies
-
The system should only fire the timer based on when it thinks the next message will expire. We could soften that a bit and round up to say seconds, but would probably not go beyond that since had memory repercussions. If we decide to go forward with a second minimum timer value I would be ok with that. |
Beta Was this translation helpful? Give feedback.
8 replies
-
Thank you ... that was quick 🚀 |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I just noticed within my testsetup that memstores expireMsgs is called basically all around the clock stopping the store with the lock, deleting 2-3 msgs and then starting all over again in a few micro secs...
This has a performance hit and I would like to discuss if this aggressiveness is really needed.
My use case: I have a quite steady rate of msgs and I have set the max age to something like 30 mins.
On my stream I have ~100 subjects where there is a lot of traffic on some, but almost none on others. I also have set a per subj msg limit. I cannot tell beforehand which subjects will be the ones with high and with low traffic in the real world as this is depending on user behaviour at the end of the day.
This setup causes the deleted count to go up as discussed in another question.
Goal was to find a sweet spot with config between maxage, maxbytes and maxmsgs per subject to reduce those delete messages.
MaxAge was added now to get rid of such msgs stuck in subjects with almost no new messages sent.
My expectation based on the docu was: If I set this to something like 30 mins, then this limit is evaluated like once every few mins or so. I was not aware that these 30mins are taken literally as exact as a nanosec level.
Ideas / Proposals:
Not sure though if running it at a lesser pace effectively deleting more messages in one go has other performance implications?
Beta Was this translation helpful? Give feedback.
All reactions