Flux response limiting is bottleneck in dashboards

[chnn]

We have a utility that executes a Flux query and returns the results. It has been through several iterations:

1. It was first introduced as a simple wrapper around Axios + the query endpoint
2. We realized that we needed the ability to limit the size of Flux responses, and so we rewrote the utility using fetch and the Streams API
3. We realized that the Streams API was behind a feature flag in Firefox, and thus the utility wasn't working in Firefox. We rewrote it using XMLHttpRequest
4. We extracted this code to influxdb-client-js, wrapping the XMLHttpRequest limiting logic in a Node.js Stream

It turns out that the stream wrapper is an extremely costly abstraction, at least it its current incarnation.

I created a dashboard with 9 cells, each containing a single series with about 42k points.

I refreshed all cells on this dashboard and recorded a performance profile. The influxd instance was on my laptop and no additional network latency was introduced.

52% of the total time was spent piping data through the stream wrapper. It took ~4x longer to pipe data through the stream wrapper than it did to parse it.

I ran another test, replacing the stream wrapper limiting logic with our previous fetch / Streams API approach. Profiling the same interaction showed that the time spent reading the Flux responses was entirely negligable (0.3% of total time):

Since the Streams API was de-feature flagged in Firefox 65, this is now a viable option for removing this dashboards bottleneck. Note that it has slightly different behavior: the node stream approach limits responses to a maximum number of rows, while the fetch approach limits responses to a maximum number of bytes.

Some other possible approaches:

• Remove the stream wrapper in the client in favor of just exposing a promise
• Replace the stream with something more efficient
• Tweak the stream wrapper so that it doesn't output each line individual, but outputs chunks of lines (maybe once per Flux result?)

The need to fix this bottleneck begs the question: should the Node stream wrapper be in the client at all, given its performance issues?