RTO: How to know the network bandwidth from an EMA app running env to an ADS server?
[Performance Debugging and Tuning]
How to know the network bandwidth from an EMA app running env to an ADS server?
Any tools may facilitate this purpose? to identify if the 'slow consumer' issue is due to the network bandwidth.
Take this as example, the EMA application is directly (without LPC or RTC/ADSPOP) connecting to ap-southeast RTO (in the region RTO endpoint) and experiencing the 'channel down' issue possibly due to the 'slow consumer' issue.
There will be ongoing debugging with the tools like 'testclient' of which the logs will be compared with the logs of that EMA application.
However, if any tool may facilitate the checking on the network bandwidth? (not just watching the inbound and outbound throughput of that server running EMA application, need to know the maximum bandwidth it may reach to that endpoint/ADS server in AWS)
Best Answer
-
Users can use package analysis tools, such as tcpdump or Wireshark to verify the network bandwidth or the TCP receive window size of consuming applications.
For example, if the application is a slow consumer, the size of the TCP receive window will drop nearly or equal to zero. The below line graph represents the size of TCP received changed over time. There are some periods that the TCP receive window size drops to zero. This indicates that the application could be a slow consumer.
Otherwise, if the clients have a list of subscribed items, they can use that list with the testclient to measure the update rate per second of the subscribed items. Then, they need to measure the number of updates that the application can handle per second.
If the number of updates that the application can handle per second is too small compared to the number of updates per second reported by testclient, there is a chance that the connection of the application can be cut due to the slow consumer problem.
0
Answers
-
The background:
1. to identify the current bottleneck, which makes the 'slow consumer' problem (since even use an empty UpdateMsg handle implementation, still met the 'channel down' problem due to stale UpdateMessage over 120s in the server cache)2. How many RIC updates per second that EMA application and runtime environment may handle at maximum? So for a single RTO machine id, maybe that EMA application instance only may subscribe that number of RIC of that exchange at maximum.
0 -
0
-
testclient is written on top of ETA.0
Categories
- All Categories
- 3 Polls
- 6 AHS
- 37 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 698 Datastream
- 1.5K DSS
- 633 Eikon COM
- 5.2K Eikon Data APIs
- 14 Electronic Trading
- 1 Generic FIX
- 7 Local Bank Node API
- 6 Trading API
- 2.9K Elektron
- 1.5K EMA
- 257 ETA
- 565 WebSocket API
- 40 FX Venues
- 16 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 25 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 283 Open PermID
- 47 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 24 RDMS
- 2.1K Refinitiv Data Platform
- 800 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 27 DACS Station
- 122 Open DACS
- 1.1K RFA
- 107 UPA
- 194 TREP Infrastructure
- 232 TRKD
- 918 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 101 Workspace SDK
- 11 Element Framework
- 5 Grid
- 19 World-Check Data File
- 1 Yield Book Analytics
- 48 中文论坛