0

We have an application with multiple threads which reuses one KDB connection. From performance perspective, will it be good to open multiple connection to multithreaded KDB instance to speed up the process? Just also interesting is there any potential downside effect if we publish from multiple threads to a single connection: we have java app and use exxeleron java library.

Donald_W
  • 1,773
  • 21
  • 35
user3914448
  • 469
  • 1
  • 11
  • 22
  • Answer is not straight forward as it is more application specific. Depends on how much processing is done by your KDB server on every update,latency limit, published data size, ordering requirements and more. More details would help. – Rahul Jan 29 '15 at 06:11

1 Answers1

1

Aside from the fact that a single socket connection to KDB isn't very resource hungry by itself, in the end I think you'll find that disk seeks and memory allocation are by far the largest bottlenecks, not how many connections you have to a database. That said, since you ask...

Let's go on simple assumptions:

  1. The KDB database is a historical database. Multithread options on that side are negative port number and -s - which can't be set simultaneously
  2. You have a single process, let's call it A, that accesses it

With a negative port number, you get multi-threaded input queue. So if A has the ability to do multiple queries they can be dispatched simultaneously and KDB+ won't block on each call. However A would somehow need to be able to identify the incoming stream of results as the responses to particular queries. You can query it like (<queryId>;<actualQuery>) and parse the the first element for identification I suppose. However in this use case it sounds like you should have multiple A's.

With -s you get multi-threaded queries so you q queries have to written as such (sometimes you get it for free though, like querying across partitions). You'll block on every call, so no real advantage in having multiple A's.

Manish Patel
  • 4,411
  • 4
  • 25
  • 48