Dear sirs,
searching on the web and in old ML threads about the suggested number of TCP and UDP workers, I just found:
- for TCP children (i.e., TCP receivers, isn't it?) "As a rule of thumb, (maximum simultaneous connections)/2000 should be OK" (from doc/tcp_tunning.txt)
- In general for workers (from a past thread by Henning Westerholt): "In my experience the number of children is not that important for performance, you may just choose the default size of 8."
In the last post there was, moreover, a suggestion that the number of children should be chosen with respect to RAM and CPU cores (that makes sense to me).
The only thing I can think about the rule of thumb above comes from the possibility that a number of processes may be unavailable in blocking operations. So my question is:
- with asynchronous TCP/TLS is it safe to assume that more children than CPU cores are more or less useless? - are there other blocking operations for which the number of UDP/TCP children should be incremented above the CPU cores number?
Thank you!
Best regards, Francesco Castellano
Hello,
On 8/3/11 6:28 PM, Francesco Castellano wrote:
Dear sirs,
searching on the web and in old ML threads about the suggested number of TCP and UDP workers, I just found:
- for TCP children (i.e., TCP receivers, isn't it?)
"As a rule of thumb, (maximum simultaneous connections)/2000 should be OK" (from doc/tcp_tunning.txt)
- In general for workers (from a past thread by Henning Westerholt):
"In my experience the number of children is not that important for performance, you may just choose the default size of 8."
In the last post there was, moreover, a suggestion that the number of children should be chosen with respect to RAM and CPU cores (that makes sense to me).
The only thing I can think about the rule of thumb above comes from the possibility that a number of processes may be unavailable in blocking operations. So my question is:
- with asynchronous TCP/TLS is it safe to assume that more children
than CPU cores are more or less useless?
No, unless you have a lot of cores. There is a lot of I/O with the networking, database a.s.o. The number of children is a matter of traffic and the time consuming operations you do (db lookups, dns).
- are there other blocking operations for which the number of UDP/TCP
children should be incremented above the CPU cores number?
No matter the number of cores, in production I start from 8 children and don't go more than 32. After this value, either the config is too blocking or the traffic is too high and it is time for new hardware. I am talking about usual server hardware, not supercomputers.
Cheers, Daniel
Daniel,
thank you very much.
May I ask you another question? We used to re-compile the production proxy with a high value (32 MB) of PKG_SIZE, for older versions of the MySQL db module didn't provide fetch_result() capability. But now, apart from start up loading issues, are there any other reason to keep the PKG_SIZE above the 4MB default?
Thank you,
Best regards, Francesco
On Fri, Aug 5, 2011 at 6:02 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 8/3/11 6:28 PM, Francesco Castellano wrote:
Dear sirs,
searching on the web and in old ML threads about the suggested number of TCP and UDP workers, I just found:
- for TCP children (i.e., TCP receivers, isn't it?)
"As a rule of thumb, (maximum simultaneous connections)/2000 should be OK" (from doc/tcp_tunning.txt)
- In general for workers (from a past thread by Henning Westerholt):
"In my experience the number of children is not that important for performance, you may just choose the default size of 8."
In the last post there was, moreover, a suggestion that the number of children should be chosen with respect to RAM and CPU cores (that makes sense to me).
The only thing I can think about the rule of thumb above comes from the possibility that a number of processes may be unavailable in blocking operations. So my question is:
- with asynchronous TCP/TLS is it safe to assume that more children
than CPU cores are more or less useless?
No, unless you have a lot of cores. There is a lot of I/O with the networking, database a.s.o. The number of children is a matter of traffic and the time consuming operations you do (db lookups, dns).
- are there other blocking operations for which the number of UDP/TCP
children should be incremented above the CPU cores number?
No matter the number of cores, in production I start from 8 children and don't go more than 32. After this value, either the config is too blocking or the traffic is too high and it is time for new hardware. I am talking about usual server hardware, not supercomputers.
Cheers, Daniel
-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda
-
Daniel-Constantin Mierla -
Francesco Castellano