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.

Sign up for GitHub

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

Jump to bottom

Requests are too protocol chatty, should be optimized. #294

Closed
derekcollison opened this issue May 23, 2017 · 1 comment
Closed

Requests are too protocol chatty, should be optimized. #294

derekcollison opened this issue May 23, 2017 · 1 comment

Comments

@derekcollison
Copy link
Member

derekcollison commented May 23, 2017 •
edited

Every request forms a new INBOX subscription for each request and then tears them down. Since NATS has to flood the interest graph to clusters and possible future bridged clusters, this should be redesigned to reuse a single subscription but still be semantically be the same from a client perspective. One word of caution is that we use the circuit breaker pattern such that the server auto-unsubscribes after N responses (usually 1), so if you are requesting from a large set of normal subscribers, the client may be getting a higher number of responses that will be ignored. However I feel the normal case should be a request is always sent to a queue group, which does not need the circuit breaker assist.

Example trace from a single request / response today.

[TRC] ::1:50431 - cid:2 - ->> [SUB _INBOX.Gmw3KasVkAqYFpskoKCV79 1]
[TRC] ::1:50431 - cid:2 - ->> [UNSUB 1 1]
[TRC] ::1:50431 - cid:2 - ->> [PUB foo _INBOX.Gmw3KasVkAqYFpskoKCV79 4]
[TRC] ::1:50431 - cid:2 - ->> MSG_PAYLOAD: [help]
[TRC] ::1:50426 - cid:1 - <<- [MSG foo 1 _INBOX.Gmw3KasVkAqYFpskoKCV79 4]
[TRC] ::1:50426 - cid:1 - ->> [PUB _INBOX.Gmw3KasVkAqYFpskoKCV79 5]
[TRC] ::1:50426 - cid:1 - ->> MSG_PAYLOAD: [hello]
[TRC] ::1:50431 - cid:2 - <<- [MSG _INBOX.Gmw3KasVkAqYFpskoKCV79 1 5]
[TRC] ::1:50431 - cid:2 - <-> [DELSUB 1]
derekcollison added a commit that referenced this issue May 25, 2017
@derekcollison
More protocol friendly request pattern. Fix for #294.
2231281 
This request pattern is sematically the same but utilizes a single
wildcard subscription and the last token context for the response
subject binding to each request. Since NATS floods interest (subscriptions),
the old requestor pattern would create a new inbox subscription for each request.
It would then auto-unsubscribe and delete the subscription after the
response was received, causing quite a bit of protocol traffic.

So although this does have a performance gain as can be seen in the benchmarks,
it's implementation is specifically designed to be more friendly for NATS
clusters.
derekcollison added a commit that referenced this issue May 27, 2017
@derekcollison
Merge pull request #295 from nats-io/new_request
9147cfa 
More protocol friendly request pattern. Fix for #294.
@kozlovic kozlovic mentioned this issue May 30, 2017
Closed
@kozlovic
Copy link
Member

Resolved with #295

@petemiron petemiron mentioned this issue Jun 5, 2017
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@derekcollison @kozlovic