Our websocket RPC requests are currently handled by a pool of background threads, which means that our performance can be limited by the GIL. Some of our stress testing on an earlier project did show that we got over a 3x improvement on throughput on a 4-processor machine by changing over to a pool of processes.
We probably don't want this to be the default, because plugins might rely on shared, global state. For example, our sideboard.lib.Subscription class is specifically designed around the idea of having a single global variable which is the current value of the latest subscription response. This would need to be changed to use shared memory or something if we wanted that to work in a multiprocessing environment (which wouldn't be hard), and we'd need to put a lot more thought into what else would be affected.
Even if not the default, we could potentially implement a config option that would tell Sideboard that we want the higher-performance option.
A more radical suggestion would be to make it possible for a single plugin to run its functions across multiple machines for performance improvements, like with the pp module. Maybe if you decorate your service methods to indicate that it's safe to call them that way, or something.
Since we don't currently have a specific plugin that needs this, it's definitely a low priority.
Our websocket RPC requests are currently handled by a pool of background threads, which means that our performance can be limited by the GIL. Some of our stress testing on an earlier project did show that we got over a 3x improvement on throughput on a 4-processor machine by changing over to a pool of processes.
We probably don't want this to be the default, because plugins might rely on shared, global state. For example, our sideboard.lib.Subscription class is specifically designed around the idea of having a single global variable which is the current value of the latest subscription response. This would need to be changed to use shared memory or something if we wanted that to work in a multiprocessing environment (which wouldn't be hard), and we'd need to put a lot more thought into what else would be affected.
Even if not the default, we could potentially implement a config option that would tell Sideboard that we want the higher-performance option.
A more radical suggestion would be to make it possible for a single plugin to run its functions across multiple machines for performance improvements, like with the pp module. Maybe if you decorate your service methods to indicate that it's safe to call them that way, or something.
Since we don't currently have a specific plugin that needs this, it's definitely a low priority.