mainThe eXtended osip library - Support: sr #109369, what is the performance?

 
 

sr #109369: what is the performance?

Submitter:  Andrew <dronord>
Submitted:  Mon 14 Aug 2017 09:58:43 AM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  2 - Minor Status:  Invalid
Privacy:  Public Assigned to:  aymeric
Open/Closed:  Closed Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 24 Aug 2017 09:19:08 PM UTC, comment #6: 

Hi!

I just tried your scenario with code being updated to the latest stack and with my own changes:

sipp is taking full CPU:

25504 jack      20   0   33176   5604   4024 R 100.0  0.0   1:07.95 sipp

Your test/my stack is taking 3,3% CPU:

25456 jack      20   0  109148  38692   3124 S   3.3  0.2   0:03.80 lt-test

Thus, the test you are doing doesn't look to be adequate for testing performance of osip/exosip. SIP message should come from several different host running several instance of sipp. May be that would give better results.

In my test, I see a lot of timeout, but it's pretty hard to see wether this is coming from exosip side or sipp side. Because sipp is running out of CPU, I guess the timeout are more related to sipp side...

Can I close the topic?

Aymeric MOIZARD <aymeric>
Group administrator
Wed 23 Aug 2017 08:58:50 PM UTC, comment #5: 

Nothing changed.

On 40 CPS CPU usage grows up 30%.
On 50 start from 5% and up to 50%.
On 70 start from 8% up to 100%.

You can repeat by:
1. compile main.c
2. install sipp from repo
3. run as sipp -r 70 -sn uac -i 127.0.0.1 127.0.0.1
where 70 - CPS.

Andrew <dronord>
Wed 23 Aug 2017 06:13:35 PM UTC, comment #4: 

minor change, the code is

eXosip_default_action(evt);

not

eXosip_default_action(je);

;)
Aymeric

Aymeric MOIZARD <aymeric>
Group administrator
Wed 23 Aug 2017 06:12:17 PM UTC, comment #3: 

eXosip_automatic_action is not used to send reply.
It is used to refresh registration, handle "timer" feature for dialog, and handle authentication procedure (by resending request with credentials)

You can try replacing the second call to eXosip_automatic_action by the more efficient (but less complete)  API: eXosip_default_action

 evt = eXosip_event_wait (0, 20);

 if (evt == NULL)
 {
   eXosip_automatic_action();
   continue;
 }

 eXosip_lock();
 eXosip_default_action(je);
 //eXosip_automatic_action();

However, if you have continuous flow, "eXosip_automatic_action()" will never be called and this could prevent a few expected actions to be taken.

The above code will work for UA, but if traffic is too intensive, evt==NULL never happens, and eXosip_automatic_action is never called.

In the old stack, 200 ok for BYE are sent automatically (not by eXosip_automatic_action).
In the newer stack, there is a setting to either choose between automatic replies OR calling the API to answer incoming request for calls. (eXosip_call_send_answer)


Let me know the results you have with this!
Regards
Aymeric

Aymeric MOIZARD <aymeric>
Group administrator
Wed 23 Aug 2017 01:18:31 PM UTC, comment #2: 

Version in Fedora rpm (attache here) without context.
W/o context result is identical.

&gt; evt = eXosip_event_wait (0, 1);
&gt; evt = eXosip_event_wait (0, 20);
evt = eXosip_event_wait (0, 50);
evt = eXosip_event_wait (1, 0);
Result is identical.

&gt; In your scenario, are you also closing calls?
BYE after ACK without delay.

&gt; Just make sure you don't call it too much.
How to reply 100/200/200(BYE) without eXosip_automatic_action()?

Andrew <dronord>
Thu 17 Aug 2017 05:16:45 PM UTC, comment #1: 

Hi Andrew,

The version you are using seems pretty old. There is no "context" as the first parameter, so I guess this is a version before 2012 or 2013.

I have to say that eXosip2 itself is designed to be used for being an UA. Not for processing many calls.

Despite this, some people are using it for such usage (voicemail or gateway services?)

First change I advise: Instead of:

evt = eXosip_event_wait (0, 1);

use

evt = eXosip_event_wait (0, 20);

Then, as you are expecting a high number of transaction, ou should try to lower the number of call of eXosip_automatic_action. If you receive 70 INVITE, the code will wake up too often and thus, eXosip_automatic_action will be called for every wake up. This is too much. Just make sure you don't call it too much.

In your scenario, are you also closing calls? If they always remains, then, for eXosip2, it would increase the number of "active calls", and the list would just increase by 70 each seconds and it would anyway end with too much active call in the list.

Aymeric MOIZARD <aymeric>
Group administrator
Mon 14 Aug 2017 09:58:43 AM UTC, original submission:  

code in attache

> sipp -sn uac -r 70 ...

70 INVITE/s - CPU 100%, it is max?

eXosip/osip from repo Fedora 26 x64
Core2Duo 3GHz

Andrew <dronord>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #41514:  main.c added by dronord (2KiB - text/x-csrc)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by aymeric (Posted a comment)
  • -email is unavailable- added by dronord (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-08-29 aymeric Open/ClosedOpen Closed
    2017-08-29 aymeric StatusIn Progress Invalid
    2017-08-17 aymeric Severity3 - Normal 2 - Minor
        StatusNone In Progress
        Assigned toNone aymeric
    2017-08-14 dronord Attached File- Added main.c, #41514

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code