provided by Star2Billing S.L.

Reposting to a more appropriate topic:

I have a x86_64 version of CentOS, 4GB, Intel 2.3Ghz Dual core Xeon.

I get roughly 240 concurrent calls (as expected) when making outbound calls without A2Billing. My setup is sipp generating calls to the Asterisk-under-test, which initiates calls over a SIP trunk to another Asterisk which only answers and does Playback(). No transcoding is done. The CPU in this case reaches only about 20%, and less than 1/2 of the memory is used (according to top).

When the same scenario is run using A2Billing on that Asterisk, everything else being identical, there seems to be an upper bounds max of 100-105 calls that can be simultaneously created. Then I see Asterisk sending "unexpected messages" to SIPp (according to SIPp they're unexpected. THe best I can tell is that they are BYE messages sent from the Asterisk-under-test. I have no idea what is prompting them to be sent... Sipp is supposed to terminate the call, and successfully does in about 2/3 of the calls in this scenario). The Asterisk-under-test box is only running at about 30% CPU, slightly under 1/2 memory free, with no swapping.

Does anyone have any more information, know what's limiting this or the reason that this happens only with A2Billing in the middle and not without?

I'm running asterisk 1.6beta7.1.

THanks,

Nathan

Added after 38 minutes:

A few more things I tried:

- 2 seperate instances of sipp, each calling as a different customer, each making 75 concurrent calls at a low cps, and still 99 active calls is all the more I am allowed to set up before the Asterisk-under-test starts sending BYEs

- I even took that one step further and sent customer #1's calls over a SIP trunk to another Asterisk, and sent customer #2's calls over an IAX trunk to another Asterisk, to see if the problem was one involving A2Billing and trunks. Same 99-105 limits.

Other ideas/thoughts?

Nathan

due to AGI ?

pls try to test on asterisk without a2b but via AGI, what is result ?

Clearly folks don't actually *read* the posts.

I quote:
"I get roughly 240 concurrent calls (as expected) when making outbound calls without A2Billing."

Which means:
When I have a dialplan of:
exten => 9999,1,Dial(SIP/SIP_Trunk_To_Other_Asterisk/${EXTEN})

I get roughly 240 concurrent calls.

When I have a dialplan of:
exten => 5555,1,Answer
... blah blah
exten => AGI(a2billing.php)
...

Something is limiting me to 100 concurrent calls.

Next someone will tell me perhaps it's a hardware limitation.

Interesting analysis. Is this a real world problem or achedemic testing? I have very busy servers, but I'm not getting anywhere near 100 calls on 1 server. Still, A2B is PHP based. It could be that you need to allocate more memory to the processes in PHP. That may well be your limitation.

PHP4 needs to be recompiled to change the value, PHP 5 can be set from the php.ini file

That said, you are running a Beta of asterisk. There may be some bug in the current AGI module. Have you tested with 1.4?

But you're right, you probably need more horse power (Just Kidding)

Regards

Hi!

So, it's in a controlled lab environment so I know what to expect as an upper bounds in a production environment.

It should, however, mimic the behavior in a production environment for this machine, because in this case, the behavior of each SIP endpoint will be identical, and not subject to variations in codecs, recording, etc.

I will try your suggestions... thanks.

---------------
NOTES:
- I've attempted the following tests, and STILL max out at 99 calls before Asterisk-under-test sends BYEs.

1) Turn off all CDR recording (still using A2Billing). Nothing is being written to DB or to the CSV files
2) Send 1/2 the calls to a completely seperate Asterisk machine for Playback(). No longer just a seperate trunk
3) Increased the memory to PHP as you've suggested in the php.ini
4) Used version 1.4.19

no luck.

This is all interesting stuff.

I wonder if you reduce the memory by half (if you can do this easily) whether the number of concurrent calls reduces.

If the number of concurrent calls does not reduce, then that would suggest that the limitation lies in the software somewhere, as you currently suspect, because so far, it would appear that you are not stressing your hardware, this may give us some clues of where and how to optimise.

Joe

So I've updated some of the tests I've run... no luck.

At this point, I simply believe it must be related the A2Billing software somewhere, the number of files that are allowed to be concurrently open, or something...

Anyone with other ideas?

You don't mention whether you are using MySQL or PostgreSQL.

I wonder if this makes a difference?

Joe

I'm not too sure it's a2b per say, but perhaps an asterisk restriction when calling an agi script.

The reason I say this is because on Saturday I was watching one of my servers that was under heavy load. All of a sudden I say all new calls failing. What I saw was the inbound connection but asterisk was not executing the AGI script to call A2B. What would be useful is to see what happens if you call a simple PHP script and then connect the call back in asterisk. This wil determine if it's AGI related.

Regards

MySQL, but it shouldn't matter, because I tested with CDRs off as well.

Hi

There are still queries going on to check your balance etc.

If the total concurrent calls is not dependent on memory and processor (within reason), which we suspect may be the case (removing half the memory, may help prove this), then the issue probably has to lie in:-

The Databse query
PHP
The Asterisk AGI.

So changing the database for something else may give markedly different results. If so, then we know that we have to work on optimising the database.

If there is no change, then we are probably left the with Asterisk AGI or PHP

Joe
,

I ran the test with an AGI script that does very little and sends the call back to the dialplan. I can get 200+ calls. So either this isn't a good AGI comparison, or it's in the actual A2B.

Perhaps someone knows of a better AGI Script? Not being the AGI expert, can someone write me a code-segment (I don't need the whole script) that makes the call to SIP/SIP_Home/9999 through the AGI script?

Nathan

May I ask a couple of things:
1. Is there a "hard" number of maximum calls: i.e. can you see always the 101th or 129th call failing, or is it /around/ 100 that they fail?
(ok answered)

2. Can you see anything in verbose/debug logs when calls fail?
3. What is the CPU/memory usage at that time? Does that happen when you switch off the swap, perhaps?
(that too..)

4. What is the number of asterisk channels (core show channels) when calls limit?

Edit: I read the first post again.

1. There *seems* to be a hard limit. When I look at the Asterisk on the other side of the trunk (which does Playback() only), it only ever has 99 active channels/calls via show channels. Keep in mind, there are calls constantly being created and torn down, so it fluctuates a little, but only on the Asterisk-under-test side... between 98-105, but again, that might just be beacuse some are in various stages of being torn down or not yet created. So as one is legitimately torn down, another one succeeds.

2. Nothing in the logs. I've even turned on sip debugs, but they show little except that a BYE is sent from the Asterisk-under-test when it should not. The test tool (sipp) is supposed to be the endpoint ending the call, and this is what happens for the calls that succeed.

3. At the peak time, when ~100 calls are up, and some calls pass (as old calls are appropriately torn down) and some calls fail, the CPU is about 30%. Memory is about 1.6GB free (out of 4GB total). No swapping is done.

4. show channels for the Asterisk-under-test is about 98-105, and for the Asterisk on the other side of the trunk, show channels never goes above 99. When I make the calls use 2 trunks to 2 different Asterisks to play audio, the sum of the active channels on the 2 asterisks is again never more than 99.

Hmm, this is becoming an interesting thread.

OK, how about modifying asterisk.conf

This is what I have in mine.

Try changing max calls to 50. Do you get byes? In other words is the behavour similar?

[options]
maxload = 0.9 ; The maximum load average we accept calls for
maxcalls = 140 ; The maximum number of concurrent calls you want
; to allow
dontwarn = yes
timestamp = yes

Added after 24 minutes:

Just been chatting with Areski, there's no hard coded limit to the number of calls. His suggestion was to look at http://lists.digium.com/pipermail/asterisk-dev/2006-October/024091.html

REgards