-
Notifications
You must be signed in to change notification settings - Fork 336
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
[Partition Consumer] Provide lock-free access to compression providers #689
[Partition Consumer] Provide lock-free access to compression providers #689
Conversation
9bf63d9
to
96bf631
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM +1
pulsar/consumer_partition.go
Outdated
pc.providersMutex.RLock() | ||
provider, ok := pc.compressionProviders[msgMeta.GetCompression()] | ||
pc.providersMutex.RUnlock() | ||
v, ok := pc.compressionProviders.Load(msgMeta.GetCompression()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can replace v
with meaningful variable names
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wolfstudy , I've renamed the variables in this method for additional clarity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, nice work
The compression providers map in the partition consumer is a textbook case for using go's lock-free sync.Map: the set of map entries is stable and access is read-only. On machines with 4 cores or greater, read contention on the sync.RWMutex outweighs the cost of using a sync.Map. Below is an old article on the subject, but it still holds true today: https://medium.com/@deckarep/the-new-kid-in-town-gos-sync-map-de24a6bf7c2c Signed-off-by: Daniel Ferstay <dferstay@splunk.com>
0a8e77c
to
ac0a159
Compare
Motivation
The compression providers map in the partition consumer is a textbook case
for using go's lock-free sync.Map: the set of map entries is stable and
access is read-only.
On machines with 4 cores or greater, read contention on the sync.RWMutex
outweighs the cost of using a sync.Map.
Below is an old article on the subject, but it still holds true today:
https://medium.com/@deckarep/the-new-kid-in-town-gos-sync-map-de24a6bf7c2c
Modifications
The sync.RWMutex and map of compression providers (
map[pb.CompressionType]compression.Provider
) in the partition consumer has been replaced with a sync.MapVerifying this change
This change is already covered by existing tests, such as:
pulsar/consumer_partitiion_test.go
Does this pull request potentially affect one of the following parts:
Documentation