Reduce stream message limit

Its possible that a worker is starved out of running during the initial
spin up of worker processes. When there's a high Q running its possible
that a few of the workers are prevented from sending messages back which
ends up causing significant latency as they wait for other workers to
fill up their 100 message buffer and get swapped out.

Once they start sending though the view streams fine. While we don't
understand why some workers behave like this a quick fix is to just
reduce the size of the buffer so that we're not introducing as large of
a delay in the time to first byte.
1 file changed
tree: aa76584f45cac37214efcc246d0fa20f7336b262
  1. include/
  2. src/
  3. README.md
  4. rebar
  5. rebar.config
README.md

Rexi is a tailor-made RPC server application for sending CouchDB operations to nodes in a cluster. It is used in BigCouch as the remote procedure vehicle to get fabric functions to execute on remote cluster nodes.

Rexi better fits the needs of the BigCouch distributed data store by dropping some unneeded overhead in rex, the RPC server that ships with Erlang/OTP. Rexi is optimized for the case when you need to spawn a bunch of remote processes. Cast messages are sent from the origin to the remote rexi server, and local processes are spawned from there, which is vastly more efficient than spawning remote processes from the origin. You still get monitoring of the remote processes, but the request-handling process doesn't get stuck trying to connect to an overloaded/dead node. ‘rexi_DOWN’ messages will arrive at the client eventually. This has been an extremely advantageous mix of latency and failure detection, vastly improving the performance of BigCouch.

Rexi is used in conjunction with ‘Fabric’ which is also an application within BigCouch, but can be used on a stand-alone basis.

Getting Started

Rexi requires R13B03 or higher and can be built with rebar, which comes bundled in the repository.

License

Apache 2.0

Contact