taigrr/nats.docs
1
0
Fork 0
mirror of https://github.com/taigrr/nats.docs synced 2025-01-18 04:03:23 -08:00
Code Issues Projects Releases Wiki Activity

Update slow_consumers.md

Browse Source
This commit is contained in:
Ginger Collison 2019-05-30 12:52:58 -05:00 committed by GitHub
parent 7765f4b86a
commit 2dcb7fc687
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
nats_admin/slow_consumers.md
View File

@ -64,11 +64,11 @@ The server will also keep count of the number of slow consumer errors encountere
## Handling slow consumers
Apart from using [NATS streaming](nats_streaming/intro.md/) or optimizing your consuming application, there are a few options available: scale, meter, or tune NATS to your environment.
Apart from using [NATS streaming](/nats_streaming/intro.md/) or optimizing your consuming application, there are a few options available: scale, meter, or tune NATS to your environment.
__Scaling with queue subscribers__
This is ideal if you do not rely on message order. Ensure your NATS subscription belongs to a [queue group](http://nats.io/documentation/concepts/nats-queueing/), then scale as required by creating more instances of your service or application. This is a great approach for microservices - each instance of your microservice will receive a portion of the messages to process, and simply add more instances of your service to scale. No code changes, configuration changes, or downtime whatsoever.
This is ideal if you do not rely on message order. Ensure your NATS subscription belongs to a [queue group](/developer/concepts/queue.md/), then scale as required by creating more instances of your service or application. This is a great approach for microservices - each instance of your microservice will receive a portion of the messages to process, and simply add more instances of your service to scale. No code changes, configuration changes, or downtime whatsoever.
__Create a subject namespace that can scale__
@ -110,4 +110,4 @@ if err := sub.SetPendingLimits(1024*500, 1024*5000); err != nil {
The default subscriber pending message limit is `65536`, and the default subscriber pending byte limit is `65536*1024`
If the client reaches this internal limit, it will drop messages and continue to process new messages. This is aligned with NATS at most once delivery. It is up to your application to detect the missing messages and recover from this condition.
If the client reaches this internal limit, it will drop messages and continue to process new messages. This is aligned with NATS at most once delivery. It is up to your application to detect the missing messages and recover from this condition.