[asterisk-dev] Asterisk modules in C++

[Chris Tooley]

By comparison, we handle millions of calls a day, tens of thousands
concurrently and each call executes several (up to 12) AGIs. We can see 15
calls a second hit each of our servers and no issues as far as that goes.

I happen to completely agree with fixing the design and converting to a
FastAGI, not creating a module. Having a bug that ocurrs once every million
calls or so take down everything because your logic fails is a bad idea.

On May 9, 2010 12:28 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...

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

On Sun, 9 May 2010, Deepesh D wrote:

> The AGI does some database lookups and based on the results sets some
> dialplan variables. In th...
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 E...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100509/200c2e26/attachment.htm