Skip to content
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

Reduce number of transmitted ObjectService.Search response messages #2723

Open
cthulhu-rider opened this issue Jan 17, 2024 · 1 comment
Open
Labels
enhancement Improving existing functionality I4 No visible changes S3 Minimally significant U4 Nothing urgent

Comments

@cthulhu-rider
Copy link
Contributor

Is your feature request related to a problem? Please describe.

object SEARCH operations are executed additively on all container nodes. Currently, server writes one response message to the stream per response from each individual node. When each node stores a few objects, this leads to a decrease in performance due to the overhead of additional messages when transmitting a fixed payload (list of object IDs for SEARCH)

Describe the solution you'd like

buffer the results up to the limit volume, and then flush them into the stream. Seems like this component is a good place to do

func (s *searchStreamMsgSizeCtrl) Send(resp *object.SearchResponse) error {
body := resp.GetBody()
ids := body.GetIDList()
var newResp *object.SearchResponse
for ln := uint64(len(ids)); ; {
if newResp == nil {
newResp = new(object.SearchResponse)
newResp.SetBody(body)
}
cut := s.addrAmount
if cut > ln {
cut = ln
}
body.SetIDList(ids[:cut])
newResp.SetMetaHeader(resp.GetMetaHeader())
newResp.SetVerificationHeader(resp.GetVerificationHeader())
if err := s.stream.Send(newResp); err != nil {
return err
}
ids = ids[cut:]
if len(ids) == 0 {
break
}
}
return nil
}

Describe alternatives you've considered

leave as it is. One of the possible benefits of the current approach with client POV is faster receipt of primary results from faster nodes. However, if the client understands the internal structure of the cluster so deeply and wants to more flexibly control operations on it, then either:

  • it can manage cluster nodes itself - for this all information is available (netmap, containers)
  • the protocol can be extended with a buffering bypass service flag upon special feature request (not yet)

Additional context

currently it's hard to detect specifics of such internal container queries. I've noticed current case during deep debug within #2722

@cthulhu-rider cthulhu-rider added the enhancement Improving existing functionality label Jan 17, 2024
@roman-khimov roman-khimov added U4 Nothing urgent S3 Minimally significant I4 No visible changes labels Jan 17, 2024
@roman-khimov
Copy link
Member

This requires both size and time constraints to balance latencies/bandwidth.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improving existing functionality I4 No visible changes S3 Minimally significant U4 Nothing urgent
Projects
None yet
Development

No branches or pull requests

2 participants