Posts tagged nginx

Managing Nginx Processes


The second in a series of Nginx posts. Nginx runs two different types of processes: the master process and worker processes. Master Process This should be started as , because this will allow Nginx to open sockets below 1024 (it needs to be able to listen on port 80 for HTTP and 443 for HTTPS). Worker Processes These are spawned by the master process, and the user and group will as specified The Nginx binary accepts command-line arguments, of which a full list can be obtained by: tells you about Nginx as well as the options it was built with: Starting To start Nginx, simply run the binary without any switches: Stopping There are two ways to stop Nginx - immediately using the signal, or gracefully using the signal: Reloading Configuration All of the above commands will verify the configuration file each time they are run, even when you’re trying to stop Nginx. When you’re unable to stop Nginx using , you may use or : Testing Your Configuration Optionally, you can specify a path with so that you can test another configuration file: Nginx as a system service Adding Nginx as a system service allows us to: Control it with standard commands Have it launch and quit at system startup and shutdown automatically To add Nginx as a system service, we simply need to include a script in called . There’re many resources out there which covers Nginx init scripts. This one seems quite popular and well-documented. Install it into your and make the script executable: Then, we need to associate the script with the operation system’s default so that the system runs this script on startup: At this point, you should be able to start, stop, restart, or poll for Nginx status (assuming you used the script above): Don’t forget to make it executable! () Linux-based operating systems have 7 s which correspond to different system states (0 means the system is shut down, 3 means the system is in multiuser mode, etc). Each state is associated with a folder in called . Each folder contains symbolic links to scripts located in . A daemon called is responsible for running the scripts associated with each state . Thus, what does is it creates a symbolic link to the script within the that is associated with the OS’s default state upon startup (for Ubuntu its 3).

Downloading and Installing Nginx


The first in a series of Nginx posts. The information here is heavily inspired from my reading of Clément Nedelcu’s excellent book Nginx HTTP Server and can be considered as my own personal reference. There are five main steps involved in installing Nginx, as outlined below: Install dependencies Download Configure Compile Install Nginx should be compiled from source, because: It may not be available in the enabled repositories of your Linux distro, Even if it is, it’s often an outdated version, and certain options and flags can only be configured at compile time. 1. Install dependencies Nginx dependencies vary, according to the modules you require. Core dependencies include: GNU Compiler Collection (GCC) Nginx is written in C, so we need a C compiler. It’s quite likely that you already have GCC installed on your system. Test if is installed: Success: Failure: To install it: Perl Compatible Regular Expression (PCRE) The Rewrite and HTTP Core modules need PCRE for parsing their regular expressions. We need to install both the library and its source: and : To install it: zlib The library contains compression algorithms and is required in Nginx for gzip compression. Like PCRE, we need both the library and its source. To install it: OpenSSL Nginx relies on OpenSSL to serve secure pages. To install it: 2. Download Nginx has three main branches: stable, mainline and legacy. It’s generally fine to use the mainline branch. Download and extract Nginx onto a directory of your choice: 3. Configure The configuration process consists of appending switches to the command. Some of these options affect the project binaries and cannot be changed post-compilation. contains configuration error logs. Below is a brief overview of the available configuration switches. Path Options Default: Specify an absolute path on which to install Nginx to. If a relative path is specified, it will be taken as relative to . Paths can also be specified for the Nginx binary (), the main configuration file (), the pid file (), the lock file (), fallback log files (, ), as well as paths where Nginx should look for its dependencies. Since the default path does not include a version number, upgrading Nginx will override the existing directory. It is recommended to override to include a version number, like this: , then create a symbolic link to point to the latest versioned Nginx folder. Make sure the path specified by exists and is read/writable by the user running the configuration…

Nginx Configuration Syntax


The third post in the Nginx series. Nginx configuration consists essentially of key-value pairs called directives, which can be organised and grouped in blocks. Directives A directive is a key-value(s) pair that looks something like this: Directives may accept more than 1 value, like the directive. Directives may also have type restrictions on values - the directive only accepts a single integer as a value. Directives are terminated with semicolons. Each module may introduce its own directives and blocks (discussed below) that can be set. Importing Nginx configuration files can be imported with the directive: The effect of this importing is that the contents of the file will be inserted at the exact location of the directive. directives are processed recursively. The directive supports filename globbing: where may match any number (>0) of consecutive characters. This will import all of the files in the folder. If a file specified by an directive cannot be found, Nginx’s configuration check will fail, unless the directive path includes a wildcard: Blocks Modules may introduce blocks, which are logical structures that group module-specific directives together. Many directives can only be used within their associated blocks. The root of the main configuration file is also known as the main block. Blocks may be nested. Below we define a block as introduced by the Nginx HTTP module. The block accepts multiple blocks defining Nginx virtual hosts, and each block itself accepts multiple blocks which contain directives specific to certain locations of the website: In nested blocks, directives are inherited by child blocks and can be overriden. In this example, logging will be disabled just for the path of . Units One may use units: or : Kilobytes or : Megabytes : Milliseconds : Seconds : Minutes : Hours : Days : Weeks : Months (30 days) : Years (365 days) Variables Variables in Nginx start with . Some modules introduce variables can be used when setting directives. Some directives do not support variables: will actually log to a file called . String values Strings may be inputted without quotes unless they include blank spaces, semicolons or curly braces, then they need to be escaped with backslashes or enclosed in single/double quotes. Variables in quoted strings are expanded normally unless the is escaped. Comments Comments is Ruby-like, with lines prepended by a :

Core Nginx Configuration and HTTP Load Testing with Autobench


The Core module controls essential Nginx features, some of which will have a direct impact on performance, such as the number of worker processes. It also includes some directives that are useful for debugging. Official Nginx docs on the Core module Below, I cover the directives that I think have the greatest impact on performance or are critical to change from default values for security purposes. Core directives Syntax: Accepted values for : , , , , , and Default: This directive can be placed in , , , and blocks to indicate specific rules for logging. Nginx file importing. See Nginx Configuration Syntax. Syntax: Default: Defined at compile time Defines the path of the pid file. Syntax: Default: off Defines whether worker processes will accept all new connections (on), or one new connection at a time (off). Syntax: Default: Nginx will automatically choose the fastest one Specifies the connection processing method to use. The available methods are , , , , , , and . For Linux systems, seems to yield the best performance. Here is an interesting post comparing and . Syntax: Defines the user that will be used to start the worker processes. It’s dangerous to set the user and group of worker processes to . Instead, create a new user specifically for Nginx worker processes ( is canonical). Syntax: Default: 1024 This sets the number of connections that can be received by each worker process. If you have 4 worker processes that can accept 1024 connections each, your system can accept a total of 4096 simultaneous connections. Related to below. Syntax: Allows you to assign worker processes to CPU cores. For example, if you’re running 3 worker processes on a dual-core CPU (which you shouldn’t, see below), you can configure the directive to assign 2 worker processes to the first CPU core and 1 to the second CPU core: There are 3 blocks for 3 worker processes, and each block has 2 digits for 2 CPU cores. Syntax: Default: 0 Adjusts the priority level of worker processes. Decrease this number if your system is running other processes simultaneously and you want to micromanage their priority levels. Syntax: Default: 1 This number should match the number of physical CPU cores on your system. Syntax: Default: None, system determined sets the limit on the number of file descriptors that Nginx can open. You can see the OS limit by using the command. Check out this excellent post for more on . An excerpt: When any program opens a file, the operating…

Nginx HTTP Module and Configuration


Nginx’s HTTP module comes with its own set of directives and structure blocks. Structure Blocks The block acts as the overarching block for all directives and sub-blocks. A block defines a website, as identified by a hostname (or many), or in Nginx parlance, a virtual host. blocks cannot be placed outside of a block. A block allows you to define settings for specific locations in a website. blocks can be placed in a block or nested within another block. A location block is specified with a pattern that will be matched against the requested URI. This pattern can be quite complex, involving location modifiers. modifier This modifier means the URI must match the pattern exactly. Only simple strings can be specified (no regular expressions). No modifier This modifier means the URI must begin with the pattern. Only simple strings can be specified (no regular expressions). modifier This modifier means the URI must match the pattern, and is case sensitive. Regular expressions are allowed. modifier This modifier means the URI must match the pattern, and is case insensitive. Regular expressions are allowed. modifier This modifier behaves the same as no modifier, except that Nginx will stop searching for other patterns if it has matched a location block with this modifier (see below for search order and priority). modifier This modifier is used to define a named location block, which can only be accessed internally by or (see below). As an example, given a pattern of or : will match all modifiers will match modifier, as well as and no modifier if your OS is case-insensitive will match all modifiers (query strings are ignored) will match only no modifier, due to the trailing slash will match only no modifier Search order and priority Different modifiers have different priorities when Nginx is searching for a location block that matches a particular URI. In order from most important to least important: Matching on the modifier Matching exactly on no modifier Matching on the modifier Matching on the and modifiers Matching on no modifier Module Directives Socket and host configuration Context: Sets the address and port for IP, or path for a UNIX-domain socket. If the address is left out, then a wildcard (*) is assumed. If the port is left out, port 80 is assumed (unless the master process is run without root privileges, in which case port 8000 will be assumed). Also accepts and parameters for SSL and SPDY (SPDY practically requires SSL…