[asterisk-dev] Asterisk modules in C++

Chris Tooley chris at tooley.com
Sun May 9 19:39:40 CDT 2010


I have worked on several platforms that have handled a lot more calls
than that, one platform now handles 250-300 calls per second. None of
them required a module. Fast AGI or ExternalIVR using a socket
connection are your best choice.

On Sun, May 9, 2010 at 7:13 PM, Deepesh D <deep.d2010 at gmail.com> wrote:
> I am looking at handling around 20-25 calls per second. Without AGI my
> system is able to take upto 30-35 CPS, with AGI this falls to 13-15
> CPS. Even this figure was reached after I did database optimizations
> and combined 4 agis into one. Earlier with 4 agis per call it used to
> take only 5-7 CPS.
>
> I also did a test where the AGI exits without doing anything. Just the
> process of calling the AGI increases the CPU utilization by 25%.
>
> On Sun, May 9, 2010 at 10:58 PM, Steve Edwards
> <asterisk.org at sedwards.com> wrote:
>>>> On Sun, 9 May 2010, Deepesh D wrote:
>>>>
>>>>> Performance is the main reason for switching from AGI to module. Will
>>>>> a FastAGI running on the same server as asterisk give me improved
>>>>> performance?
>>
>>> On Sun, May 9, 2010 at 9:09 PM, Steve Edwards
>>
>>>> While creating a new process is typically a very "expensive" (in CPU
>>>> resources) process, any reasonably modern processor can create hundreds
>>>> of processes per second.
>>>>
>>>> Before switching to FastAGI, why do you think process creation is the
>>>> limiting factor in your quest for improved performance?
>>>>
>>>> How about some details about exactly what you are doing and what your
>>>> AGIs are doing?
>>
>> On Sun, 9 May 2010, Deepesh D wrote:
>>
>>> The AGI does some database lookups and based on the results sets some
>>> dialplan variables. In the dialplan the call is routed to different
>>> extensions based on the value of these variables. The database I use is
>>> postgresql. The AGI uses libpq++ (postgresql's C++ interface) to connect
>>> with database.
>>
>> I see no benefit to implementing this as a module.
>>
>> Implementing your AGI as FastAGI would eliminate process creation and
>> database connection overhead.
>>
>> I suspect a minor improvement in database design, indexing, etc. could
>> yield orders of magnitude more improvement in performance than converting
>> from AGI to FastAGI.
>>
>> How many calls per second are you handling? I have a host (Intel(R)
>> Xeon(TM) CPU 3.40GHz) handling 60,000 calls per day -- just under 1 call
>> per second.
>>
>> Each call executes 4 AGIs, each accessing the database, before the caller
>> hears first audio. Each call may execute dozens of other AGIs through the
>> life of the call.
>>
>> If I were to do it again, I would merge the 4 AGIs into a single AGI and
>> would consider FastAGI, but I have no performance problems at this CPS
>> level.
>>
>> I'm not against FastAGI, I'm just saying it may not be the silver bullet
>> you are looking for.
>>
>> --
>> Thanks in advance,
>> -------------------------------------------------------------------------
>> Steve Edwards       sedwards at sedwards.com      Voice: +1-760-468-3867 PST
>> Newline                                              Fax: +1-760-731-3000
>>
>> --
>> _____________________________________________________________________
>> -- 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
>>
>
> --
> _____________________________________________________________________
> -- 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
>



-- 

Chris Tooley
mobile: 615-525-8067
Instant Messenger
MSN: ctooley at ntrc.net
AIM: mrchristooley
Yahoo: mrchristooley
Google Talk: ctooley at gmail.com



More information about the asterisk-dev mailing list