[asterisk-dev] Asterisk modules in C++

[Donny Kavanagh]

In this case i think the time required to spawn each individual process is
definitively having an effect.  A well coded FastAGI server with persistent
database connections and a minimum number of worker threads would help for
sure.

Donny

On Sun, May 9, 2010 at 8: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100509/04c27c0c/attachment.htm