[asterisk-dev] Asterisk Performance as a B2BUA

[Dmitry Andrianov]

Well, I believe there are at least two reasons which may prevent SIP
thread to utilize CPU 100% even in the case there are more SIP messages
than the systzem can handle:
1. some SIP messages may require Asterisk to do asynchronous database
query (realtime)
2. locking: if during any operation SIP thread has to obtain lock held
by another thread, waiting on that lock will definitely make CPU
utilization less than 100%.

Another benefit in having multiple threads is reduced latency. If 10 SIP
messages arrive to the asterisk server simultaneously and each message
takes 10 ms to be handled, it means first response to the first message
will be sent in 10 ms while last message will be replied only in 100 ms.
On dual-core system, running two SIP threads, last message most likely
won't take more than 50 ms.

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Simon
Perreault
Sent: Friday, November 23, 2007 5:08 PM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Asterisk Performance as a B2BUA

On Friday 23 November 2007 05:28:50 Vadim Lebedev wrote:
> I believe that it amounts to the same....
> When you use aio you simply using kernel-provided threads instead of
you
> own threads.

I think you are confusing things. There are generally two ways of using 
threads:

1) A single thread handles all I/O. Nonblocking I/O is used for sockets,
but 
disk I/O can still block.
2) One thread for each SIP socket. Blocking I/O is used. Cannot wait on 
multiple I/O at the same time.

To fix #1, you either use aio, or offload disk I/O to a secondary
thread. In 
Asterisk's chan_sip, currently, we're in situation #1 and disk I/O (e.g.
for 
logging) is offloaded to a secondary thread. If there was a lot of disk
I/O 
(hint: there is not) it may not be 100% efficient because that single
thread 
for disk I/O cannot queue multiple requests at the same time. That's why
aio 
is superior: it can queue all I/O requests at the same time. And we
cannot 
achieve the same performance as aio in user-space because we'd have to 
allocate one thread per disk I/O request, which would be very slow.

As I understood it, the proposition for creating a pool of threads
handling 
SIP requests was to switch to situation #2, which has been proven by
many 
sources (e.g. W. Richard Stevens, "UNIX Network Programming") to not be
as 
efficient as #1.

_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev