I am making an app based on the Sync Gateway and what I am seeing is that the Sync Gateway notifies Websocket listeners with the 2-second timer. That becomes apparent when you look at the times the Sync Gateway receives notification from Couchbase Server’s Tap Feed:
As you can see, the number of milliseconds is always the same and second is always an odd number, so I gather there is a timer somewhere in the Couchbase Server that’s set to two seconds.
What I’m wondering is how to dial it down to, say, 500ms so that Sync Gateway gets its notifications faster, because it’s really critical for me. Can you help me?
I understand that there may be other implications about lowering the timer and am willing to accept the risk.
I don’t know of anything off the top of my head that would set a 2-second notification timer, but I’d like to take a closer look. Can you provide some more details on which notification messages you’re seeing in the SG log associated with the timestamps you’ve listed above?
Then try to send one new document to sync gateway and look at the logs, you’ll find that there’s considerable delay between sending the document to the server and getting it back. Then try this a couple times more to see that the server answers at the exact same millisecond number.
I’ve used Couchbase Server v3.0.2 enterprise to reproduce this.
Reviewed this with the TAP feed owners, and there’s no timed buffering happening on the Couchbase Server side - requests are sent to the feed immediately. Based on some other testing, this may have something to do with the way sync gateway is doing writes. If I run the same test with Sync Gateway listening to the Tap Feed, but another client doing the writes to the server, I don’t see the same 2-second groupings - the tap events show up as they are written.
Filed issue #616 against Sync Gateway for this issue