nspcc-dev / nspcc-dev/neofs-node
Try small payload chunks in GET
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 38
- Forks
- 51
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 38
Description
Is your feature request related to a problem? Please describe.
I'm always frustrated when a single GRPC message spans multiple HTTP/2 frames. These frames need to be queued before returning them to GRPC stream handler. With 254KB of data per message that's 16 frames.
Describe the solution you'd like
We still want to read ~256KB from disk, but we can try sending this data in smaller messages. Each message needs to be ~15KB to perfectly fit into the default HTTP/2 frame. Then we can check how this affects local reads and forwarding.
Likely this will require some buffer dances with grpc prefixes stored in a different slice from payload (currently a single one is used).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the GET path and its gRPC stream handler, then trace how the current 256KB reads and frame-sized payloads are queued. Measure smaller messages for local reads and forwarding, and compare the results with the current behavior. Done means the tradeoffs are evaluated and the required buffering changes are clearly established.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, grpc
- Domain
- backend-api-design, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100