[asterisk-users] Scaling Asterisk: Dual-Core CPUs not yieldinggains at high call volumes

Douglas Garstang DGarstang at interainc.com
Fri Jun 1 09:31:38 MST 2007


I previously worked for a company that did some heavy load testing with
Asterisk on multiple core Sun systems. We saw that no matter how many
cores you threw at Asterisk, it always used ONE core to process calls,
even at very high loads.

-----Original Message-----
From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Matthew J.
Roth
Sent: Friday, June 01, 2007 9:07 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] Scaling Asterisk: Dual-Core CPUs not
yieldinggains at high call volumes

John Hughes wrote:
> OpenSSI can't (at the moment) migrate threads between compute nodes.
It
> can migrate separate processes, but doesn't Asterisk use threads?
John,

Asterisk uses 1 thread per call, plus about 10 to 15 background threads 
that persist throughout the life of the process.

I'm curious if the 1 thread per call model is efficient as the number of

calls increases.  It's possible that in the 100+ call range that there 
is a significant overhead to managing all of those threads without much 
gain since most servers have 1 to 8 processors to actually schedule them

on.  Acquiring locks on shared resources between the threads could be 
pretty nasty at that point, too.

I wonder if pooling the calls in X threads, where X is a value that is 
determined at compile time by looking at the number of processors 
available, would be more efficient?  This is probably just an academic 
question, because I'd imagine it would require an overhaul of the 
codebase to accomplish.

Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer

_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


More information about the asterisk-users mailing list