IAB Usage & Performance

IAB Usage & Performance

Overview

OpenFin’s InterApplication Bus (IAB) is a feature-first mechanism that drives app-to-app communication to streamline an end user’s experience. In this topic, we discuss common practices for OpenFin’s IAB and highlight key decision points on where and when IAB usage makes practical sense. Additionally, we share some benchmarks on performance and include a tool to assist in velocity and throughput expectations. 

OpenFin’s IAB throughput can reach up to 40 MB/s (for large messages), or 200 messages/s (for small messages) enabling Application Providers the flexibility of message size and frequency between OpenFin applications.  

Common Use Cases

1. Topic based messaging (Pub/Sub) 
   1. Publish / Subscribe to topics of interest (i.e., equity tickers, contract identifiers, etc...)
   2. Use Case 
2. Direct connections between applications
   1. Send a direct message to another application
   2. Use Case
3. One-to-many connections (Channel API)
   1. The OpenFin Channels API permits communication between OpenFin applications via an asynchronous request-response messaging channel. Channels permit communication between applications while providing asynchronous methods for discovery, transfer of data, and lifecycle management.

Large data sets | Best Practices Best practices for large data sets, how do it

OpenFin’s IAB is well-suited for sharing bi-directional context and data between two renderer processes on the same desktop. Use of OpenFin’s IAB for messaging or market data provider services has its inherent side effects. These data sets are generally one-way communication and do not provide a means for the receiving application to respond to the data being sent. Couple app-to-app messages with large data volume services on the IAB, will result in queued messaging which may impact the end-user experience.

Large data set Approaches

While ample memory is available in the Multi-Process chromium architecture, it is important to recognize that a single window is limited by an upper bound of memory. How do we maximize the efficiency of memory that is given to us? A fundamentally sound approach, a bit of creativity, and a checklist of tasks that ensure we are using the right “tool for the trade”. Listed below are a couple aforementioned tools that are often used to deal with the evergreen problem, that is, maximizing the efficiency of a set of data that may be sent / received at a very high rate and or sent / received as a very large size. 

1. Websockets (over TLS)
   1. <Link to how to use websockets correctly>
2. Server Sent Events (SSE)
   1. <Link to how to use websockets correctly>

IAB Performance

OpenFin’s IAB is designed to send small messages at rates of 200 messages per second at only a fraction of the data throughput. In cases where messages are sent for market or app events and the data size is small, then these messages can be sent faster than the UI can render them – a very good thing. In contrast, larger messages or high volume set messages over the IAB can result in a laggy or choppy end user experience.

OpenFin’s messaging capabilities are top-notch for application web-content, which often has to go over the network to a backend server.

Benchmarks

Like any benchmark or stress test, the actual capabilities will depend heavily on system hardware specifications, current CPU utilization, and the number of other OpenFin applications running on the same box.

<DATA>

Smaller messages = faster speed, however, not as efficient

Larger messages = slower speed, however, more efficient

How OpenFin’s IAB differs from a messaging or market data provider

OpenFin’s IAB is not the same as a messaging or market data provider service. While  messaging or market data providers send lots of messages to client applications, this information is usually one-way and does not provide a means for the receiving application to respond to the data being sent. 

In contrast, OpenFin’s IAB is for sharing context and data between two processes on the same box in both directions. As small amounts of data is passed between two applications, the need to pass large amounts of data between the two applications is greatly diminished.