When K connects to another SIP proxy over TCP or TLS, the connection is shared for all requests to that destination. If the receiving SIP proxy is K, it means that only one worker process is handling all those requests. This may become a bottleneck if processing of requests is time consuming, e.g., because of DB operations.
It should therefore be possible one way or another to establish more than one parallel TCP or TLS connections to the same destination. One solution could be based on a function call, such as t_forward_connect(number), to be called before t_relay specifying the desired number of parallel connections shared randomly by outgoing requests.
I think this is the way the SIP RFC wants it, but I see the problem too. Using an async process in the receiving end where you move transactions to a group of background processes will offload a bit, but it may still be a bottleneck of sorts.
+1 for this feature request.
I ran into this bottleneck, as discussed on this thread:
https://lists.kamailio.org/pipermail/sr-users/2018-February/100447.html
As a workaround, I've opted for the async process technique, but it's not perfect, because some operations don't execute properly on the async route. Specifically, I've discovered that set_dlg_profile() does not seem to work on the async route.
Notwithstanding the fact that not all operations work in async routes, I would be curious to know why distributing the workload into a pool of async workers is "still a bottleneck of sorts". Are there architectural reasons for this that I am failing to consider?
Also: I use set_dlg_profile(), but not in 'async' routes per se; instead, I suspend TM transactions and push them over an 'mqueue' into 'rtimer' processes. This appears to work fine.
When K connects to another SIP proxy over TCP or TLS, the connection is shared for all requests to that destination. If the receiving SIP proxy is K, it means that only one worker process is handling all those requests. This may become a bottleneck if processing of requests is time consuming, e.g., because of DB operations.
It should therefore be possible one way or another to establish more than one parallel TCP or TLS connections to the same destination. One solution could be based on a function call, such as t_forward_connect(number), to be called before t_relay specifying the desired number of parallel connections shared randomly by outgoing requests.
As simple workaround you could map multiple alias / IP addresses to a single NIC? And feed the dispatcher module with the multiple alias.
This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
Closed #1107 as not planned.
-
Alex Balashov -
codyherzog
-
github-actions[bot]
-
juha-h
-
kvrban
-
Olle E. Johansson