[asterisk-dev] Asterisk Performance as a B2BUA
dimas at dataart.com
Fri Nov 23 11:32:44 CST 2007
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
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.
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Simon
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
> own threads.
I think you are confusing things. There are generally two ways of using
1) A single thread handles all I/O. Nonblocking I/O is used for sockets,
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
Asterisk's chan_sip, currently, we're in situation #1 and disk I/O (e.g.
logging) is offloaded to a secondary thread. If there was a lot of disk
(hint: there is not) it may not be 100% efficient because that single
for disk I/O cannot queue multiple requests at the same time. That's why
is superior: it can queue all I/O requests at the same time. And we
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
SIP requests was to switch to situation #2, which has been proven by
sources (e.g. W. Richard Stevens, "UNIX Network Programming") to not be
efficient as #1.
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
More information about the asterisk-dev