-
Notifications
You must be signed in to change notification settings - Fork 41
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
Upgrade to latest JetStream SDK #542
Comments
Still wondering whether this is the right approach... The request volume I'm seeing in my environment shouldn't have any impact on performance with respect to the number of goroutines |
This issue is stale because it has been open for 90 days with no |
/remove-lifecycle stale |
This issue is stale because it has been open for 90 days with no |
Problem
We're using a legacy SDK for interacting with NATS, I have been observing some performance issues in our environment, and although I'm not 100% certain the issue is in this repo, things got slightly better after restarting the dispatcher. I believe it's still to do with the number of goroutines we have running, and the new SDK makes it much easier to control how many messages we fetch in parallel.
I'm proposing this as a feature rather than a bug, because as I said, I'm not actually 100% certain there is a performance issue.
I already have some WIP changes which use the new SDK whilst fixing some other minor issues, any PR is probably going to come addressing multiple issues (sorry! but doing all the things I want to do in separate PRs is going to take too long and I'm pushed for time in this repo)
Persona:
Exit Criteria
Library is updated and performance is improved.
Time Estimate (optional):
1 day
Additional context (optional)
My WIP code makes changes so that we use the new
FetchNoWait(batchSize)
method, and convert thejetstream.Msg
to a new struct which implementsbinding.Message
(since the CE SDK doesn't support this library yet). This struct also contains aContext()
method which is configured with a timeout based onAckWait
so that we can successfully cancel requests as soon as they expire.We then write this
Message
implementation to a local channel which we handle in a fixed number of goroutines, rather than spawning a new goroutine for every message.I think this will make things much easier to tweak for performance issues, and should be more performant out of the box.
The text was updated successfully, but these errors were encountered: