El Miércoles, 24 de Junio de 2009, Daniel-Constantin Mierla escribió:
- rtpproxy seems to not take advantage of SMP
it is well known, but you can run one or two instances per core and load balance from the nathelper module. I usually start 2 per cpu core.
I've asked some times some doubts about this supposed "load balance" system (which I can't trust at 100%).
Which the current RtpProxy documentation there is no info enough to ensure that load balancing should work correctly. I sent the following mail to rtpproxy-dev maillist but unfortunatelly got no reply. Perhaps I could receive now some comments on it? I'd really appreciate them.
My mail ot rtpproxy-dev ML:
---------------------------- Hi, using multiple RtpProxy instancies would be more flexible if set_rtp_proxy_set() allows a pseudo-variable instead of just a fixed integer.
Without this feature, it's impossible to implement real RtpProxy loadbalancing since: how to use the same RtpProxy for an in-dialog request? Let me show an example:
- Let's suppose we have these rtpproxies:
modparam("nathelper", "rtpproxy_sock", "1 == udp:1.1.1.1:12221") modparam("nathelper", "rtpproxy_sock", "2 == udp:2.2.2.2:12221")
(note that I don't use various rtpproxies in the same set since with the, real loadbalancing it's not possible).
- An INVITE arrives and we want to use a ramdom rtpproxy (set 1 or 2). Since set_rtp_proxy_set() doesn't allow pv, the only way is something as computing the from_tag or call-id and get values 0 or 1 (or 1 or 2). In the first case we invoke set_rtp_proxy_set("1") and in the second set_rtp_proxy_set("2").
- When processing the 183/200 response we should do the same (get 1 or 2 from the from_tag or call-id), or perhaps add a parameter in RR (rtpproxy_set=1) and invoke the corresponding set_rtp_proxy_set() function.
- The same for every in-dialog request (re-INVITE, BYE...).
I understand that this mechanims is not really scalable since adding a new rtpproxy requires modifications in the kamailio script (the ramdom function which now should return 1, 2 or 3 depending on the call-id/from_tag hash or something similar) and also adding a new "else if (XXXXX) { set_rtp_proxy_set("3") ... }"
So, extending set_rtp_proxy_set() to allow pv would mitigate this issue: - When the INVITE arrives a ramdom function returns 1,2,3..., we store that value in a pv and use it into set_rtp_proxy_set(). - We also store that value in a RR param to retrieve it in replies and in- dialog requests in order to invoke the samertpproxy set.
About various rtpproxy instances per set: I consider there is no solution for it. If we have:
# multiple rtproxies for LB modparam("nathelper", "rtpproxy_sock", "udp:localhost:12221 udp:localhost:12222")
We invoke "rtpproxy_offer" and some rtpproxy has been transparently selected, but we CANNOT know which one, so, how to reuse it in the reply and in-dialog requests??
I remember a thread about it in which the code was inspected and some "hash algorithm" resulted to take place to select the rtpproxy instance. However I remember that this algorithm is not so robust as required for a real loadbalancing system.
So, in conclusion, is there any aim in improving RtpProxy module to allow real and robust load-balancing? What about multiple rtpproxy instances in the same set? is it really usable?
Thanks a lot for any comment on it. -------------------------