Actually, I was thinking about that... I've managed to whip up a simple python fast agi script. It starts a new thread when it gets a connection and uses python MySQLdb. I couldn't create a pool of database connections for the threads because the docs for MySQLdb say that isn't thread safe. It implements a simple findme/followme feature where it tries a sequence of numbers in order, and plays a sound file between each. Anyway, now that everything is performed through one server-side process, if anything goes wrong with it, either in the python internals (threads maybe?), or a exception occurs that I didn't forsee (when you hang up the current call before the SIP messaging completes, python gets a Broken Pipe exception on the socket for example), then the script completely pukes and dies of course at this point. With one server-side process, you don't have the safety net of one system process perl call. If that screws up, only the current call is affected. I'm really not too confident that I can write (or python is capable of) a fast agi script that is so bullet-proof that I'd want to put production calls through it. Doug.
-----Original Message-----
From: Mike Fedyk [mailto:[EMAIL PROTECTED]
Sent: Thu 1/12/2006 9:33 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Cc:
Subject: Re: [Asterisk-Users] Nested MySQL Commands
Simone Cittadini wrote:
> Douglas Garstang ha scritto:
>
>> So I really wish there was some way to measure how well the worst
>> case scenario would perform. This would be 120 simultaneous calls
>> (don't know how many per second) on a Dual 3.8Ghz Dell PowerEdge 1850
>> with 2GB RAM. Asterisk would call an AGI script, written in perl, to
>> route all calls. The script would have to perform multiple database
>> queries in order to route a call.
>>
>>
> It will work if you need no transcoding, I tested a python agi doing
> something like 6 query to accept / instradate the call and it works
> for 150 / 200 simultaneous calls, the machine starts sweating of
> course, but the voice quality is still good, no drops.
> Mine is just a quick prototype, using fastagi or writing the agi in C
> is surely the way to go, imho fastagi will let you have a more
> configurable / customizable system since you can write the application
> in a object oriented language.
Also an ugly hack would be to call the perl bytecode instead of the text
script. That would allow for the ease of AGI (everything is cleaned up
when the process exits) with lower overhead.
FastAGI is of course what you want for production, but this can help in
a pinch.
Mike
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
Asterisk-Users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
<<winmail.dat>>
_______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
