Also, with the default settings most boxes collapse at just over a 1000 concurrent due to php limits, memcached previously etc.
Well, the immediate thing that comes to mind is CDRs, these are http posts to the webserver.
"php limits" This is not a big factor on scalability. The HTTP Post to the web server uses PHP for XML CDR. You can skip the HTTP Post and use a cron job and still use XML CDR just without the HTTP Post. PHP is not a major deciding factor on scale.
What affects performance the most is actually how much the person configuring the server picks the right hardware and understand the software and all dependencies to configure their settings for the best performance. There is also things like is the server virtualized, and how good is the network routers, switches, and connection to the internet.
I had a company that hired me to come in person. I was there for 3 days. Most of the time I was there was spent optimizing many different things. Could have been optimizing things for weeks. We didn't have that kind of time I was helping them for only 3 days. However in the end they saw a dramatic improvement in performance. Point I'm trying to make is that it wasn't a few settings to get a big performance increase. It was many settings and optimizations.
@markjcraneWe are talking FreeSWITCH speed here...Using the file cache method, the dialplan is only pulled from the database when there are not dialplan xml files present on the file system. Go look in the file cache directory on your server. You'll see a bunch xml files there. Clear cache then look again. The directory should be empty. Make a call and the directory will have files in it again. To make this happen, the dialpan was pulled from postgres and then written to the files on your server. If the xml files exist already, then postgres isn't touched.
www_authorize("","subscriber");
switch ($retcode) {
case -3: # stale nonce
case -2: # invalid passwd
case -1: # no such user
xlog("Failed Auth\n");
if ( cache_fetch("local","authF_$si",$avp(failed_no)) ) {
if ( $(avp(failed_no){s.int}) >= 20 ) {
xlog("SCRIPT: SECURITY ALERT: 20 failed auth from $si\n");
send_reply("403","Forbidden");
exit;
}
cache_add("local","authF_$si",1,60);
} else {
cache_store("local","authF_$si","1",60);
}
default:
xlog("Challenging\n");
www_challenge("", "0");
exit;
break;
}
I have thought for some time now that the use of opensips/kamailio in front of fusionpbx may well be really worth while.I think there are a number of ways within these packages to sanitise the sip before it hits fusionpbx.
I've never decided upon the approach properly though. Do you just relay through the kamailio everything to the fusionpbx or really try and integrate it. The second method would be better performance wise, if kamailio could handle much of the presence and registrar functions etc.
The easiest way is to just use it as a proxy. What most integrations appear to do, is use it for presence/registrar. But it increases complexity considerably so it is usually not worthwhile to try do it yourself.