bottle neck discovery!!

[bobbymc]

Not sure if this was fixed in 2.0.3 or higher.. currently im usiong the AST_manager_send.pl from 2.0.1..

So i pushed my box to make 600 calls at once.. asterisk works without a charm.. no issues but the problem i found out was that AST_manager_send.pl was so busy taking requests from the manager table to make these calls that it started to lag on the hangup requests and due to this everytime i pressed hangup it would take 10-20 secodns to proccess this.. sometimes even longer.. so what i did is copy the scritp and ran it for only the action="hangup" processes and this issue was solved.. any idea why this fixed it and is this a fix or what can i have done wrong to cause this issue in the first place?

[mflorell]

What kind of system are you running this on?

What kind of calling are you doing?

There is a limitation built in to the sending script for sending actions per server at 10 per second in the 2.0.4 and earlier codebase which has been raised to 20 per second in the SVN trunk codebase.

You mention that Asterisk had no problems, but was there a lag in Manager request responses?

What was the loadavg on the server?

[bobbymc]

what happend is that the server was trying to make 400 calls with a 12 second dial timeout.. the issue happend that while it was looping throuhg the QUEUE proccesses in vicidial_manager.. the script started to cause latency on when it got to the hangup commands.. so this is what happend..

$00 calls are made.. or its making sure its always having 400 calls it makes.. i get a few calls and i press hangup.. the command was send tot he database but the scritp did not execute it in time and i got the next call comming in..

I made the AST_manager_send into send and hangup.. so the send only does the QUEUE for generating new calls and the hangup only handels hangups.. after i did this i was able to push over 700 calls on a dell dual cpu quad core 2.3 gighz with 8 gigs of ram.. load avrage belive it or not was 1.1 1.0..

Now consider i was the only one in the meetme room.. but using ulaw and no g729 helped out a bit.. not sure how muhc more the conf rooms will use when i put the rest 30-40 agents in.. that will happen monday when i run the test with that many people.. i let you know what the resutls are but i really suggest you split the hangup actions and redirect actions into 2 seperate scritps..

[mflorell]

I believe your bottleneck is just the timeout that is in the script and if you lowered that(cut it in half) you would achieve the same effect as separating the scripts.

[rishuk]

Hi,

Please let us know how you do it, where you make changes.can you post the script?

Not sure if this was fixed in 2.0.3 or higher.. currently im usiong the AST_manager_send.pl from 2.0.1..

So i pushed my box to make 600 calls at once.. asterisk works without a charm.. no issues but the problem i found out was that AST_manager_send.pl was so busy taking requests from the manager table to make these calls that it started to lag on the hangup requests and due to this everytime i pressed hangup it would take 10-20 secodns to proccess this.. sometimes even longer.. so what i did is copy the scritp and ran it for only the action="hangup" processes and this issue was solved.. any idea why this fixed it and is this a fix or what can i have done wrong to cause this issue in the first place?

[bobbymc]

i even did that and still the hangups are half a second slower.. i really suggest we take scritp to dedicate them to originate calls redirect hangup etc.. all theos should have their own deamon running

[mflorell]

I disagree, I have done over 1000 concurrent calls running the SVN trunk codebase on a single machine and I have not had the issues you mention.

[mflorell]

What numbers are you using for the interval delays in the manager send script?

[Op3r]

concurrent means simultaneous right?

I believe even a2billing can only make 200 simultaneous calls per asterisk box.

Or if I got it wrong, Ill shut up now.

Or try using SER to push your calls.

[bobbymc]

What kind of system are you running this on?

What kind of calling are you doing?

There is a limitation built in to the sending script for sending actions per server at 10 per second in the 2.0.4 and earlier codebase which has been raised to 20 per second in the SVN trunk codebase.

You mention that Asterisk had no problems, but was there a lag in Manager request responses?

What was the loadavg on the server?

you mean change

Code: Select all


                if ($affected_rows) {
                        ### sleep for 1 hundredth of a second if just send an ACTION
                        usleep(1*10*1000);
                } else {
                        ### sleep for 10 hundredths of a second if no actions sent
                        usleep(1*100*1000);
                }


to

Code: Select all


                if ($affected_rows) {
                        ### sleep for 1 hundredth of a second if just send an ACTION
                        usleep(1*5*1000);
                } else {
                        ### sleep for 10 hundredths of a second if no actions sent
                        usleep(1*50*1000);
                }