WASM Connector Memory Issue

[bbollen23]

Hi there,

We have an application that we are using with a standard duckDb server. In other words, we were handling it like this:

const connector = vg.socketConnector(
                configStore.duckDbWebSocketUrl
            );

vg.coordinator().databaseConnector(connector);

This works fine, but we're having some performance issues when running our app on a server and accessing it remotely (just much slower than we wished).

We wanted to try out the wasm connector like this:

const connector = vg.wasmConnector();

vg.coordinator().databaseConnector(connector);

Unfortunately, we're running into this issue:

Error resolving promises: RuntimeError: memory access out of bounds

Is this just a limited memory issue? The dataset we're loading is a parquet file with 1,132,850 rows with 17 columns.

Thanks in advance!

[domoritz]

Webassmbly is limited to 2GB because of the 32 bit address model it uses. Check the memory usage of your tab and try a sample of the dataset. In the future, using OPFS or 64 bit memory (when it ships in browsers) would solve this issue.

I'm curious about the performance issues you see with the server. Is that stemming from latency over the network?

[bbollen23]

The main issue is definitely just latency. I'm located in CO and the server is in Utah (where most of the folks that are going to use this are, anyway), so I can see that its probably 2 to 3 times slower when deployed on the server rather than running my local version of the application (both using the non-wasm websocket connector).

The other performance issues are pretty involved. Our main issue is that when using Vue.js, we weren't able to figure out how to make a well-defined "client" (like a Vue component which dispatches actions to duckdb through mosaic). I'm not sure if this changes any of the performance, but what we ended up doing was essentially creating "watch variables" on our interactions.

For example, we have a slider that we have in a specific vue. As you slide, a set of selections and filters are updated. Once these are updated, we generate the appropriate predicates and call something like

const clause = {source: 'some_source_string', predicate: 'some_predicate'}
someSelection.update({ ...clause });

Where "someSelection" comes from const someSelection = vg.Selection.intersect()

I think the main thing is that we just have tons of cross filtering and cross updates. When you update just one slider, you're updating many different selections all at once. I'd be happy to go more into detail about our particular issues. Otherwise, the workflow and how it all ties together has worked really well for us. Smaller datasets work extremely well and quickly.

[domoritz]

Yeah, latencies to servers is something we are very well aware of. For now, try to keep the server close to your users. I really want to add some kind of hybrid execution to Mosaic where we offload big aggregations but keep the preaggregates in the client.

Regarding better integration with libraries like svelte, vue, and react, we will have some updates soon. Watch this issue.

We should definitely stay in touch about your use case. It could help us iron out performance edge cases.

[bbollen23]

That would be great! We have an application running right now at https://loonsw.sci.utah.edu if you'd like to check it out. It's a Cell Microscopy data visualization platform.

Here are the relevant papers: https://ieeexplore.ieee.org/document/10670500, https://ieeexplore.ieee.org/document/9552235

[domoritz]

Awesome, thanks for sharing! Just to note, exposing a server means allowing arbitrary SQL. Make sure you don't have anything critical on the server this is running on and that you can reset it easily since this machine is exposed to the Internet.

[bbollen23]

Thanks for the tip! I think we should be good. The DuckDB that is exposed is only for Mosaic. We have a MinIO storage bucket which actually hosts the data. On load, duckdb pulls in the relevant stuff into DuckDB from MinIO, so if somebody deleted that DuckDB database, it wouldn't matter at all. We have a separate MySQL instance which runs in conjunction with our backend which handles file references through MinIO