CODEWITHSUNDEEP
kdb+
BlackPearl
BlackPearl

Reputation: 115

how can we monitor latency between process in kdb?

What is the best way/tool to calculate the latency in my current kdb setup?

This is how data is flowing : linehandler LH pub -> TP -> RDB

So the latency table will look like this

tableName | Total Latency (RDB-LH)| (TP-LH)| (RDB-TP)
tab1      |00:00:20               |00:00:10|00:00:10
tab2      |00:00:50               |00:00:10|00:00:40

We are getting updates from LH to TP in both ways (periodically and irregular updates) Not sure what is the best to capture latency here between the process.

Any tool which already captures it or do I need to set it up from scratch?

Note: We cannot have new column introduced bec then all prod setup and downstream subs system will break bec of new cols.

Upvotes: 0

Views: 191

Answers (1)

Matt Moore
Matt Moore

Reputation: 2800

It sounds like you have everything you need to monitor it with the time columns you have available.

If you are using ITRS/Geneos you can have scripts to query rdb to check the latency between those time columns or have it periodically output to a log an monitor it's output. Although any monitoring system could be subbed in here if it supports bash scripting and/or log tailing.

However, looking at rdb latency may not be very useful. User queries which take 30 seconds or more would cause the next few tp updates to lag behind if comparing to tp time. If you think the rdb is underperforming you should just test the upd functionality in a UAT environment under high load to verify it performs ok.

The other thing to be wary of is if -t is set on tp for batching. Although typically this can be 1/5 second, you should check what value it has and account for it in latency statistics.

Usage logging on the rdb may also be useful as if you are seeing significant gaps between tp -> rdb you should review what users are doing on the process. Although this defeats the purpose of having an rdb if users can't query it which is the likely cause of latency.

The other option is to measure latency outside of the rdb in a dedicated process such as TorQ's monitoring/data quality engine processes which are out of the box and help keep your rdb leaner: https://www.aquaq.co.uk/torq-data-quality-system/

*Disclaimer I work for AquaQ

Upvotes: 2

Related Questions