Installing NGINX and Third-Party Modules
[ 16 ]As you can see, these are all modules that build upon the http module, providing
extra functionality. Enabling the modules at compile time should not affect runtime
performance at all. Using the modules later in the configuration is where performance
may be impacted.
I would therefore recommend the following configure options for a web
accelerator/proxy:
$ ./configure --with-http_ssl_module --with-http_realip_module --with-
http_geoip_module --with-http_stub_statusmodule --with-openssl=${BUILD
DIR}/openssl-1.0.1c
And the following for a web server:
$ ./configure --with-http_stub_status_module
The difference lies in where NGINX will be faced with clients. The web acceleration
role would take care of terminating SSL requests as well as dealing with proxied
clients and making decisions based on where a client came from. The web server
role would need only provide default file serving capability.
I would recommend always enabling the stub_status module, as it provides a
means of gathering metrics on how your NGINX is performing.
Disabling unused modules
There are also a number of http modules that are normally activated, but may
be disabled by setting the appropriate configuration option --without-<module-
name>_module. If you have no use for these modules in your configuration, you
can safely disable them.
Table: Disable configure options
Option Explanation
--without-http_charset_module The charset module is responsible for
setting the Content-Type response
header, as well as converting from one
charset to another.
--without-http_gzip_module The gzip module works as an output
filter, compressing content as it's
delivered to the client.
--without-http_ssi_module This module is a filter that processes
Server Side Includes. If the Perl module
is enabled, an additional SSI command
(perl) is available.