[asterisk-dev] Asterisk Performance as a B2BUA

[Dmitry Andrianov]

>> 1. some SIP messages may require Asterisk to do asynchronous database
>> query (realtime)
>
> I don't get your point. If the query is asynchronous, where is the
problem? 
> What does "realtime" mean?

Sorry, I meant synchronous query. Asterisk allows storing SIP peer/user
data in the database and issues query to the database to retrieve/update
the data. This is what called "realtime" in Asterisk context -
http://www.voip-info.org/wiki-Asterisk+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%.
>
> Again, where is the problem?

The problem is that SIP processing thread has to wait while another
thread releases some lock. It is possible that during that wait time
other SIP messages could be read from the socket and processed but SIP
thread won't start processing it - it has to wait until it finishes
processing of current message first. So the time (not CPU cycles!) will
be wasted where second thread would happily take second SIP message and
process it.

Well, I do not really think this one is an issue at all, I was just
trying to point you there something you have to consider in addition to
just "if SIP thread loads CPU 100%". 


-----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 9:07 PM
To: Asterisk Developers Mailing List
Subject: Re: [asterisk-dev] Asterisk Performance as a B2BUA

On Friday 23 November 2007 12:32:44 Dmitry Andrianov wrote:
> 1. some SIP messages may require Asterisk to do asynchronous database
> query (realtime)

I don't get your point. If the query is asynchronous, where is the
problem? 
What does "realtime" mean?

> 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%.

Again, where is the problem?

My point is: the SIP thread does *not* use 100% of its allocated time
slices. 
Unless it does, there is no point in adding SIP threads.

> 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.

What you're saying in effect is that the SIP thread uses 100% of its
allocated 
time slices *for a very short period of time*, and therefore multiple
threads 
are justified during that very short period of time. Well, this is true
of 
any kind of processing but you need to keep Amdahl's law in mind.
Optimizing 
for CPU while the process is clearly I/O bound is wrong. Also it doesn't

justify adding all the complexity.

_______________________________________________
--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