jsip
  1. jsip
  2. JSIP-301

JAIN-SIP multi-threading when all calls use single TCP socket

    Details

    • Type: Task Task
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: current
    • Fix Version/s: milestone 1
    • Component/s: www
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      301

      Description

      Adding a new option disabled by default.

      gov.nist.javax.sip.TCP_POST_PARSING_THREAD_POOL_SIZE = integer </b>

      • Use 0 or no not set this option to disable it.
      • When using TCP your phones/clients usually connect independently creating
        their own TCP
      • sockets. Sometimes however SIP devices are allowed to tunnel multiple calls
        over
      • a single socket. This can also be simulated with SIPP by running "sipp -t
        t1".
      • In the stack each TCP socket has it's own thread. When all calls are using
        the same
      • socket they all use a single thread, which leads to severe performance
        penalty,
      • especially on multi-core machines.
      • This option instructs the SIP stack to use a thread pool and split the CPU
        load
      • between many threads. The number of the threads is specified in this
        parameter.
      • The processing is split immediately after the parsing of the message. It
        cannot
      • be split before the parsing because in TCP the SIP message size is in the
      • Content-Length header of the message and the access to the TCP network stream
      • has to be synchronized. Additionally in TCP the message size can be larger.
      • This causes most of the parsing for all calls to occur in a single thread,
        which
      • may have impact on the performance in trivial applications using a single
        socket
      • for all calls. In most applications it doesn't have performance impact.
      • If the phones/clients use separate TCP sockets for each call this option
        doesn't
      • have much impact, except the slightly increased memory footprint caused by
        the
      • thread pool. It is recommended to disable this option in this case by setting
        it
      • 0 or not setting it at all. You can simulate multi-socket mode with "sipp -t
        t0".
      • With this option also we avoid closing the TCP socket when something fails,
        because
      • we must keep processing other messages for other calls.

      After some back and forth this seems to work for all our cases.

      Ranga what do you think?

        Activity

        Hide
        vralev added a comment -

        How about changing the patch in a way that it clearly don't change the code-path
        if the option is disabled?

        if(disabled)

        { // exactly the same old code }

        else

        { //new code }

        That is doable and should guarantee the old behaviour?

        In fact the current patch adds some overhead and I should change it anyway.

        Show
        vralev added a comment - How about changing the patch in a way that it clearly don't change the code-path if the option is disabled? if(disabled) { // exactly the same old code } else { //new code } That is doable and should guarantee the old behaviour? In fact the current patch adds some overhead and I should change it anyway.
        Hide
        mranga added a comment -

        Yes such a check would be fine. Please make sure the documentation for this
        property clearly states the limitation.

        Show
        mranga added a comment - Yes such a check would be fine. Please make sure the documentation for this property clearly states the limitation.
        Hide
        vralev added a comment -

        All done. Checked in in trunk and in the sipx-stable branch.

        Show
        vralev added a comment - All done. Checked in in trunk and in the sipx-stable branch.
        Hide
        vralev added a comment -

        After more analysis this case could be improved by moving 99% of the parsing into worker threads

        Show
        vralev added a comment - After more analysis this case could be improved by moving 99% of the parsing into worker threads
        Hide
        vralev added a comment -

        The first working patch

        Show
        vralev added a comment - The first working patch

          People

          • Assignee:
            vralev
            Reporter:
            vralev
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: