performance testing
performance testing
have you done some performance testing for the local version like how many concurrent calls , memory usage ?
Nope. And there's a memory leak in the IronRuby assembly that slowly leaks memory and will require a periodic restart on any long running process.
The mysipswitch.com service which is the same code as the local version (the only difference is if you're using XML files instead of an SQL database) has been hit with 30 to 40 calls per second when a few users have looped calls between it and Voxalot.
The SIP Application server on mysipswitch.com needs to be restarted every 24 hours at the current usage levels. After 24 hours the memory utilisation is between 150MB and 400MB.
All the other server agents are fine since they don't use the IronRuby assembly. Currently on mysipswitch.com all the agents below have been up for a couple of weeks.
Monitor 31MB
Stateless Proxy 46 MB
3rd Party Registration Agent 142 MB (4885 registered contacts)
Registrar 63 MB (550 bindings)
Application Server 125MB (restarted 8 hours ago)
You can also get a pretty good idea of the traffic levels generating those utilisations from:
http://www.mysipswitch.com/realtimemonitoring.aspx
On my local version which includes all the above agents except the Stateless proxy the current memory usage is 45MB and CPU is 0% but it's only maintaining 1 3rd party registration and 1 binding.
Regards,
Aaron
The mysipswitch.com service which is the same code as the local version (the only difference is if you're using XML files instead of an SQL database) has been hit with 30 to 40 calls per second when a few users have looped calls between it and Voxalot.
The SIP Application server on mysipswitch.com needs to be restarted every 24 hours at the current usage levels. After 24 hours the memory utilisation is between 150MB and 400MB.
All the other server agents are fine since they don't use the IronRuby assembly. Currently on mysipswitch.com all the agents below have been up for a couple of weeks.
Monitor 31MB
Stateless Proxy 46 MB
3rd Party Registration Agent 142 MB (4885 registered contacts)
Registrar 63 MB (550 bindings)
Application Server 125MB (restarted 8 hours ago)
You can also get a pretty good idea of the traffic levels generating those utilisations from:
http://www.mysipswitch.com/realtimemonitoring.aspx
On my local version which includes all the above agents except the Stateless proxy the current memory usage is 45MB and CPU is 0% but it's only maintaining 1 3rd party registration and 1 binding.
Regards,
Aaron
monitoring tools
where can we download the Blue Face's production monitoring tools ?
It's a fair question and one it took me three months to be sure on. The answer is that I am 99.99% sure the leak is in the IronRuby assembly. I did a lot of profiling and measuring on the mss SIP stack and did not find any leaks.asimkhan wrote:is it because of ironruby ?
or there is another memory leak in SIP application server ?
The problem did not occur before using Ruby dialplans and it also does not occur on any of the other 3 agents which all use the same SIP stack as the Application Server but without the IronRuby engine.
Bascially I am as sure as I can be without having found the code that is leaking the memory. I did look over the IronRuby code and found some suspicious looking blocks but since that assembly is under heavy development I decided that it would be best just to workaround it for the time being and didn't invest the time in an in depth investigation.
Regards,
Aaron
Re: monitoring tools
That you can't do. Blue Face have not open sourced them and I'm not at liberty to do that.asimkhan wrote:where can we download the Blue Face's production monitoring tools ?
Regards,
Aaron
Hi shkaff,
An instance of the mysipswitch should cause negligible system load on any modern system (anything less than 5 years old). The live version is running on a HP DL380 with dual opteron CPUs and 1GB RAM. That server is actually Blue Face's main web server and the mss function is something running in the background. Currently the 6 different mss agents are using a combined CPU of between 5 and 10%. You can get a rough idea of the load the service is under from this link http://www.mysipswitch.com/realtimemonitoring.aspx (there are currently 6491 3rd party registrations being maintained).
Because the mss doesn't deal with media the loads it can cope with should be very high compared to a typical soft PBX system like Asterisk. That being said the IronRuby engine used to process dialplans has caused some issues in the past and I wouldn't like to run an emergency call center off it at this point. Also there has been one report from jzwelen where he experienced 100% CPU spikes on his local mss instance. I am yet to experience this myself but since the software is still under heavy development it is possible there is a flaw somewhere.
Regards,
Aaron
An instance of the mysipswitch should cause negligible system load on any modern system (anything less than 5 years old). The live version is running on a HP DL380 with dual opteron CPUs and 1GB RAM. That server is actually Blue Face's main web server and the mss function is something running in the background. Currently the 6 different mss agents are using a combined CPU of between 5 and 10%. You can get a rough idea of the load the service is under from this link http://www.mysipswitch.com/realtimemonitoring.aspx (there are currently 6491 3rd party registrations being maintained).
Because the mss doesn't deal with media the loads it can cope with should be very high compared to a typical soft PBX system like Asterisk. That being said the IronRuby engine used to process dialplans has caused some issues in the past and I wouldn't like to run an emergency call center off it at this point. Also there has been one report from jzwelen where he experienced 100% CPU spikes on his local mss instance. I am yet to experience this myself but since the software is still under heavy development it is possible there is a flaw somewhere.
Regards,
Aaron