[asterisk-dev] Asterisk scalability (was: Improve scheduler performance under high load)

[Johansson Olle E]

16 feb 2009 kl. 02.38 skrev Russell Bryant:

> It appears that in this test environment, somewhere near N=100 and  
> below, the code in trunk will perform better.  However, at that  
> point, we're talking about very small fractions of a second.  As N  
> gets larger, the code in team/russell/heap clearly starts to perform  
> much better.
>
> With how the scheduler API is used today, a module such as chan_sip  
> or chan_iax2 could easily have a scheduler context with N in the  
> thousands.  Every registration will result in a scheduler entry.   
> Also, every active channel will result in at least one, if not more  
> scheduler entries.
>
> Given these results, I do believe that the changes have proven to be  
> beneficial overall.

I think this together with the changes done by murf in the area of  
hash tables will mean that we done some major work to build a new  
generation of Asterisk that scales better than the old versions on the  
current server architectures! Impressed!

Now, can anyone start a discussion on the way we handle threads? If we  
run on a quad-core or a system with dual quad core CPUs, we have  
capactiy for an enormous quantity of calls, with at least one thread  
per call. Can a modern Linux/Unix thread scheduler handle 10 000  
threads efficently?

Oh, I think I just started that discussion. Looking forward to your  
feedback!
/O