This is the "Knowledge Doc" version of Joerg Mertin's Blog -- https://communities.ca.com/community/ca-apm/blog/2017/03/24/how-does-a-tim-worker-get-its-traffic
I want to know how does a TIM worker get its traffic?
All APM releases
On all TIM's 9.7+, the captured network communication flow is handled by apmpacket (on the High performance TIM) or nqcapd (on the MTP). Its function is very simple. It will get data from a network device or capture-card, and distribute the network communications based on a load-balancing algorithm defined by the client or server IP address, to the available TIM Workers.
The main differences between apmpacket and nqcapd are as follows:
1. Filter configuration for Napatech board needs to be written manually in a text file, and will be uploaded during start through the ntpcap.ini file.
2. Any change done to the ntpcap.ini (Napatech card configuration) will require a restart of apmpacket! As long as any program is accessing the data-feed, the Napatech board cannot load the new configuration.
When talking about "network communication", the TIM requires the communication flow that happens between a user's Web browser, and the responses sent back by the Web Server in its entirety. Any missing packet can invalidate the entire Monitoring of that communication, or cause a defect to show up. If that missing packet has been lost inside the SPAN infrastructure, this will be a false positive (as the real traffic is not impacted) which is not wanted.
Every complete communication traffic from every user will then be dumped in pcap format in a TIM workers' dedicated directory.
By default, there are as many workers as there are CPU Cores on the system. On a 16 Core system, you'll have 16 timworkers actively monitoring their respective data directories for the data to be analyzed.
Example on a CA6000 series Multiport collector:
Note - for performance reasons the nqtmp/tim directory is usually mounted as a RAM file-system with limited capacity. This is why it is imperative that there is enough space available, and the TIM workers fast enough to empty their respective queue. If the TIM's are not fast enough, out-of-space errors will be logged in the TIM logs.
As for the size of the temporary RAM Filesystem - it does not really make sense to make it very large (4 to 6GB). If a TIM work stops working, that queue will not be emptied anymore and it will fill up. Thing is that when this happens, usually something else is wrong, so increasing the size will not really help.