You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by "lhotari (via GitHub)" <gi...@apache.org> on 2024/10/23 04:41:55 UTC
[I] [Enhancement] Make cursor caching eligibility logic reactive since reads don't get cached until checkCursorsToCacheEntries has been called [pulsar]
lhotari opened a new issue, #23503:
URL: https://github.com/apache/pulsar/issues/23503
### Search before asking
- [X] I searched in the [issues](https://github.com/apache/pulsar/issues) and found nothing similar.
### Motivation
Currently broker cache doesn't cache entries until `checkCursorsToCacheEntries` has been called. It get called as part of PulsarStats.updateStats which gets called every `statsUpdateFrequencyInSecs` (60s by default).
This could be a problem when a topic gets assigned to a broker and a large number of consumer connect in a large fanout scenario. The read request deduplication solution (PendingReadsManager added in #17241) will handle the problem for consumers at the same point of consumption, but caching would be useful for consumers that are not consuming exactly at the same location.
### Solution
Improve the cursor caching eligibility logic to be reactive instead of calculated every 60s.
### Alternatives
_No response_
### Anything else?
discussion thread about broker cache design: https://lists.apache.org/thread/xm095hnjo0cffbdy8ckysmzzm90gsbnp
broker cache default tuning: #23466
### Are you willing to submit a PR?
- [ ] I'm willing to submit a PR!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] Make cursor caching eligibility logic reactive since reads don't get cached until checkCursorsToCacheEntries has been called [pulsar]
Posted by "lhotari (via GitHub)" <gi...@apache.org>.
lhotari commented on issue #23503:
URL: https://github.com/apache/pulsar/issues/23503#issuecomment-2997624227
"PIP-430: Pulsar Broker cache improvements: refactoring eviction and adding a new cache strategy based on expected read count", #24444 covers this
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] Make cursor caching eligibility logic reactive since reads don't get cached until checkCursorsToCacheEntries has been called [pulsar]
Posted by "merlimat (via GitHub)" <gi...@apache.org>.
merlimat commented on issue #23503:
URL: https://github.com/apache/pulsar/issues/23503#issuecomment-6388744174
This was addressed by PIP-430 (https://github.com/apache/pulsar/blob/master/pip/pip-430.md, implemented in #24623, released in 4.1.0). With the default `cacheEvictionByExpectedReadCount=true`, caching depends on the expected read count of the active cursors at add/read time, not on the 60-second `checkCursorsToCacheEntries` pass, which now returns early in that mode. Closing as completed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] Make cursor caching eligibility logic reactive since reads don't get cached until checkCursorsToCacheEntries has been called [pulsar]
Posted by "merlimat (via GitHub)" <gi...@apache.org>.
merlimat closed issue #23503: [Enhancement] Make cursor caching eligibility logic reactive since reads don't get cached until checkCursorsToCacheEntries has been called
URL: https://github.com/apache/pulsar/issues/23503
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] Make cursor caching eligibility logic reactive since reads don't get cached until checkCursorsToCacheEntries has been called [pulsar]
Posted by "berg223 (via GitHub)" <gi...@apache.org>.
berg223 commented on issue #23503:
URL: https://github.com/apache/pulsar/issues/23503#issuecomment-2933685462
I have a preview on https://github.com/lhotari/pulsar/pull/209 . I have simplely splitted the improvement into two parts:
1. Strategy about when to insert entry into cache. We will insert entry into cache when expectedReadCountVal > 0
2. Strategy about when to remove entry from cache. We will remove entry from cache when the cache is full and expectedReadCountVal < 1 or expired.
This is an awesome improvement. The strategy about insert is reactive, however it maybe too simple compared with `checkCursorsToCacheEntries`. Maybe we should consider compatibility about the insert strategy. We can make the origin insert strategy reactive by update `cacheReadEntry` filed of ManagedCursorImpl every time cursor updates position or accumulative update.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Enhancement] Make cursor caching eligibility logic reactive since reads don't get cached until checkCursorsToCacheEntries has been called [pulsar]
Posted by "lhotari (via GitHub)" <gi...@apache.org>.
lhotari commented on issue #23503:
URL: https://github.com/apache/pulsar/issues/23503#issuecomment-2923027729
A revisited broker entry cache solution is in progress in lhotari/pulsar#209
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org