Optimize the system (linux / CentOS)
The first thing to do is to have an optimal OS configuration on wich we will run our apps. If the OS is not well configured, we can optimize our application as much as we want, we will not have optimal performance and it's why we will first focus on this part.
Optimize Kernel settings
Te kernel, by default, has fairly low limits on network, we will try to increase it a little.
Increase the backlog socket setting
The default setting for SOMAXCONN is 128 under CentOS as well as in most linux distribution. This setting determines the maximum number of listen() a socket can accept simultaneously. This limit is too low for exisiting server and can degrade the performance of your application if you have more simultaneous connection than this limit.
For those who say that this limit is dangerous because it can use too much memory, I would like to say that one listen, in a 64b server, use 160b in memory, with a limit of 8k, this will use only 1.25M in memory.
For the good value to be here, it will depend. Generally, a good limit is between 128 and 8192 (generally, I use a limit of 4096 on my project).
Allow the system to reuse sockect (optional)
One of the problems I have encountered is the huge number os connection in TIMEWAIT_. I have no magic solution to this. Under hard load, I still have a lot of them, but we can help the system to reuse its socket in end of life:
tcp_tw_reuse = 1 tcp_fin_timeout = 15 (in second)
By default, tcpfintimeout is 60s, this means that the kernel will wait 60 second before closing the socket if all applications already close it but we do not have a confirmation from the client.
Increase the limit of file descriptor
This is one of the most important points. On CentOS, the limit is 1024 file descriptor by application, by default. This is roughly the number of files that the application can have open at the same time, but since Linux, everything is a file, this includes the number of connection. This can be a major performance problem.
There are two way to change it: we can define it by user in the system level or for the current session. In my case, nodejs run with it user or nobody and I change the limit at the system level.
Increase the limit for the current session
ulimit -n 9999 node app.js
It's as simple as that!
Increase the limit for an user
vim /etc/security/limits.d/99-nobody #user soft/hard/all option value nobody - nofile 9999
Check the limit for the current process
If you want to check the limit for the current process, you must have its PID:
# ps ax | grep node PID [...] COMMAND 5699 [...] node app.js
Then we will check the limits of PID:
cat /proc/__PID__/limits Limit Soft Limit Hard Limit Units [...] Max open files 9999 9999 files
Et voilà! We have the limit set before in place.…