[reSIProcate] [reSIProcate-users] resip/dum performance issue

Mon Apr 27 14:47:02 CDT 2009

As far as I know, Windows handles sockets and file descriptors 
differently. You can not call select() on anything but a set of SOCKET 
structures, so this would be an UNIX-only solution.

regards,
  gabriel

Byron Campen wrote:
>   Cross-posting to resip-devel, since we're talking about a pretty 
> significant change here. 
> 
> Yeah, but there is a tradeoff here; when dealing with really high load, 
> the transport fds are firing constantly, meaning that we almost never 
> block. And putting that extra fd into the select call does impose a 
> (small) performance penalty.
> 
> What does everyone think about this?
> 
> Best regards,
> Byron Campen
> 
>> At this point I am pretty sure that the problem is the udp buffer 
>> size. After switching to TCP or when increasing the udp RCV buffer 
>> size to 16K (the default is 8K) I am not seeing the retransmissions 
>> and there is no spikes. I think that the approach of having the TU put 
>> thing into the pipe that is a part of the select fd set the stack sits 
>> on is better then have it wake up every 25ms.
>> I think maybe we should have a buffer size configurable thru stack API 
>> in the future.
>> Ilana   
>>  
>> *From:* Byron Campen [mailto:bcampen at estacado.net] 
>> *Sent:* Monday, April 27, 2009 12:47 PM
>> *To:* Adam Roach
>> *Cc:* Scott Godin; Ilana Polyak; resiprocate-users at resiprocate.org 
>> <mailto:resiprocate-users at resiprocate.org>
>> *Subject:* Re: [reSIProcate-users] resip/dum performance issue
>>  
>>             We should be taking everything that is there. Also, I'm 
>> wondering how we're seeing INVITE retransmissions 400 ms after the 200 
>> hits the wire; this doesn't involve DUM in any way.
>>  
>> Best regards,
>> Byron Campen
>>
>>
>> Are you saying we just take the top message and go back into a wait 
>> instead of draining the queue?
>>
>> /a
>>
>> On 04/27/2009 11:23 AM, Byron Campen wrote:
>>  Yeah, but we're talking about 25 transactions.
>>  
>> Best regards,
>> Byron Campen
>>
>>
>> That wouldn't be a bad thing to do, but I don't think it causes the 
>> issue described in the email. There's an order of magnitude difference 
>> between 25 ms and 500 ms.
>>
>> So it may improve the situation, but it's not the sole cause.
>>
>> /a
>>
>> On 04/27/2009 10:41 AM, Byron Campen wrote:
>>  A while back, I noticed a slight problem in the way the stack's 
>> process loop is constructed. The issue is that we can get in a 
>> situation where we are blocking on a select call (in the transport 
>> code) when there is work to be done in the transaction layer. 
>> Basically, let's say we get down into the select call; we're waiting 
>> for an fd to become ready. Then, the TU sends a request down to the 
>> stack. This does not interrupt the select call; we sit there waiting 
>> for an fd to become ready for 25ms, time out, and then notice the new 
>> work that the TU kicked down to us. We could solve this by using the 
>> "self-pipe" trick; where we have an anonymous pipe that we write a 
>> single byte to whenever stuff gets put in the state machine fifo, and 
>> we select on this pipe's fd along with the transport fds.
>>  
>> Best regards,
>> Byron Campen
>>
>>
>> That sounds strange.  Assuming the process loop is written correctly, 
>> I wouldn't expect this behaviour.  Are you using StackThread and 
>> DumThread from resip code unmodified?  Can you post your test program(s)?
>>  
>> >Also I noticed that stack gets select interrupt for each message is it possible that this creates a problem?
>>  
>> I'm not really sure why you think this is a problem - that's what is 
>> supposed to happen.  Can you explain your question in more detail?
>>  
>> Thanks,
>> Scott
>> On Wed, Apr 1, 2009 at 10:02 AM, Ilana Polyak 
>> <Ilana.Polyak at audiocodes.com <mailto:Ilana.Polyak at audiocodes.com>> wrote:
>>
>> Hello
>>
>> Maybe someone can help me with some performance issues I am seeing.
>>
>> I have a test client application that generates 25 simultaneous calls 
>>  and another application that acts as a server and response back with 
>> ok. After all 25 calls are connected the client app issues another 25 
>> calls and so own.
>>
>> A am calculating the time from when the first invite is sent until the 
>> last OK for invite is received to see how many connect per second I 
>> can have and the result are vary. Sometimes it will be just 60 msec 
>> and sometimes 500 msec. It looks like the stack is retransmitting some 
>> of the Invites because OK is not received on time. But when I run 
>> ethereal I see that OK came it 400 msec before invite was 
>> retransmitted. So it looks like the dum is not fast enough to keep up 
>> with the stack. Does anyone have any dum performance measurements?
>>
>> I am running stack using StackThread and I tried running dum from my 
>> app and separately in dumthread.
>>
>> Also I noticed that stack gets select interrupt for each message is it 
>> possible that this creates a problem?
>>
>> Thanks a lot
>>
>>  
>>
>> I am using release 1.3.4, windows XP Pentium 3.2Gh.
>>
>>  
>>
>> Ilana
>>
>>  
>>  
>> ------------------------------------------------------------------------
>> This email and any files transmitted with it are confidential 
>> material. They are intended solely for the use of the designated 
>> individual or entity to whom they are addressed. If the reader of this 
>> message is not the intended recipient, you are hereby notified that 
>> any dissemination, use, distribution or copying of this communication 
>> is strictly prohibited and may be unlawful.
>>
>> If you have received this email in error please immediately notify the 
>> sender and delete or destroy any copy of this message
>>
>> _______________________________________________
>> resiprocate-users mailing list
>> resiprocate-users at resiprocate.org 
>> <mailto:resiprocate-users at resiprocate.org>
>> List Archive: http://list.resiprocate.org/archive/resiprocate-users/
>>  
>> _______________________________________________
>> resiprocate-users mailing list
>> resiprocate-users at resiprocate.org 
>> <mailto:resiprocate-users at resiprocate.org>
>> List Archive: http://list.resiprocate.org/archive/resiprocate-users/
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> resiprocate-users mailing list
>> resiprocate-users at resiprocate.org <mailto:resiprocate-users at resiprocate.org>
>> List Archive: http://list.resiprocate.org/archive/resiprocate-users/
>>  
>>  
>>  
>>  
>>
>> ------------------------------------------------------------------------
>> This email and any files transmitted with it are confidential 
>> material. They are intended solely for the use of the designated 
>> individual or entity to whom they are addressed. If the reader of this 
>> message is not the intended recipient, you are hereby notified that 
>> any dissemination, use, distribution or copying of this communication 
>> is strictly prohibited and may be unlawful.
>>
>> If you have received this email in error please immediately notify the 
>> sender and delete or destroy any copy of this message
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel