Best Practices

The following guidelines offer some practical advice for developers working with NeuroScale in a production environment.

While you can subscribe to all topics/output nodes that a pipeline provides, this means that you will receive an unnecessarily large number of messages that you have to discard, which costs performance and bandwidth, and can also increase latency. To avoid this, subscribe to the default subtopic and/or specific topics of interest whenever possible.

Use MessagePack encoding whenever possible¶

While you can use JSON to encode your messages, this format is only really useful for inspecting the data that is being sent up and down. For production use, prefer MessagePack because this format uses less network bandwidth, which also gives you more consistent network performance, and is also faster to encode/decode both on the client and server side.

Reuse your instances, especially when testing/debugging¶

While you can destroy and re-create instances easily, we strongly recommend to instead recycle your instances between uses, especially when testing/debugging. This is done by either reconfiguring an existing instance (i.e. by sending a HTTP PATCH request with one or more updated attributes) or forcibly resetting an existing instance. This not only dramatically shortens the launch time, but it also reduces churn on the cloud backend. We may impose limits on excessive/rapid instance creation and destruction by user accounts.

Destroy your instances after use¶

Instances will keep running after your program terminates unless you explicitly destroy them. Since instances cost cloud resources (and therefore money), it is in your best interest to ensure that your program cleanly shuts itself down even in the face of exceptions, and destroys its cloud resources after use (but also see "Reuse your instances" above). To avoid accidental resource leakage, instances will by default self-terminate after sitting idle for a certain number of hours (the idle timeout, known as time_to_live, can be overridden when creating a new instance).

Do not send more than \~20 data chunks per second for most use cases¶

All pipelines on NeuroScale will pick up messages (that is, data chunks) up to a certain rate. If you exceed this rate, i.e., send too many (e.g., small) chunks per second, a pipeline will start to lag behind and messages will buffer up. Eventually this will lead you to get disconnected. Instead, send larger chunks with more samples in them to avoid this issue. Note however, that some pipelines that are made for particularly latency-sensitive use cases will support a higher message rate. Such exceptions will be noted in the pipeline description.

Minimizing latency¶

If you have a latency-sensitive application or if you encounter sporadic hitches in the data stream you receive, you will want to take some measures to minimize transmission latency. For this we suggest that you use the MessagePack encoding instead of JSON (which uses less bandwidth), and to use the lowest sampling rate and number of channels that you can use without sacrificing performance. Also, make sure that you have a reasonably good internet connection available with sufficient upload and download speed.