Italo Dacosta wrote: >> Ok - that's the first problem. Number of children == number of >> processes. You cannot handle more than 4 messages at one time right >> now. >> > > I forgot to mention that I tested with several number of children > already. Surprisingly, increasing the number of processes seems to > reduce performance. With 8 children processes the maximum call rate I > measured was around 17,000 cps. I think that the performance is lower > due to the overheads associated with context switching. > Here there is a whole theory.
Starting first with the concept of parallel computation: ideally you assume an application has an 100% of parallelism (if you have a core, you get a performance of N, if you have X cores, you get a performance of X*N) - in reality, most of the application have a much lower degree of parallelism, mainly due shared data, access on common resources (sockets), synchronization between processes, etc . So, the first conclusion we can have is that, for an ideal application, it is enough to have to a number of procs equal with the number of cores you have on the machine. Now, second part is about the CPU computation ops via I/O blocking ops - the above conclusion is correct as time as the application is doing pure computation (no I/O). Once the app starts doing I/O, you have wait time in kernel, rescheduling - more or less "dead time" from your application point of view. In practice, this "dead time" can be compensated by a higher number of processes. For ex. while a process is blocked in doing some DB I/O, and blocking DNS query, etc, another process may use the CPU and do some non-I/O ops. So, the second conclusion is that you should increase the number of procs directly proportional with the degree of I/Os performed by your app. In your particular case, the I/O delay is low - you do not use DNS, no DB module, etc - only I/O is on the network sockets where the sharing of these sockets between the procs is done by kernel. Regards, Bogdan _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
