Config Nginx Tuning For Best Performance on vultr vps

This is config Nginx and make your nginx webserver more strong.

# you must <span class="hljs-keyword">set</span> worker processes based <span class="hljs-keyword">on</span> your CPU cores, nginx does <span class="hljs-keyword">not</span> benefit from setting more than that
worker_processes = auto; #some last versions calculate it automatically, thanks <span class="hljs-keyword">to</span> Diego :)

# number of file descriptors used <span class="hljs-keyword">for</span> nginx
# the limit <span class="hljs-keyword">for</span> the maximum FDs <span class="hljs-keyword">on</span> the <span class="hljs-built_in">server</span> <span class="hljs-keyword">is</span> usually <span class="hljs-keyword">set</span> by the OS.
# <span class="hljs-keyword">if</span> you don<span class="hljs-comment">'t set FD's then OS settings will be used which is by default 2000</span>
worker_rlimit_nofile <span class="hljs-number">100000</span>;

# only <span class="hljs-built_in">log</span> critical errors
error_log /var/<span class="hljs-built_in">log</span>/nginx/<span class="hljs-keyword">error</span>.<span class="hljs-built_in">log</span> crit

# provides the configuration file context <span class="hljs-keyword">in</span> which the directives that affect connection processing are specified.
events {
    # determines how much clients will be served per worker
    # max clients = worker_connections * worker_processes
    # max clients <span class="hljs-keyword">is</span> also limited by the number of socket connections available <span class="hljs-keyword">on</span> the system (~<span class="hljs-number">64</span>k)
    worker_connections <span class="hljs-number">4000</span>;

    # optmized <span class="hljs-keyword">to</span> serve many clients <span class="hljs-keyword">with</span> <span class="hljs-keyword">each</span> thread, essential <span class="hljs-keyword">for</span> linux
    use epoll;

    # accept as many connections as possible, may flood worker connections <span class="hljs-keyword">if</span> <span class="hljs-keyword">set</span> too low
    multi_accept <span class="hljs-keyword">on</span>;
}

# cache informations about FDs, frequently accessed files
# can boost performance, but you need <span class="hljs-keyword">to</span> test those values
open_file_cache max=<span class="hljs-number">200000</span> inactive=<span class="hljs-number">20</span>s; 
open_file_cache_valid <span class="hljs-number">30</span>s; 
open_file_cache_min_uses <span class="hljs-number">2</span>;
open_file_cache_errors <span class="hljs-keyword">on</span>;

# <span class="hljs-keyword">to</span> boost IO <span class="hljs-keyword">on</span> HDD we can disable access logs
access_log off;

# copies data between one FD <span class="hljs-keyword">and</span> other from within the kernel
# faster <span class="hljs-keyword">then</span> read() + write()
sendfile <span class="hljs-keyword">on</span>;

# send headers <span class="hljs-keyword">in</span> one peace, its better <span class="hljs-keyword">then</span> sending them one by one 
tcp_nopush <span class="hljs-keyword">on</span>;

# don<span class="hljs-comment">'t buffer data sent, good for small data bursts in real time</span>
tcp_nodelay <span class="hljs-keyword">on</span>;

# <span class="hljs-built_in">server</span> will close connection after this <span class="hljs-built_in">time</span>
keepalive_timeout <span class="hljs-number">30</span>;

# number of requests client can make over keep-alive -- <span class="hljs-keyword">for</span> testing
keepalive_requests <span class="hljs-number">100000</span>;

# allow the <span class="hljs-built_in">server</span> <span class="hljs-keyword">to</span> close connection <span class="hljs-keyword">on</span> non responding client, this will free up memory
reset_timedout_connection <span class="hljs-keyword">on</span>;

# <span class="hljs-built_in">request</span> timed out -- <span class="hljs-keyword">default</span> <span class="hljs-number">60</span>
client_body_timeout <span class="hljs-number">10</span>;

# <span class="hljs-keyword">if</span> client <span class="hljs-keyword">stop</span> responding, free up memory -- <span class="hljs-keyword">default</span> <span class="hljs-number">60</span>
send_timeout <span class="hljs-number">2</span>;

# reduce the data that needs <span class="hljs-keyword">to</span> be sent over network
gzip <span class="hljs-keyword">on</span>;
gzip_min_length <span class="hljs-number">10240</span>;
gzip_proxied expired no-cache no-store <span class="hljs-keyword">private</span> auth;
gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;
gzip_disable <span class="hljs-string">"MSIE [1-6]\."</span>;

# you must set worker processes based on your CPU cores, nginx does not benefit from setting more than that

worker_processes = auto; #some last versions calculate it automatically, thanks to Diego :)

# number of file descriptors used for nginx

# the limit for the maximum FDs on the server is usually set by the OS.

# if you don't set FD's then OS settings will be used which is by default 2000

worker_rlimit_nofile 100000;

# only log critical errors

error_log /var/log/nginx/error.log crit

# provides the configuration file context in which the directives that affect connection processing are specified.

events {

# determines how much clients will be served per worker

# max clients = worker_connections * worker_processes

# max clients is also limited by the number of socket connections available on the system (~64k)

worker_connections 4000;

# optmized to serve many clients with each thread, essential for linux

use epoll;

# accept as many connections as possible, may flood worker connections if set too low

multi_accept on;

}

# cache informations about FDs, frequently accessed files

# can boost performance, but you need to test those values

open_file_cache max=200000 inactive=20s;

open_file_cache_valid 30s;

open_file_cache_min_uses 2;

open_file_cache_errors on;

# to boost IO on HDD we can disable access logs

access_log off;

# copies data between one FD and other from within the kernel

# faster then read() + write()

sendfile on;

# send headers in one peace, its better then sending them one by one

tcp_nopush on;

# don't buffer data sent, good for small data bursts in real time

tcp_nodelay on;

# server will close connection after this time

keepalive_timeout 30;

# number of requests client can make over keep-alive -- for testing

keepalive_requests 100000;

# allow the server to close connection on non responding client, this will free up memory

reset_timedout_connection on;

# request timed out -- default 60

client_body_timeout 10;

# if client stop responding, free up memory -- default 60

send_timeout 2;

# reduce the data that needs to be sent over network

gzip on;

gzip_min_length 10240;

gzip_proxied expired no-cache no-store private auth;

gzip_types text/plain text/css text/xml text/javascript application/x-javascript application/xml;

gzip_disable "MSIE [1-6]\.";

Now you can save config and run bottom command

/etc/init.d/nginx <span class="hljs-operator"><span class="hljs-keyword">start</span>|restart</span>

1	/etc/init.d/nginx <span class="hljs-operator"><span class="hljs-keyword">start</span>\|restart</span>

If you wish to test config first you can run

/etc/init<span class="hljs-preprocessor">.d</span>/nginx configtest

1	/etc/init<span class="hljs-preprocessor">.d</span>/nginx configtest

Just For Security Reason

<span class="hljs-title">server_tokens</span> <span class="hljs-built_in">off</span>;

1	<span class="hljs-title">server_tokens</span> <span class="hljs-built_in">off</span>;

Nginx Simple DDoS Defense

This is far away from secure DDoS defense but can slow down some small DDoS. Those configs are also in test environment and you should do your values.


# limit the number <span class="hljs-keyword">of</span> connections per single IP
limit_conn_zone $binary_remote_addr zone=conn_limit_per_ip:<span class="hljs-number">10</span>m;

# limit the number <span class="hljs-keyword">of</span> requests <span class="hljs-keyword">for</span> a given session
limit_req_zone $binary_remote_addr zone=req_limit_per_ip:<span class="hljs-number">10</span>m rate=<span class="hljs-number">5</span>r/s;

# zone which we want <span class="hljs-keyword">to</span> limit <span class="hljs-keyword">by</span> upper values, we want limit whole server
server <span class="hljs-comment">{
    limit_conn conn_limit_per_ip 10;
    limit_req zone=req_limit_per_ip burst=10 nodelay;
}</span>

# <span class="hljs-keyword">if</span> the request body size <span class="hljs-keyword">is</span> more than the buffer size, <span class="hljs-keyword">then</span> the entire (<span class="hljs-keyword">or</span> <span class="hljs-keyword">partial</span>) request body <span class="hljs-keyword">is</span> written <span class="hljs-keyword">into</span> a temporary file
client_body_buffer_size  <span class="hljs-number">128</span>k;

# headerbuffer size <span class="hljs-keyword">for</span> the request header <span class="hljs-keyword">from</span> client, its <span class="hljs-keyword">set</span> <span class="hljs-keyword">for</span> testing purpose
client_header_buffer_size <span class="hljs-number">3</span>m;

# maximum number <span class="hljs-keyword">and</span> size <span class="hljs-keyword">of</span> buffers <span class="hljs-keyword">for</span> large headers <span class="hljs-keyword">to</span> <span class="hljs-keyword">read</span> <span class="hljs-keyword">from</span> client request
large_client_header_buffers <span class="hljs-number">4</span> <span class="hljs-number">256</span>k;

# <span class="hljs-keyword">read</span> timeout <span class="hljs-keyword">for</span> the request body <span class="hljs-keyword">from</span> client, its <span class="hljs-keyword">set</span> <span class="hljs-keyword">for</span> testing purpose
client_body_timeout   <span class="hljs-number">3</span>m;

# how long <span class="hljs-keyword">to</span> wait <span class="hljs-keyword">for</span> the client <span class="hljs-keyword">to</span> send a request header, its <span class="hljs-keyword">set</span> <span class="hljs-keyword">for</span> testing purpose
client_header_timeout <span class="hljs-number">3</span>m;

# limit the number of connections per single IP

limit_conn_zone $binary_remote_addr zone=conn_limit_per_ip:10m;

# limit the number of requests for a given session

limit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=5r/s;

# zone which we want to limit by upper values, we want limit whole server

server {

limit_conn conn_limit_per_ip 10;

limit_req zone=req_limit_per_ip burst=10 nodelay;

}

# if the request body size is more than the buffer size, then the entire (or partial) request body is written into a temporary file

client_body_buffer_size 128k;

# headerbuffer size for the request header from client, its set for testing purpose

client_header_buffer_size 3m;

# maximum number and size of buffers for large headers to read from client request

large_client_header_buffers 4 256k;

# read timeout for the request body from client, its set for testing purpose

client_body_timeout 3m;

# how long to wait for the client to send a request header, its set for testing purpose

client_header_timeout 3m;

Now you can do again test config

/etc/init<span class="hljs-preprocessor">.d</span>/nginx configtest

1	/etc/init<span class="hljs-preprocessor">.d</span>/nginx configtest

And then reload or restart your nginx

/etc/init<span class="hljs-preprocessor">.d</span>/nginx restart|reload

1	/etc/init<span class="hljs-preprocessor">.d</span>/nginx restart\|reload

You can test this configuration with tsung and when you are satisfied with result you can hit Ctrl+C because it can run for hours.

Happy Hacking!