Speedus leverages modern hardware and OS capabilities to achieve extreme low latency and high throughput communications. Many application deployments can benefit from Speedus to debottleneck their networking stack, but there are some cases in which Speedus may not be suitable for your use case.
Best fit scenarios<
As a rule of thumb, any use case in which two or more applications running in the same host spend significant time in data transfers between them, will be a good candidate to be accelerated by Speedus.
Software stack running in a host on-premises or in a large cloud VM<
- Optimizes apps data transfers specially in non-virtualized environments, in which throughput performance is key.
- Allow legacy apps to leverage state-of-the-art hardware and OS communications improvements with no code changes involved.
Containerized microservices sharing a Docker engine<
- Avoid the network bottleneck toll that microservice designs usually have to pay, since decoupling services in smaller apps will increase the pressure in communications.
- Accelerates communications between containerized and non-containerized services
Low-latency messaging Deployments<
- Achieve sub-microsecond latencies for intrahost communications, which is key for specialized applications with low-latency requirements such as trading software.
- Compatible with third-party high-speed NIC solutions such as Solaflare, InfiniBand or RoCE-based.
Moderate fit scenarios<
Communications over LAN<
Speedus bypasses communications when both endpoints reside in the same host, so LAN communications will still be using the standard TCP/IP protocols. Despite this, Speedus also replaces polling interfaces (e.g. poll(2), select(2), epoll(7)) with customized ones, so it can improve overall response times if your application uses these interfaces.
Unsuited / anti-pattern scenarios<
In order to be fault tolerant and 100% compatible with TCP/IP apps, Speedus maintains two connections per endpoint: the original TCP/IP connection and the Speedus protocol connection. Thus, the trade-off is that establishing connections with Speedus may be slighty costly compared with simply using the standard socket connections. This means that applications which create a lot of connections and after a few data transfers destroys them won't be the best use case for Speedus. This is specially true with web servers with short-lived TCP connections, although you can avoid this issue by leveraging keep-alive strategies.
Heavy CPU consuming applications with scarce communications<
Another use case in which Speedus can be a liability is with heavy CPU consuming applications with scarce data transfers. The trade-off here is that, in order to provide the best latency and throughput, Speedus consumes more CPU time than the standard I/O, so your application may see that its CPU processing time has been reduced and, therefore, the overall performance may decrease.