Skip to content

Scaling

Andrew J. Gillis edited this page Jan 31, 2018 · 1 revision

Scaling Routers

Scale-up

A single nexus router process can manage multiple, independent realms. The nexus router uses all cores available on the host machine, and handles separate clients and their messages in a highly concurrent manner. There is no need to run separate routers on the same host to improve concurrency. This scalability is designed to allow a nexus router to make maximum use of a single machine.

Concurrency Details

Messages are processed in separate concurrent stages (receive, route, send). All clients send and receive concurrently with each other, and message routing is minimally serial - limited to determining which client's queue to put the message on and adding and removing clients. Broker routing is independent of (and concurrent with) Dealer routing within a realm. Separate realms have their own brokers and dealers making them completely independent of and concurrent with each other. See diagram.

Scale-out

Multiple routers, managing different realms, can be run on separate machines. The means that the overall communication strategy must divide the message traffic into separate realms. How the messages are partitioned is up to the implementor. This type of scaling would allow more resources (CPU and memory) to be dedicated to message routing that an single machine could provide.

A client application could connect to separate routers for handling different types of messages.

Scaling Application Components

Scale-up

Application components, using the nexus client library, can run multiple client instances, each an independent WAMP session, attached to the same realm, and/or attached to separate realms, served by the same or separate routers. Each of these client sessions operates completely independent of each other and they can all run concurrently with each other.

An application may run separate client sessions for the different WAMP roles it participates in (publisher, subscriber, caller, callee). The application may even use separate sessions for subscribing to different events, or for handling different RPC calls, if it does not care about the order these are handled in. Since message processing is independent between client sessions the activities for the separate separate sessions could be completely concurrent.

The allows a single application to scale up by creating as many separate concurrent client sessions as it needs. Each concurrent activity can use any CPU core, allowing concurrent applications to scale-up and maximize use of available cores.

Scale-out

Application components can also be spread across multiple machines, all connecting to the same router. This allows applications to scale-out and utilize the resources of multiple machines.

The Go advantage

Nexus is written in Go. Go was designed with concurrency and scalability in mind, and is able to run thousands of concurrent routines, across all available cores, within a single process. It is not necessary to run separate processes to take advantage of multiple cores. This allows a single router or single client application to be able to scale-up and fully utilize the machine is it running on.