proto: optimize global (un)marshal lock using RWMutex #655
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is also submitted to golang/protobuf#1004
This is a workaround to #656
Signed-off-by: TennyZhuang [email protected]
Thie PR Use
RWMutex
to optimizegetMarshalInfo
andgetUnmarshalInfo
, for these functions, only n (number of message type) will hit Write, and m(number of message) - n will hit Read, it's the best case to use RWMutex instead of Mutex.This optimization introduce huge improvement in our scenario.
We have 1000 worker and 1 controller, and work and controller keep heartbeat with gRPC. They also exchange the job info with each other.
The message is like
About 10000 jobs in every Heartbeat, and the heartbeat QPS in controller is about 1000.
The controller handle the Heartbeat in about 10ms, and the network latency is about 10ms, but the client will use about 30s in maximum to finish a RPC call.
We use golang pprof block profile, and it seems that almost all block is caused by one global Mutex in protobuf package.
After optimization, in our use case, the rpc call from client will only use about 30ms, as our expected.