RE: [Asterisk-Users] Nested MySQL Commands
Is it possible to have nested MySQL queries in extensions.conf? Ie, perform a query, grab a value, and then jump to another location in the dialplan and do another query based on that original value. I'm having problems with the result and fetchid's and I'm not sure if it's even possible to do this or not. Just make sure that you use different variable names for each query if the values should stay available after the next query. What we tend to do is grab the data from the database and the stuff that should stay around for a longer time is assigned to a new and appropriately named variable. So the original variable can be used again. We've got loads of queries in our extensions.conf. -- Andreas Sikkema BBned NV Software EngineerPlaneetbaan 4 +31 (0)23 70743422132 HZ Hoofddorp ___ --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
Re: [Asterisk-Users] Nested MySQL Commands
Douglas Garstang ha scritto: Peter, I assume you mean something like this in extensions.conf: exten = _X.,1,AGI(master-dial-logic.pl) and then there's only one call. All logic would be performed by the perl script. This has many advantages. One disadvantage however is that potentially, there could be 120 simultaneous instances of this script running (one per call). Douglas. but you can use fastagi, it will be maybe a little more complex to write the server code but it should scale better, shouldn't it ? ___ --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
Re: [Asterisk-Users] Nested MySQL Commands
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. ___ --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
RE: [Asterisk-Users] Nested MySQL Commands
Andreas. I tried that. Still didn't work. It just appears that Asterisk doesn't like letting you execute another query while it's holding on to the state of a previous one. Doug. -Original Message- From: Andreas Sikkema [mailto:[EMAIL PROTECTED] Sent: Thursday, January 12, 2006 2:01 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: RE: [Asterisk-Users] Nested MySQL Commands Is it possible to have nested MySQL queries in extensions.conf? Ie, perform a query, grab a value, and then jump to another location in the dialplan and do another query based on that original value. I'm having problems with the result and fetchid's and I'm not sure if it's even possible to do this or not. Just make sure that you use different variable names for each query if the values should stay available after the next query. What we tend to do is grab the data from the database and the stuff that should stay around for a longer time is assigned to a new and appropriately named variable. So the original variable can be used again. We've got loads of queries in our extensions.conf. -- Andreas Sikkema BBned NV Software EngineerPlaneetbaan 4 +31 (0)23 70743422132 HZ Hoofddorp ___ --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 ___ --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
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
Re: [Asterisk-Users] Nested MySQL Commands
Andreas Sikkema wrote: Is it possible to have nested MySQL queries in extensions.conf? Ie, perform a query, grab a value, and then jump to another location in the dialplan and do another query based on that original value. I'm having problems with the result and fetchid's and I'm not sure if it's even possible to do this or not. Just make sure that you use different variable names for each query if the values should stay available after the next query. What we tend to do is grab the data from the database and the stuff that should stay around for a longer time is assigned to a new and appropriately named variable. So the original variable can be used again. I'd rather use a hash (also called associative arrays in other languages) instead of calling eval to assign a variable. ___ --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
Re: [Asterisk-Users] Nested MySQL Commands
On 1/13/06, Mike Fedyk [EMAIL PROTECTED] wrote: [..snip..] 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. Also, just a suggestion that was mentioned to me by somebody (whose nick I can't remember, sorry!) on the #asterisk chan, when using AGI to do the sort of thing the original poster is after, it's a good idea to set some dial variable and let the AGI exit and Dial from Asterisk using this variable. This way the AGI exits and doesn't stay running for the duration of the call. Regards, Gonzalo ___ --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
RE: [Asterisk-Users] Nested MySQL Commands
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
RE: [Asterisk-Users] Nested MySQL Commands
No an option. Too slow and too resource intensive. -Original Message- From: Gonzalo Servat [mailto:[EMAIL PROTECTED] Sent: Thu 1/12/2006 9:47 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Cc: Subject: Re: [Asterisk-Users] Nested MySQL Commands On 1/13/06, Mike Fedyk [EMAIL PROTECTED] wrote: [..snip..] 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. Also, just a suggestion that was mentioned to me by somebody (whose nick I can't remember, sorry!) on the #asterisk chan, when using AGI to do the sort of thing the original poster is after, it's a good idea to set some dial variable and let the AGI exit and Dial from Asterisk using this variable. This way the AGI exits and doesn't stay running for the duration of the call. Regards, Gonzalo ___ --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 ___ --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
[Asterisk-Users] Nested MySQL Commands
Is it possible to have nested MySQL queries in extensions.conf? Ie, perform a query, grab a value, and then jump to another location in the dialplan and do another query based on that original value. I'm having problems with the result and fetchid's and I'm not sure if it's even possible to do this or not. Thanks, Doug. ___ --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
Re: [Asterisk-Users] Nested MySQL Commands
On 11/01/06, Douglas Garstang [EMAIL PROTECTED] wrote: Is it possible to have nested MySQL queries in extensions.conf? Ie, perform a query, grab a value, and then jump to another location in the dialplan and do another query based on that original value. I'm having problems with the result and fetchid's and I'm not sure if it's even possible to do this or not. When things start to get that complicated, I reckon it's time for AGI Peter -- Peter Bowyer Email: [EMAIL PROTECTED] Tel: +44 1296 768003 VoIP: sip:[EMAIL PROTECTED] VoIP: [EMAIL PROTECTED] FWD: **275*5048707000 VoipTalk: **473*5048707000 ___ --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
RE: [Asterisk-Users] Nested MySQL Commands
Peter, Too slow! We're going to potentially be doing several MySQL lookups for routing even the most basic of calls, and if every one of those queries has to make a call out to an AGI script, it would become a performance problem. Douglas. -Original Message- From: Peter Bowyer [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 11:27 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] Nested MySQL Commands On 11/01/06, Douglas Garstang [EMAIL PROTECTED] wrote: Is it possible to have nested MySQL queries in extensions.conf? Ie, perform a query, grab a value, and then jump to another location in the dialplan and do another query based on that original value. I'm having problems with the result and fetchid's and I'm not sure if it's even possible to do this or not. When things start to get that complicated, I reckon it's time for AGI Peter -- Peter Bowyer Email: [EMAIL PROTECTED] Tel: +44 1296 768003 VoIP: sip:[EMAIL PROTECTED] VoIP: [EMAIL PROTECTED] FWD: **275*5048707000 VoipTalk: **473*5048707000 ___ --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 ___ --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
Re: [Asterisk-Users] Nested MySQL Commands
On Wed, 11 Jan 2006 11:39:20 -0700 Douglas Garstang [EMAIL PROTECTED] wrote: Peter, Too slow! We're going to potentially be doing several MySQL lookups for routing even the most basic of calls, and if every one of those queries has to make a call out to an AGI script, it would become a performance problem. Douglas. -Original Message- From: Peter Bowyer [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 11:27 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] Nested MySQL Commands On 11/01/06, Douglas Garstang [EMAIL PROTECTED] wrote: Is it possible to have nested MySQL queries in extensions.conf? Ie, perform a query, grab a value, and then jump to another location in the dialplan and do another query based on that original value. I'm having problems with the result and fetchid's and I'm not sure if it's even possible to do this or not. When things start to get that complicated, I reckon it's time for AGI Peter Has anyone yet played with MySQL version 5?? My understanding is that is now includes stored procedures. Wonder if that will help things with Asterisk? Send a query over to the MySql server with only the required parameters and have it do all the processing for you and only returns the results. I know that is a nice feature od Microsoft Sql. But have not had a chance to read up on the performance of the new version of MySql... Robert ___ --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
Re: [Asterisk-Users] Nested MySQL Commands
Send a query over to the MySql server with only the required parameters and have it do all the processing for you and only returns the results. THe above describes the whole point of a SQL DBMS Server. WHat else could you ask one to do for you? Back to the original question: Can you use the result of one query to feed another without going to the DBMS twice? Yes, Of course SQL allows this. In fact Data base experts would be horrified to see any code that querries a value, holds that value and then querries based on that value. Doing this without holding a lock on the relevent tables is just plain wrong and will result in bugs. You should _always_ write the SQL querry such that only one querry gives you the results you need. Manual Locks are not good, they can be the source of very serious performance problems. For more specific advice you would need to post the details of what you are tring to do and a bit of the SQL you are using. I know that is a nice feature od Microsoft Sql. But have not had a chance to read up on the performance of the new version of MySql... Basically MySQL is very fast when the load is light but scales very poorly with either higher loads or higher conplexity querries. It is good for flat file like problems. The larger DBMSes are slower initially but scale better. (Please CC any replies to my direct email) Chris Albertson Home: 310-376-1029 [EMAIL PROTECTED] Cell: 310-990-7550 Office: 310-336-5189 [EMAIL PROTECTED] KG6OMK __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ --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
RE: [Asterisk-Users] Nested MySQL Commands
We are trying to implement findme/followme. The dialplan first queries the dialled number in the database and determines if it is OnNet(IP) or OffNet(PSTN). If it is OnNet, it then queries a findme/followme table, which looks like this: mysql select * from ast_findme; ++---+--+---+-+ | id | extension | sequence | dial | playback | ++---+--+---+-+ | 1 | 3254101 |1 | SIP/3254102SIP/3254101|10|tr | wait-offensive-sounds | | 2 | 3254101 |2 | SIP/3254101|10|tr | call-forward | | 3 | 3254101 |3 | SIP/13033372500 | nbdy-avail-to-take-call | ++---+--+---+-+ 3 rows in set (0.00 sec) The dialplan will retrieve each record for the called number, one at a time, and attempt to dial the new number. The 'dial' column is passed directly to the Dial() command. However, before it can dial that number it has to check once again and see if the new number is OnNet or OffNet. If it is OffNet, send the call off to the proxy server. If it is OnNet, dial the number directly. As you can see, this isn't trivial. I'm no MySQL expert, and I can't see a way to do this without first obtaining each new number, and then querying it individually to determine if it is OnNet or OffNet before dialling it. Douglas. -Original Message- From: Chris Albertson [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 12:40 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] Nested MySQL Commands Send a query over to the MySql server with only the required parameters and have it do all the processing for you and only returns the results. THe above describes the whole point of a SQL DBMS Server. WHat else could you ask one to do for you? Back to the original question: Can you use the result of one query to feed another without going to the DBMS twice? Yes, Of course SQL allows this. In fact Data base experts would be horrified to see any code that querries a value, holds that value and then querries based on that value. Doing this without holding a lock on the relevent tables is just plain wrong and will result in bugs. You should _always_ write the SQL querry such that only one querry gives you the results you need. Manual Locks are not good, they can be the source of very serious performance problems. For more specific advice you would need to post the details of what you are tring to do and a bit of the SQL you are using. I know that is a nice feature od Microsoft Sql. But have not had a chance to read up on the performance of the new version of MySql... Basically MySQL is very fast when the load is light but scales very poorly with either higher loads or higher conplexity querries. It is good for flat file like problems. The larger DBMSes are slower initially but scale better. (Please CC any replies to my direct email) Chris Albertson Home: 310-376-1029 [EMAIL PROTECTED] Cell: 310-990-7550 Office: 310-336-5189 [EMAIL PROTECTED] KG6OMK __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ --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 ___ --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
Re: [Asterisk-Users] Nested MySQL Commands
On 11/01/06, Douglas Garstang [EMAIL PROTECTED] wrote: Peter, Too slow! We're going to potentially be doing several MySQL lookups for routing even the most basic of calls, and if every one of those queries has to make a call out to an AGI script, it would become a performance problem. I mean, an AGI to do the routing. A single call which does all the MySQLing it needs to do in a manner efficient for the environment it's written in, and makes all the call routing desicions as well. Peter -- Peter Bowyer Email: [EMAIL PROTECTED] Tel: +44 1296 768003 VoIP: sip:[EMAIL PROTECTED] VoIP: [EMAIL PROTECTED] FWD: **275*5048707000 VoipTalk: **473*5048707000 ___ --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
RE: [Asterisk-Users] Nested MySQL Commands
Peter, I assume you mean something like this in extensions.conf: exten = _X.,1,AGI(master-dial-logic.pl) and then there's only one call. All logic would be performed by the perl script. This has many advantages. One disadvantage however is that potentially, there could be 120 simultaneous instances of this script running (one per call). Douglas. -Original Message- From: Peter Bowyer [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 1:36 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] Nested MySQL Commands On 11/01/06, Douglas Garstang [EMAIL PROTECTED] wrote: Peter, Too slow! We're going to potentially be doing several MySQL lookups for routing even the most basic of calls, and if every one of those queries has to make a call out to an AGI script, it would become a performance problem. I mean, an AGI to do the routing. A single call which does all the MySQLing it needs to do in a manner efficient for the environment it's written in, and makes all the call routing desicions as well. Peter -- Peter Bowyer Email: [EMAIL PROTECTED] Tel: +44 1296 768003 VoIP: sip:[EMAIL PROTECTED] VoIP: [EMAIL PROTECTED] FWD: **275*5048707000 VoipTalk: **473*5048707000 ___ --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 ___ --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
Re: [Asterisk-Users] Nested MySQL Commands
Douglas Garstang wrote: Peter, I assume you mean something like this in extensions.conf: exten = _X.,1,AGI(master-dial-logic.pl) and then there's only one call. All logic would be performed by the perl script. This has many advantages. One disadvantage however is that potentially, there could be 120 simultaneous instances of this script running (one per call). Yes, but if you need it to scale efficiently, each of these could be a very lightweight process. If you used each of these to communicate via RPC or shared memory to a process with a small and configurable pool of database connections (which isn't that difficult), you can build a simple and scalable solution. jd -- John Daragon [EMAIL PROTECTED] argv[0] limited (Asterisk implementation consultancy) Lambs Lawn Cottage, Staple Fitzpaine, Taunton, TA3 5SL, UK v +44 (0) 1460 234068 f +44 (0) 1460 234069 m +44 (0) 7836 576127 ___ --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
RE: [Asterisk-Users] Nested MySQL Commands
jd but. but Asterisk still fires up a process each time you make an AGI call in the dialplan. You could still have 120 of these lightweight processes running, in _addition_ to the other process. Doesn't sound like it provides much benefit. -Original Message- From: John Daragon [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 2:14 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] Nested MySQL Commands Douglas Garstang wrote: Peter, I assume you mean something like this in extensions.conf: exten = _X.,1,AGI(master-dial-logic.pl) and then there's only one call. All logic would be performed by the perl script. This has many advantages. One disadvantage however is that potentially, there could be 120 simultaneous instances of this script running (one per call). Yes, but if you need it to scale efficiently, each of these could be a very lightweight process. If you used each of these to communicate via RPC or shared memory to a process with a small and configurable pool of database connections (which isn't that difficult), you can build a simple and scalable solution. jd -- John Daragon [EMAIL PROTECTED] argv[0] limited (Asterisk implementation consultancy) Lambs Lawn Cottage, Staple Fitzpaine, Taunton, TA3 5SL, UK v +44 (0) 1460 234068 f +44 (0) 1460 234069 m +44 (0) 7836 576127 ___ --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 ___ --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
Re: [Asterisk-Users] Nested MySQL Commands
Douglas Garstang wrote: jd but. but Asterisk still fires up a process each time you make an AGI call in the dialplan. You could still have 120 of these lightweight processes running, in _addition_ to the other process. Doesn't sound like it provides much benefit. True. But Linux is *good* at processes. The code is likely to be in RAM (provided you use a compiled language), And most databases are *bad* (relatively) at new connections, and at large numbers of connections. By keeping connection numbers low, keeping them open, and keeping the number of actual database calls to the minimum I'd be pretty confident of a scalable solution. Remember that these processes will spend most of their lives sleeping. Sure, there'll be more linked-list traversal c, but that's what an OS is for. I'm going to be building just such a beast over the next couple of weeks (for a similar sort of application), perhaps I'll do some performance estimation up front and post it. jd -Original Message- From: John Daragon [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 2:14 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] Nested MySQL Commands Douglas Garstang wrote: Peter, I assume you mean something like this in extensions.conf: exten = _X.,1,AGI(master-dial-logic.pl) and then there's only one call. All logic would be performed by the perl script. This has many advantages. One disadvantage however is that potentially, there could be 120 simultaneous instances of this script running (one per call). Yes, but if you need it to scale efficiently, each of these could be a very lightweight process. If you used each of these to communicate via RPC or shared memory to a process with a small and configurable pool of database connections (which isn't that difficult), you can build a simple and scalable solution. jd -- John Daragon [EMAIL PROTECTED] argv[0] limited (Asterisk implementation consultancy) Lambs Lawn Cottage, Staple Fitzpaine, Taunton, TA3 5SL, UK v +44 (0) 1460 234068 f +44 (0) 1460 234069 m +44 (0) 7836 576127 ___ --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
Re: [Asterisk-Users] Nested MySQL Commands
Under Linux (and other OSes) It's not as bad as that. Even with 128 Perl processes running there is only one copy of the Perl interpeter in memory. Each of the 128 running processes would have it's own copy of only it's data segments. With Perl already in memory the biggest system overhead would be process creation. The best design is the one that minimizes the number of process that the kernel has to create. Notice that this is why the Apache Perl modual is so much faster than using Perl from a CGI script Perl connecting to a central DBMS server is already the model you describe: 128 light weight procees connected to one big process which is the DBMS server. Performance gains will come from writting the SQL so that there is only one transaction and using indexes on the right columns in the database. If you really do have 128 process runing and each one needs to access a DBMS server, I'd say you are going to need a very powerful DBMS system but likly the call volume is not neraly like that --- John Daragon [EMAIL PROTECTED] wrote: Douglas Garstang wrote: Peter, I assume you mean something like this in extensions.conf: exten = _X.,1,AGI(master-dial-logic.pl) and then there's only one call. All logic would be performed by the perl script. This has many advantages. One disadvantage however is that potentially, there could be 120 simultaneous instances of this script running (one per call). Yes, but if you need it to scale efficiently, each of these could be a very lightweight process. If you used each of these to communicate via RPC or shared memory to a process with a small and configurable pool of database connections (which isn't that difficult), you can build a simple and scalable solution. jd -- John Daragon [EMAIL PROTECTED] argv[0] limited (Asterisk implementation consultancy) Lambs Lawn Cottage, Staple Fitzpaine, Taunton, TA3 5SL, UK v +44 (0) 1460 234068 f +44 (0) 1460 234069 m +44 (0) 7836 576127 ___ --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 Chris Albertson Home: 310-376-1029 [EMAIL PROTECTED] Cell: 310-990-7550 Office: 310-336-5189 [EMAIL PROTECTED] KG6OMK __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ --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
Re: [Asterisk-Users] Nested MySQL Commands
Douglas Garstang wrote: jd but. but Asterisk still fires up a process each time you make an AGI call in the dialplan. You could still have 120 of these lightweight processes running, in _addition_ to the other process. Doesn't sound like it provides much benefit. Or, you could have the dialplan pass control to app_access_the_database and have that do the data manipulation, populating dial plan variables for processing as usual (or, I guess, performing the routing itself). No process overhead. I'd still be inclined to use a pool of running, connected database processes/threads to handle the actual queries. jd -- John Daragon [EMAIL PROTECTED] argv[0] limited (Asterisk implementation consultancy) Lambs Lawn Cottage, Staple Fitzpaine, Taunton, TA3 5SL, UK v +44 (0) 1460 234068 f +44 (0) 1460 234069 m +44 (0) 7836 576127 ___ --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
RE: [Asterisk-Users] Nested MySQL Commands
I wouldn't know where to begin to look to research how to write a new Asterisk application command. We're not all C programmers. For now, my AGI script is in perl. -Original Message- From: John Daragon [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 3:02 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Cc: Douglas Garstang Subject: Re: [Asterisk-Users] Nested MySQL Commands Douglas Garstang wrote: jd but. but Asterisk still fires up a process each time you make an AGI call in the dialplan. You could still have 120 of these lightweight processes running, in _addition_ to the other process. Doesn't sound like it provides much benefit. Or, you could have the dialplan pass control to app_access_the_database and have that do the data manipulation, populating dial plan variables for processing as usual (or, I guess, performing the routing itself). No process overhead. I'd still be inclined to use a pool of running, connected database processes/threads to handle the actual queries. jd -- John Daragon [EMAIL PROTECTED] argv[0] limited (Asterisk implementation consultancy) Lambs Lawn Cottage, Staple Fitzpaine, Taunton, TA3 5SL, UK v +44 (0) 1460 234068 f +44 (0) 1460 234069 m +44 (0) 7836 576127 ___ --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
Re: [Asterisk-Users] Nested MySQL Commands
Chris Albertson wrote: Under Linux (and other OSes) It's not as bad as that. Even with 128 Perl processes running there is only one copy of the Perl interpeter in memory. Each of the 128 running processes would have it's own copy of only it's data segments. With Perl already in memory the biggest system overhead would be process creation. The best design is the one that minimizes the number of process that the kernel has to create. Notice that this is why the Apache Perl modual is so much faster than using Perl from a CGI script You will get the best usage of shared pages if all child interpreted processes fork off of one parent process. That way they can share as many data pages as possible also. If they don't fork off of each other, then a new copy of the interpreter will be put into memory. There will be some shared CoW pages between them, but not nearly as many when compared forking off of a common pool of processes. ___ --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
RE: [Asterisk-Users] Nested MySQL Commands
We have no control over this. Asterisk is the one that starts the new process upon a call to AGI in extensions.conf... -Original Message- From: Mike Fedyk [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 3:27 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Cc: [EMAIL PROTECTED] Subject: Re: [Asterisk-Users] Nested MySQL Commands Chris Albertson wrote: Under Linux (and other OSes) It's not as bad as that. Even with 128 Perl processes running there is only one copy of the Perl interpeter in memory. Each of the 128 running processes would have it's own copy of only it's data segments. With Perl already in memory the biggest system overhead would be process creation. The best design is the one that minimizes the number of process that the kernel has to create. Notice that this is why the Apache Perl modual is so much faster than using Perl from a CGI script You will get the best usage of shared pages if all child interpreted processes fork off of one parent process. That way they can share as many data pages as possible also. If they don't fork off of each other, then a new copy of the interpreter will be put into memory. There will be some shared CoW pages between them, but not nearly as many when compared forking off of a common pool of processes. ___ --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 ___ --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
RE: [Asterisk-Users] Nested MySQL Commands
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. -Original Message- From: Mike Fedyk [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 3:27 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Cc: [EMAIL PROTECTED] Subject: Re: [Asterisk-Users] Nested MySQL Commands Chris Albertson wrote: Under Linux (and other OSes) It's not as bad as that. Even with 128 Perl processes running there is only one copy of the Perl interpeter in memory. Each of the 128 running processes would have it's own copy of only it's data segments. With Perl already in memory the biggest system overhead would be process creation. The best design is the one that minimizes the number of process that the kernel has to create. Notice that this is why the Apache Perl modual is so much faster than using Perl from a CGI script You will get the best usage of shared pages if all child interpreted processes fork off of one parent process. That way they can share as many data pages as possible also. If they don't fork off of each other, then a new copy of the interpreter will be put into memory. There will be some shared CoW pages between them, but not nearly as many when compared forking off of a common pool of processes. ___ --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 ___ --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
Re: [Asterisk-Users] Nested MySQL Commands
The most expensive part about perl is the init time. So you either want to find out how many calls per minute or most likely want FastAGI which eliminates this problem entirely. I wonder if FastAGI handles process pools, or if the FastAGIs need to handle sub-processes or threading. Douglas Garstang wrote: 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. -Original Message- From: Mike Fedyk [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 3:27 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Cc: [EMAIL PROTECTED] Subject: Re: [Asterisk-Users] Nested MySQL Commands Chris Albertson wrote: Under Linux (and other OSes) It's not as bad as that. Even with 128 Perl processes running there is only one copy of the Perl interpeter in memory. Each of the 128 running processes would have it's own copy of only it's data segments. With Perl already in memory the biggest system overhead would be process creation. The best design is the one that minimizes the number of process that the kernel has to create. Notice that this is why the Apache Perl modual is so much faster than using Perl from a CGI script You will get the best usage of shared pages if all child interpreted processes fork off of one parent process. That way they can share as many data pages as possible also. If they don't fork off of each other, then a new copy of the interpreter will be put into memory. There will be some shared CoW pages between them, but not nearly as many when compared forking off of a common pool of processes. ___ --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 ___ --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 ___ --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
Re: [Asterisk-Users] Nested MySQL Commands
Douglas Garstang wrote: 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. Why don't you use FastAGI? Run the lookup 'script' as a standalone application communicating with Asterisk through sockets. Once you're decoupled from the process forking model, you can implement all those nifty thread, connection pooling tricks. You'll probably need to use stored procedures on the SQL side. You should also do some traffic modeling to optimize the resource planning. I don't really think you need 120 threads to handle the load. In traditional PBX, when using host-based routing (or so-called adjunct routing) you get a grace period of about 4 seconds to route the call. Time to dig out the erlang-c calculator :). ___ --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
RE: [Asterisk-Users] Nested MySQL Commands
Well, is Perl DBI thread-safe for a start??? -Original Message- From: Leo Ann Boon [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 11, 2006 5:32 PM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: Re: [Asterisk-Users] Nested MySQL Commands Douglas Garstang wrote: 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. Why don't you use FastAGI? Run the lookup 'script' as a standalone application communicating with Asterisk through sockets. Once you're decoupled from the process forking model, you can implement all those nifty thread, connection pooling tricks. You'll probably need to use stored procedures on the SQL side. You should also do some traffic modeling to optimize the resource planning. I don't really think you need 120 threads to handle the load. In traditional PBX, when using host-based routing (or so-called adjunct routing) you get a grace period of about 4 seconds to route the call. Time to dig out the erlang-c calculator :). ___ --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 ___ --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
