You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi we're evaluating tiledb for persistence of some of our high frequency data.
We're using the c++ library (clang18, libc++, ubuntu22, low latency kernel etc), writing to local disk we're seeing latencies in the 8 - 16ms range per write query.
I'd expect it to be on a sub ms level given that the disks have an avg write latency at ~.4ms.
The tiledb runs on a dedicated core, with default setting except;
Can we get some attention to this issue, or some color to the lib design decisions affecting the performance if nothing else as this determines the path forward..
(a natural workaround that might work I presume if one is not to constrained, is to offset the fixed costs by batching up to a page size)
Hi we're evaluating tiledb for persistence of some of our high frequency data.
We're using the c++ library (clang18, libc++, ubuntu22, low latency kernel etc), writing to local disk we're seeing latencies in the 8 - 16ms range per write query.
I'd expect it to be on a sub ms level given that the disks have an avg write latency at ~.4ms.
The tiledb runs on a dedicated core, with default setting except;
(I still see tiledb creating 26 threads however, all idle but 4 with small cpu util)
the write query is created as;
the schema is created as;
Further there's a few hundred tiledb::Context(s) in flight catering to writes to different tiles.
Please advice on how to get the per query latencies down to acceptable levels (sub ms).
The text was updated successfully, but these errors were encountered: