(no subject)
Nov. 26th, 2012 10:18 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
torkellOh dear, I seem to be performance testing my test environment, and it's losing to the actual software being tested. This is not particularly helpful.
(also unhelpful was finding that one server I was using had a mere 512MB of RAM... and one proxy I tried ate through all of it in a matter of seconds)
The rough setup is source -> proxy -> SIP server -> proxy -> sink. Normally that's a reasonable layout, except for this test the proxy on each side is actually the same. This means that it's got to cope with double the load of the SIP server that I'm actually testing, and judging by the errors the proxy is spamming at me I don't think it is. One of them might cope if I can work out how to turn off the insane debug spam (turning its debug level down from 3 to 0 had no affect).
That said, I'm in the same situation I was in last week in that what happens to the call outside of my program is not that relevant to the test, and so mangling the test environment is fair game as long as whatever mangled behaviour it produces can be fully explained. I wonder if I can fudge the routing such that I can use different proxies, or even better bypass them entirely as I know the source and sink are fast enough...
(also unhelpful was finding that one server I was using had a mere 512MB of RAM... and one proxy I tried ate through all of it in a matter of seconds)
The rough setup is source -> proxy -> SIP server -> proxy -> sink. Normally that's a reasonable layout, except for this test the proxy on each side is actually the same. This means that it's got to cope with double the load of the SIP server that I'm actually testing, and judging by the errors the proxy is spamming at me I don't think it is. One of them might cope if I can work out how to turn off the insane debug spam (turning its debug level down from 3 to 0 had no affect).
That said, I'm in the same situation I was in last week in that what happens to the call outside of my program is not that relevant to the test, and so mangling the test environment is fair game as long as whatever mangled behaviour it produces can be fully explained. I wonder if I can fudge the routing such that I can use different proxies, or even better bypass them entirely as I know the source and sink are fast enough...
