Ubuntu Intrepid - Nginx configuration

Whether you have installed Nginx using the package manager or from source, you will need to look at the main configuration file and see what may need changing and optimising.

Although I'll make some suggestions, the aim is not to change a great deal at this point. Rather, we will look at the main settings, see what they mean and what a change will actually do.


Defaults

So why only a few changes to the default? Well, it's difficult to give a definitive configuration as there are so many variables to consider such as expected site traffic, Slice size, site type, etc.

During this article we'll discuss the main settings and you can make any decisions as to what you feel are best for your site. Any changes I do suggest are simply that: suggestions.

My advice is very simple: experiment. Find what works best on your setup.

nginx.conf

Assuming you installed via the package manager, open up the main Nginx config file:

sudo nano /etc/nginx/nginx.conf

If you installed from source, the location may be different:

sudo nano /usr/local/nginx/conf/nginx.conf

The default file is very similar in both case (again, assuming you followed the articles shown above):

user www-data;
worker_processes  1;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    access_log  /var/log/nginx/access.log;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay        on;

    gzip  on;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

The main difference you will see if you installed from source is the path in the 'include' setting which would be something like:

include /usr/local/nginx/sites-enabled/*;

Beyond that, any changes are minor and can be adjusted as discussed below although I won't mention some of the more obvious settings such access logs and pid's.

user

Default:

user www-data;

As you can imagine, this sets the nginx user.

I always push for consistency across servers and the default web server user on Debian based systems is www-data. As such, keep this as the www-data user.

You can also add a group to this setting and it may be an idea to do so as follows:

user www-data www-data;

worker_processes

Default:

worker_processes  1;

Nginx can have more than one worker process running at the same time.

To take advantage of SMP and to enable good efficiency I would recommend changing this to read:

worker_processes  4;

Although you can experiment with this number (and I encourage you to do so) setting it at more than 4 processes may actually cause Nginx to be less efficienct on your Slice.

worker_connections

Default:

events {
    worker_connections  1024;
}

Note the worker_connections setting is placed inside the 'events' module.

Sets the number of connections that each worker can handle. This is a good default setting.

You can work out the maximum clients value from this and the worker_processes settings:

max_clients = worker_processes * worker_connections

http module

Next comes the http module which contains base settings for http access:

include       /etc/nginx/mime.types;
default_type  application/octet-stream;

Unless you have an overwhelming desire, I would leave these settings alone (again, for those who installed via source, adjust the paths to those of your install).

You can, of course, add more includes if you want to customise it but messing with mime-types usually ends up with broken web pages and download errors.

Mind you, it is good fun to play with!

sendfile

Default:

sendfile        on;

Sendfile is used when the server (Nginx) can actually ignore the contents of the file it is sending. It uses the kernel sendfile support instead of using its own resources on the request.

It is generally used for larger files (such as images) which do not need use of a multiple request/confirmation system to be served — thus freeing resources for items that do need that level of 'supervision' from Nginx.

Keep it an on unless you know why you need to turn it off.

tcp

Default:

#tcp_nopush      on;
tcp_nodelay      on;

tcp_nopush: Sends the HTTP response headers in one packet. You can read more about tcp_nopush on this page.

I would change the default here and uncomment the setting as it is useful when combined with the sendfile option we set earlier.

tcp_nodelay: Disables the Nagle buffering algorithm. Well, that cleared that one up!

Actually, it is for use with items than do not require a response. General web use does require a response from the client and so, going against the default, I would change this to off.

You can read more about tcp_nodelay here.

So there you are. After saying I wouldn't change a lot, I have changed the two default tcp settings. Your experience may show otherwise and, again, all I can say is experiment with your site/app — what do you need?

keepalive

Default:

#keepalive_timeout  0;
keepalive_timeout  65;

The default is very high and can easily be reduced to a few seconds (an initial setting of 2 or 3 is a good place to start and you will rarely need more than that). If no new requests are received during this time the connection is killed.

OK, but what does it mean? Well, once a connection has been established and the client has requested a file, this says "sit there and ignore everyone else until the time limit is reached or you get a new request from the client."

Why would you want a higher time? In cases where there will be a lot of interactivity on the site. However, in most cases, people will go to a page, read it for a while and then click for the next page. You don't want the connection to sit there doing nothing, ignoring other users.

gzip

Default:

gzip  on;

Good. We like gzip. It allows for instant, real time compression.

However, I would add a few more settings as follows:

gzip_comp_level 2;
gzip_proxied any;
gzip_types      text/plain text/html text/css application/x-javascript text/xml
                application/xml application/xml+rss text/javascript;

I think those are self explanatory and simply add to the gzip setting. You can read more about the various gzip settings on this page.

include

Default:

include /etc/nginx/sites-enabled/*;

If you installed from source, we added this line:

include /usr/local/nginx/sites-enabled/*;

Either way, it defines what files to include that are located outside of the main nginx.conf.

In this case, it points to the 'sites-enabled' directory and will include any symlinked files; thus enabling any sites linked from the 'sites-available' directory.

Summary

There is a lot going on in this article, especially considering that 'nginx.conf' is such a small config file.

However, taking one setting at a time, we can see that each one is not only essential but rather flexible.

The next article will take you through setting up virtual hosts and then move onto mongrel and thin integration for your Ruby on Rails applications.

Mike

Article Comments:

David L Kinney commented Sun Mar 22 02:44:30 UTC 2009:

One of the values you specify for gzip_types is "application/xml+rss". I believe that MIME type should be "application/rss+xml". RFC3023 standardizes the "+xml" suffix for XML content. Wikipedia's entry) corroborates the "application/rss+xml" MIME type.

Cory commented Sat Mar 28 00:47:22 UTC 2009:

Where does the "maxclients = workerprocesses * worker_connections" declaration go?

Matt commented Sun Mar 29 14:42:52 UTC 2009:

@Cory, it doesn't. It was just telling you how you can work out the max number of client your server can take.

Nike commented Fri May 01 09:35:12 UTC 2009:

On Ubuntu there isin't an user www-data but Nginx work aniway... can i leave it like that even if the user don't exists? Is it safe?

m commented Thu Jun 04 07:24:05 UTC 2009:

I'musing nginx-0.7.59 from source, and using the gzip_types as listed caused a warning.

[warn]: duplicate MIME type "text/html" in /usr/local/nginx/conf/nginx.conf:34

The Nginx gzip settings docs mentions that 'text/htm' is always compressed, so I took it out of the gzip_types line and all seems well.

Matt commented Mon Jul 20 23:43:00 UTC 2009:

Updated gzip settings link: http://wiki.nginx.org/NginxHttpGzipModule

cedric commented Tue Sep 01 22:51:23 UTC 2009:

you should delete the application/xml before the application/xml+rss it's repeating

Usha Iyer commented Sun Aug 08 15:42:54 UTC 2010:

HiMike,

I am Usha Iyer, an Acquisition Editor with Packt Publishing. As an Acquisition Editor, it is my role to evaluate, develop and ultimately bring book ideas to publication. I am also responsible for finding the right author for any book; bringing them onboard, then working with them as the book is written.

Recently, I have begun to develop a title on ‘Nginx cookbook’, and am now looking for an author to write this book. The book will consist of some advanced recipes for people already familiar with Nginx.

You can find some more information about writing for us at Packt’s website http://www.packtpub.com/authors.

Please contact me if you are interested in writing this book and I would love to discuss the opportunity with you further.

Thanks, Usha Email: ushai@packtpub.com

Jered commented Mon Aug 09 14:41:03 UTC 2010:

Thank you Usha, I'll pass that along to the author and he can decide whether or not to get in touch with you. So you know, in the future we would prefer contacts of this nature be sent to support@slicehost.com so it can be handled more directly.

SoftKnight commented Mon Aug 23 10:31:22 UTC 2010:

Very nice script. Works on Ubuntu 10.04.1 very well. Gzip mime type "text/html" has to be removed from the nginx.conf as "m" said already in June 2009. Also the backup file "default.dist" has to be removed because both configs point to the same server location (even when there is no symlink in "sites-enabled" an error comes up). I just moved the file to the user home dir.

Jered commented Mon Aug 23 20:53:24 UTC 2010:

Thanks SoftKnight. When I can get to this series and update it, I'll definitely work those corrections in.

arden henderson commented Wed Dec 14 04:25:02 UTC 2011:

(typo feedback -- for author, not a public comment) (presuming comments are moderated)

text: it's own resources error: it's fix: its

Thanks!

Jered commented Fri Dec 16 03:20:41 UTC 2011:

Not moderated before being posted, but thanks Arden. ;) I'll get that fixed.

suda commented Sat Dec 24 03:44:05 UTC 2011:

Thanks for this article,it helps me greatly!

Someone commented Sun Mar 11 04:02:45 UTC 2012:

In this article, it incorrectly recommends turning tcp_nodelay off for a web server - the author googled that setting and practically copied the incorrect recommendation / explanation from another blog. Basically, what the Nagel buffering algorithm does is hold on to packets until it has a reasonable amount to send, instead of sending packets with 1 byte of important data and 40 bytes of header data (a realword example would be UPS using a freightliner with just 1 package in it's cargo) (source: http://www.techrepublic.com/article/tcpip-options-for-high-performance-data-transmission/1050878 ).

If you require constant communication with the entity you are connecting to, nginx gives the example of tracking mouse movements, than you would want this off as this article recommends.

But if you are using it as a web server, and therefore do not need absolute up to the millisecond communication, it is must better and faster leaving it on. Yes, it is faster and more efficient for a web server because by turning it on, you significantly reduce the amount of overhead required - and just pass the important stuff.

click here commented Sat May 25 00:36:03 UTC 2013:

I am not sure where you are getting your information, but good topic. I needs to spend some time learning more or understanding more. Thanks for fantastic information I was looking for this information for my mission.

http://licens.volleyball.dk/?a[]=%3Ca+href=http://agelessmalesideeffects.webs.com%3Eageless+male%3C/ commented Sat May 25 00:59:50 UTC 2013:

Thanks for sharing your info. I truly appreciate your efforts and I am waiting for your next write ups thanks once again.

zyppah rx reviews commented Sun May 26 10:39:54 UTC 2013:

Hmm it appears like your website ate my first comment (it was extremely long) so I guess I'll just sum it up what I wrote and say, I'm thoroughly enjoying your blog.

I too am an aspiring blog blogger but I'm still new to the whole thing. Do you have any tips for first-time blog writers? I'd certainly appreciate it.

click here commented Mon May 27 12:30:01 UTC 2013:

Thanks for sharing your thoughts about website. Regards

male pattern baldness commented Tue May 28 08:29:43 UTC 2013:

Hello there! This is my first visit to your blog! We are a group of volunteers and starting a new initiative in a community in the same niche. Your blog provided us beneficial information to work on.

You have done a extraordinary job!

anti snoring commented Tue May 28 12:55:21 UTC 2013:

Hello mates, nice article and good arguments commented at this place, I am genuinely enjoying by these.

buy instagram likes commented Fri May 31 09:23:23 UTC 2013:

Usually I do not read post on blogs, but I would like to say that this write-up very compelled me to take a look at and do it! Your writing taste has been surprised me. Thanks, very great post.

Want to comment?


(not made public)

(optional)

(use plain text or Markdown syntax)