4965 Chapter 7 Nginx as a Reverse Proxy

Nginx 1 Web Server Implementation Cookbook

Dipankar Sarkar

Chapter No.7 "Nginx as a Reverse Proxy"

In this package, you will find: A Biography of the author of the book A preview chapter from the book, Chapter NO.7 "Nginx as a Reverse Proxy" A synopsis of the book’s content Information on where to buy this book

About the Author Dipankar Sarkar is a web and mobile entrepreneur. He has a Bachelor's degree in Computer Science and Engineering from the Indian Institute of Technology, Delhi. He is a firm believer in the Open source movement and has participated in the Google Summer of Code, 2005-06 and 2006-07. He has conducted technical workshops for Windows mobile and Python at various technical meet ups. He recently took part in the Startup Leadership Program, Delhi Chapter. He has worked with Slideshare LLC, one of the world's largest online presentation hosting and sharing service as an ea rly engineering employee. He has since then worked with Mpower Mobile LLC, a mobile payment startup and Clickable LLC, a leading search engine marketing startup. He was a co-founder at Kwippy, which was one of the top micro-blogging sites. He is currently working in the social TV space and has cofounded Jaja.

For More Information: www.PacktPub.com/nginx-1-web-server-implementation-cookbook/book

This is his first technical publication I would like to thank my patient and long suffering wife, Maitrayee, for putting up with my insane working hours and for being there for me throughout. My mother and my sister, Rickta a nd Amrita, whose belief and support sustains me. My in laws, Amal and Ruchira Roychoudhury, for opening their homes and hearts to me so generously. Also to my father, the late A. C. Sarkar, who co-authored the first chapter of my life and without whom none of this would have been possible. I would also like to thank Usha, Hyacintha, Srimoyee, and Kavita from Packt who made this opportunity possible and have been fantastic to work with. I am deeply grateful to the technical reviewers whose insights have been invaluable. Needless to say, errors, if any, are mine.


Nginx 1 Web Server Implementation Cookbook Nginx is an open source high-performance web server, which has gained quite some popularity recently. Due to its modular architecture and small footprint, it has been the default choice for a lot of smaller Web 2.0 companies to be used as a load-balancing proxy server. It supports most of the existing backend web protocols such as FCGI, WSGI, and SCGI. This book is for you if you want to have in-depth knowledge of the Nginx server. Nginx 1 Web Server Implementation Cookbook covers the whole range of techniques that would prove useful for you in setting up a very effective web application with the Nginx web server. It has recipes for lesser-known applications of Nginx like a mail proxy server, streaming of video fi les, image resizing on the fl y, and much more. The first chapter of the book covers the basics that would be useful for anyone who is starting with Nginx. Each recipe is designed to be independent of the others. The book has recipes based on broad areas such as core, logging, rewrites, security, and others. We look at ways to optimize your Nginx setup, setting up your WordPress blog, blocking bots that post spam on your site, setting up monitoring using munin, and much more. Nginx 1 Web Server Implementation Cookbook makes your entry into the Nginx world easy with step-by-step recipes for nearly all the tasks necessary to run your own web application. A practical guide for system administrators and web developers alike to get the best out of the open source Nginx web server.

What This Book Covers Chapter 1, The Core HTTP Module, deals with the basics of Nginx configuration and implementation. By the end of it you should be able to compile Nginx on your machine, create virtual hosts, set up user tracking, and get PHP to work. Chapter 2, All About Rewrites: The Rewrite Module, is devoted to the rewrite module; it will teach you the basics and also allow you to configure various commonly available web development frameworks to work correctly with your Nginx setup using the correct rewrite rules. Chapter 3, Get It All Logged: The Logging Module, aims to teach the basics as well as the advanced configurations that can be done around the Nginx logging module, like log management, backup, rotation, and more. Logging is very crucial as it can help you


identify and track various attributes of your application like performance, user behavior, and much more. It also helps you as a system administrator to identify, both reactively and proactively, potential security issues. Chapter 4, Slow Them Down: Access and Rate Limiting Module, explains how Nginx provides good protection against cases such as bringing down sites by providing rate limiting and server access based on IP. Chapter 5, Let's be Secure: Security Modules, looks at how we can use the security modules built-in Nginx to secure your site and user's data. Chapter 6, Setting Up Applications: FCGI and WSGI Modules, has a practical section devoted to helping programmers and system administrators understand and install their applications using Nginx as the web server. Due to the lack of integrated modules for running PHP and Python, the setting up of such systems can be an issue for nonexperienced system administrators. Chapter 7, Nginx as a Reverse Proxy, deals with the usage of Nginx as a reverse proxy in various common scenarios. We will have a look at how we can set up a rail application; set up load balancing, and also have a look at caching setup using Nginx, which will potentially enhance the performance of your existing site without any codebase changes. Chapter 8, Improving Performance and SEO Using Nginx, is all about how you can make your site load faster and possibly get more traffic on your site. We will cover the basics of optimizing your Nginx setup and some SEO tricks. These techniques will not only be useful for your SEO, but also for the overall health of your site and applications. Chapter 9, Using Other Third-party Modules, a look at some inbuilt and third-party modules which allow us to extend and use Nginx with other protocols such as IMAP, POP3, WebDAV, and much more. Due to the flexible and well-defined module API, many module developers have used Nginx for interesting web-based tasks such as XSLT transformations, image resizing, and HTTP publish-subscribe server. Chapter 10, Some More Third-party Modules, looks at various web situations such as load balancing, server health checks, and more which will be very useful in a production environment. These simple recipes will be highly applicable in enterprise scenarios where you may need to have analytics, external authentication schemes, and many other situations.


7

N g i n x a s a Rev e r s e Proxy In this chapter, we will cover: 

Using Nginx as a simple reverse proxy



Setting up a rails site using Nginx as a reverse proxy



Setting up correct reverse proxy timeouts



Setting up caching on the reverse proxy



Using multiple backends for the reverse proxy



Serving CGI files using thttpd and Nginx



Setting up load balancing with reverse proxy



Splitting requests based on various conditions using split-clients

Introduction Nginx has found most applications acting as a reverse proxy for many sites. A reverse proxy is a type of proxy server that retrieves resources for a client from one or more servers. These resources are returned to the client as though they originated from the proxy server itself. Due to its event driven architecture and C codebase, it consumes significantly lower CPU power and memory than many other better known solutions out there. This chapter will deal with the usage of Nginx as a reverse proxy in various common scenarios. We will have a look at how we can set up a rail application, set up load balancing, and also look at a caching setup using Nginx, which will potentially enhance the performance of your existing site without any codebase changes.


Nginx as a Reverse Proxy

U s i n g N g i n x a s a s i m p l e r e ve r s e p r o x y Nginx in its simplest form can be used as a reverse proxy for any site; it acts as an intermediary layer for security, load distribution, caching, and compression purposes. In effect, it can potentially enhance the overall quality of the site for the end user without any change of application source code by distributing the load from incoming requests to multiple backend servers, and also caching static, as well as dynamic content.

H o w t o d o i t ... You will need to first define p r o x y. c o nf , which will be later included in the main configuration of the reverse proxy that we are setting up: p r o xy _r e di r e c t p r o x y _s e t _ he a d e r p r o x y _s e t _ he a d e r p r o x y_ s e t _ h e a d e r c l i e n t _ ma x _ b od y _s i z e c l i e n t _ b od y_ bu f f e r _ s i z e p r o x y_ c o nn e c t _ t i me o u t p r o x y_ s e n d _ t i me o u t p r o x y _r e a d _t i me o ut p r o x y _b uf f e r s

off ; Ho s t $ ho s t ; X- Re a l - I P $ r e mo t e _ a dd r ; X- Fo r wa r d e d - Fo r $ p r o x y _ a dd _ x_ f o r wa r d e d _f o r ; 1 0 m; 1 28 k; 9 0; 90; 9 0; s 32 4k

To use Nginx as a reverse proxy for a site running on a local port of the server, the following configuration will suf fice: server { l i st en 80; s e r v e r _ n a me e x a mp l e 1 . c o m; a c c e s s _ l o g / v a r / www/ e x a mp l e 1 . c o m/ l o g/ n gi n x. a c c e s s . l o g; 120


Chapter 7

er r or_l og l o c at i o n /

/ v a r / www/ e x a mp l e 1 . c o m/ l o g/ n gi n x_ e r r o r . l o g d e bu g; {

i n c l u de p r o xy . c on f ; pr o xy _p as s

h t t p : / / 1 27 . 0 . 0 . 1: 8 08 0;

} }

H o w i t w o r k s . .. In this recipe, Nginx simply acts as a proxy for the defined backend server which is running on the 8080 port of the server, which can be any HTTP web application. Later in this chapter, other advanced recipes will have a look at how one can define more backend servers, and how we can set them up to respond to requests.

Se t t i n g u p a r a i l s s i t e u s i n g N gi n x a s a r e v er s e p r o x y In this recipe, we will set up a working rails site and set up Nginx working on top of the application. This will assume that the reader has some knowledge of rails and thin. There are other ways of running Nginx and rails, as well, like using Passenger Phusion.

H o w t o d o i t ... This will require you to set up thin first, then to configure thin for your application, and then to configure Nginx. 1.

If you already have gems installed then the following command will install thin, otherwise you will need to install it from source: sudo gem install thin

121


Nginx as a Reverse Proxy 2.

Now you need to generate the thin configuration. This will create a configuration in the / e t c / t h i n directory: sudo thin config -C /etc/thin/myapp.yml -c /var/rails/myapp --servers 5 -e production

3.

Now you can start the thin service. Depending on your operating system the start up command will vary.

4.

Assuming that you have Nginx installed, you will need to add the following to the configuration file: up s t r e a m t hi n _ c l u s t e r { s e r v er u n i x : / t mp / t h i n . 0 . s o c k; s e r v er u n i x : / t mp / t h i n . 1 . s o c k; s e r v er u n i x : / t mp / t h i n . 2 . s o c k; s e r v er u n i x : / t mp / t h i n . 3 . s o c k; s e r v er u n i x : / t mp / t h i n . 4 . s o c k; } server { l i st en

80;

s e r v e r _ n a me

www. e x a mp l e 1 . c o m;

r o ot / v a r / www. e x a mp l e 1 . c o m/ p ub l i c ; l oc at i on / { p r o x y _s e t _ he a d e r

X- Re a l - I P

$ r e mo t e _ a dd r ;

p r o xy _s e t _ he a d e r

X- Fo r wa r d e d- Fo r $ pr o x y_ a dd _x _ f o r wa r d e d _f o r ;

p r o x y _s e t _ he a d e r Ho s t $ h t t p _h os t ; p r o xy_ r e d i r e c t f a l s e ; t r y _f i l e s $u r i $ ur i / i n de x. h t ml $ ur i . h t ml @t hi n ; l o c at i o n @t h i n { i n cl u de pr o xy . c o nf ; p r o xy _ p a s s h t t p : / / t h i n_ c l u s t e r ; } } e r r o r _ p a ge

500 502 503 504

/ 5 0 x. h t ml ;

l o ca t i o n = / 5 0x . h t ml { r o ot

h t ml ;

} }

122


Chapter 7

H o w i t w o r k s . .. This is a fairly simple rails stack, where we basically configure and run five upstream thin threads which interact with Nginx through socket connections. There are a few rewrites that ensure that Nginx serves the static files, and all dynamic requests are processed by the rails backend. It can also be seen how we set proxy headers correctly to ensure that the client IP is forwarded correctly to the rails application. It is important for a lot of applications to be able to access the client IP to show geo-located information, and logging this IP can be useful in identifying if geography is a problem when the site is not working properly for specific clients.

Se t t i n g up c o r r e c t r e v er s e p r ox y t i m e o u t s In this section we will set up correct reverse proxy timeouts which will affect your user's interaction when your backend application is unable to respond to the client's request. In such a case, it is advisable to set up some sensible timeout pages so that the user can understand that further refreshing may only aggravate the issues on the web application.

H o w t o d o i t ... You will first need to set up p r o x y. c o nf which will later be included in the configuration: p r o xy _r e di r e c t p r o x y _s e t _ he a d e r p r o x y _s e t _ he a d e r p r o x y_ s e t _ h e a d e r c l i e n t _ ma x _ b od y _s i z e c l i e n t _ b od y_ bu f f e r _ s i z e p r o x y_ c o nn e c t _ t i me o u t p r o x y_ s e n d _ t i me o u t p r o x y _r e a d _t i me o ut p r o x y _b uf f e r s

off ; Ho s t $ ho s t ; X- Re a l - I P $ r e mo t e _ a dd r ; X- Fo r wa r d e d - Fo r $ p r o x y _ a dd _ x_ f o r wa r d e d _f o r ; 1 0 m; 1 28 k; 9 0; 90; 9 0; s 32 4k

Reverse proxy timeouts are some fairly simple flags that we need to set up in the Nginx configuration like in the following example: server { l i st en 80; s e r v e r _ n a me e x a mp l e 1 . c o m; a c c e s s _ l o g / v a r / www/ e x a mp l e 1 . c o m/ l o g/ n gi n x. a c c e s s . l o g; e r r o r _ l o g / v a r / www/ e x a mp l e 1 . c o m/ l o g/ n gi n x_ e r r o r . l o g d e bu g; # s e t y ou r d e f a ul t l o c at i o n 123


Nginx as a Reverse Proxy l oc a t i on /

{

i n c l u de p r o xy . c on f ; proxy_read_timeout 120; proxy_connect_timeout 120; pr o xy _p as s h t t p : / / 1 27 . 0 . 0 . 1: 8 08 0; } }

H o w i t w o r k s . .. In the preceding configuration we have set the following variables, it is fairly clear what these variables achieve in the context of the configurations: Directive

Use

p r o xy _r e a d _ t i me o u t

This directive sets the read timeout for the response of the proxied server. It determines how long Nginx will wait to get the response to a request. The timeout is established not for the entire response, but only between two operations of reading.

p r o xy _c o n ne c t _ t i me o u t

This directive assigns timeout with the transfer of request to the upstream server. Timeout is established not on the entire transfer of request, but only between two write operations. If after this time the upstream server does not take new data, then Nginx shuts down the connection.

Se t t i n g u p c a c h i n g o n t h e r e ve r s e p r ox y In a setup where Nginx acts as the layer between the client and the backend web application, it is clear that caching can be one of the benefits that can be achieved. In this recipe, we will have a look at setting up caching for any site to which Nginx is acting as a reverse proxy. Due to extremely small footprint and modular architecture, Nginx has become quite the Swiss knife of the modern web stack.

124


Chapter 7

H o w t o d o i t ... This example configuration shows how we can use caching when utilizing Nginx as a reverse proxy web server: ht t p { proxy_cache_path /var/www/cache levels=1:2 keys_zone=my-cache:8m max_size=1000m inactive=600m;

proxy_temp_path /var/www/cache/tmp; ... s e r v er { l i st en

80;


e x a mp l e 1 . c o m;

access_l og er r or_l og

/ v a r / www/ e xa mp l e 1 . c om/ l o g/ n gi n x. a c c e s s . l o g; / v a r / www/ e x a mp l e 1 . c o m/ l o g/ n gi n x_ e r r o r . l o g d e bu g;

# s e t y ou r d e f a ul t l oc a t i on /

l oc at i on

{

i n cl u de p r o xy . c o nf ; p r o xy _pa s s h t t p : / / 1 27 . 0. 0 . 1 : 8 0 8 0/ ; proxy_cache my-cache; proxy_cache_valid 200 302 60m;

proxy_cache_valid

404

1m;

} } }

H ow i t w o r k s . .. This configuration implements a simple cache with 1000MB maximum size, and keeps all HTTP response 200 pages in the cache for 60 minutes and HTTP response 404 pages in cache for 1 minute. There is an initial directive that creates the cache file on initialization, in further directives we basically configure the location that is going to be cached.

It is possible to actually set up more than one cache path for multiple locations.

125



T h e r e ' s m o r e . .. This was a relatively small show of what can be achieved with the caching aspect of the proxy module. Here are some more directives that can be really useful in optimizing and making your stack faster and more ef ficient: Directive

Use

pr oxy_ca che _bypas s

The directive speci fies the conditions under which the answer will not be taken from the cache. If one string variable is not empty and not equal to "0", the answer is not taken from the cache.

pr oxy_c ac he _mi n_ us es

This directive determines the number of accesses before a page is cached.

pr oxy_ca che _us e_ st al e

This directive tells Nginx when to serve a stale item from the proxy cache. For example, when an Application error HTTP Code 500 occurs.

pr oxy_cache _ me t ho ds

This directive lets you choose what directives to cache [GET, PUT, and so on].

U s i n g m u l t i p l e b a c k e n d s f o r t h e r e ve r s e proxy As traf fic increases, the need to scale the site up becomes a necessity. With a transparent reverse proxy like Nginx in front, most users never even see the scaling affecting their interactions with the site. Usually, for smaller sites one backend process is suf ficient to handle the oncoming traf fic. As the site popularity increases, the first solution is to increase the number of backend processes and let Nginx multiplex the client requests. This recipe takes a look at how to add new backend p rocesses to Nginx.

126


Chapter 7

H o w t o d o i t ... The configuration below adds three upstream servers to which client requests will be sent for processing:

upstream server server server }

backend { backend1.example1.com weight=5; backend2.example1.com max_fails=3 backend3.example1.com;

fail_timeout=30s;

s e r v er { l i st en

80;




/ v a r / www/ e xa mp l e 1 . c om/ l o g/ n gi n x. a c c e s s . l o g; / v a r / www/ e x a mp l e 1 . c o m/ l o g/ n gi n x_ e r r o r . l o g d e bu g;

# s e t y ou r d e f a ul t

l oc at i on

l oc a t i on / { i n c l u de p r o xy . c on f ;

proxy_pass

http://backend;

} }

H ow i t w o r k s . .. In this configuration we set up an upstream, which is nothing but a set of servers with some proxy parameters. For the server h t t p : / / b ac ke nd 1. e xa mp l e 1. c om, we have set a weight of five, which means that the majority of the requests will be directed to that server. This can be useful in cases where there are some powerful servers and some weaker ones. In the next server h t t p : / / b ac ke nd 2. e xa mp l e 1. c om, we have set the parameters such that three failed requests over a time period of 30 seconds will result in the server being considered inoperative. The last one is a plain vanilla setup, where one error in a ten second window will make the server inoperative! This displays the thought put in behind the design of Nginx. It seamlessly handles servers which are problematic and puts them in the set of inoperative servers. All requests to the server are sent in a round robin fashion. We will discuss modules in future recipes that ensure that the requests are sent using other queue mechanisms based on server load and other upstream server performance metrics.

127



Ser vin g CGI

fil e s

u s i ng t h t t p d a n d N g in x

At some point in time in Internet history, most applications were CGI based. Nginx does not serve CGI scripts, so the workaround is to use a really ef ficient and simple HTTP server called thttpd and to get Nginx to act as a proxy to it.

H o w t o d o i t ... The best way to go about it is to set up thttpd from source code, apply the IP forwarding patch, and then to use the configuration below: 1.

Download thttpd and apply the patch. wget h t t p : / / www. a c me . c om/ s o f t wa r e / t h t t p d / t h t t p d - 2 . 2 5 b . t a r . g z tar –xvzf

2.

thttpd-2.25b.tar.gz

Save the code below in a file called t h t t p d . p a t c h: ---

t h t t p d- 2 . 2 5b/ l i b ht t p d. c

2 00 3- 1 2- 2 5 2 0: 06 : 0 5 . 0 00 000 00 0 +0 100

+++ t ht t p d- 2 . 2 5b- p at c he d/ l i b ht t p d. c 0 0 : 2 6 : 0 4 . 8 6 72 5 52 4 8 +0 1 00

2 00 5- 0 1- 0 9

@@ - 2207, 6 +2207, 12 @@ if (

s t r c a s e c mp ( c p,

" k e ep - a l i v e" ) = = 0 )

h c - >k e e p _a l i v e = 1 ; } + )

e l s e i f ( s t r n ca s e c mp ( b uf ,

+

{ / / Us e r e a l I P i f a va i l a bl e

+

c p = &b u f [ 1 6 ] ;

+

c p += s t r s pn( c p,

+

i ne t _a t on( c p,

+

" X- Fo r wa r d e d- Fo r : " ,

1 6 ) == 0

" \t" );

&( hc - >c l i e nt _a ddr . s a _i n. s i n_a ddr ) ) ;

} #i f de f LOG_UNKNOWN_HEADERS el se i f (

s t r n ca s e c mp ( b uf ,

" Ac c e pt - Ch ar s e t : " ,

15 ) == 0

| | s t r n c a s e c mp ( b u f ,

3.

" Ac c e p t - La n gu a ge : " ,

1 6 ) == 0 | |

Apply the patch and install thttpd: patch -p 1 -i thttpd.patch cd thttpd-2.25b make sudo make install

128


Chapter 7

4.

Use the following configuration for / e t c / t h t t p d . c o n f : # BEWARE : No empt y l i nes ar e a l l owed! # Thi s s e c t i on ove r r i de s d ef a ul t s # Th i s s e c t i o n _d oc ume nt s _ d ef a ul t s i n e f f e c t # po r t =8 0 # n os y ml i n k

# defaul t = ! chroot

# novhost # n oc g i p a t # not hr o t t l e s # hos t =0. 0. 0. 0 # c ha r s e t =i s o - 8 85 9- 1 ho s t =12 7. 0 . 0 . 1 p or t =8 00 0 us e r =t ht t pd l ogf i l e =/ va r / l og/ t ht t pd. l og pi df i l e =/ va r / r u n/ t ht t pd. pi d d i r =/ v a r / www c gi pa t =**. c gi | **. pl

5.

Set up Nginx as a proxy for the port 8000. server { l i st en

80;

s e r v e r _ n a me access _l og er r or_l og

e x a mp l e 1 . c o m; / v a r / www/ e x a mp l e 1 . c o m/ l o g/ n gi n x. a c c e s s . l o g; / v a r / www/ e x a mp l e 1 . c o m/ l o g/ n gi n x_ e r r o r . l o g d e bu g;

l oc a t i on / c gi - b i n { i n cl u de p r o x y. c on f ; p r o xy _p as s

h t t p : / / 1 27 . 0 . 0. 1 : 8 00 0;

} }

H ow i t w o r k s . .. The setup above allows you to enjoy the best of CGI and Nginx. You initially set up thttpd, which will run on port 8000 of the server, which will effectively be the core CGI web server and you can run Nginx as the proxy for the user requests. All you need to do is place the perl scripts in the / v a r / www directory and you will be running CGI using Nginx and thttpd.

129



You can also use the same technique as above to run CGI scripts using other CGI-capable servers like Apache and lightHTTPD as well. You will be required to change the operating ports of those servers to 8000 and the same configuration like above will work.

Se t t i n g u p l o a d b al a n c i n g w i t h r e ve r s e p r ox y In most reverse proxy systems one wants to have some notion of load balancing in the system. In one of the preceding recipes, we have seen how to set up and run multiple upstream servers in a round robin mechanism of sending over the requests. In this recipe, we will install a load balancing module which will allow us to set up a fair load balancing with the upstream servers.

H o w t o d o i t ... For this particular recipe we will install a third-party module called "upstream fair module". 1.

You will need to go an download the module: wget https://github.com/gnosek/nginx-upstream-fair/tarball/master

130


Chapter 7

2.

Compile Nginx with the new module: Tar –xvzf nginx-upstream-fair.tgz Cd nginx ./configure --with-http_ssl_module --add-module=../nginx-upstreamfair/ Make && make install

3.

You will need to add the following configuration to your n gi n x. c o nf : u ps t r e a m b ac k en d

{

s e r v e r b a c k e n d 1. e x a mp l e 1 . c o m; s e r v e r b a c k e n d 2. e x a mp l e 1 . c o m; s e r v e r b a c k e n d 3. e x a mp l e 1 . c o m;

fair no_rr; } s e r v er { l i st en

80 ;




/ v ar / www/ e x amp l e 1. c o m/ l o g/ n gi n x. a c c e s s . l o g; / v a r / www/ e x a mp l e 1 . c o m/ l o g/ n gi n x_ e r r o r . l o g d e bu g;

# s e t y o u r d e f a ul t l oc at i on /

l oc a t i on

{

p r o xy _p a s s

h t t p : / / b ac k en d;

} }

H ow i t w o r k s . .. This is a fairly straightforward setup once you understand the basics of setting up multiple upstream servers. In this particular "fair" mode, which is n o_ r r , the server will send the request to the first backend whenever it is idle. The goal of this module is to not send requests to already busy backends as it keeps information of how many requests a curr ent backend is already processing. This is a much better model than the default round robin that is implemented in the default upstream directive.

131



There's more... You can choose to run this load balancer module in a few other modes, as described below, based on your needs! This is a very simple way of ensuring that none of the backend experiences load unevenly as compared to the rest: Mode

Meaning

default (that is fair;)

The default mode is a simple WLC-RR (weighted least-connection round-robin) algorithm with a caveat that the weighted part isn't actually too fair under low load.

n o_ r r

This means that whenever the first backend is idle, it's going to get the next request. If it's busy, the request will go to the second backend unless it's busy too, and so on.

we i g ht _ mo d e =i d l e n o_ r r

This mode redefines the meaning of "idle". It now means "less than weight concurrent requests". So you can easily benchmark your backends and determine that X concurrent requests are the maximum for you.

we i g ht _ mode =pea k

This means that Nginx will never send more than weight requests to any single backend. If all backends are full, you will start receiving 502 errors.

Here is an example of a peak weight mode setup: u ps t r e a m b a ck en d { s e r v e r b a c ke n d1 . e x a mp l e 1 . c o m we i g ht =4 ; s e r v e r b a c ke n d2 . e x a mp l e 1 . c o m we i g ht =3 ; s e r v e r b a c ke n d3 . e x a mp l e 1 . c o m we i g ht =4 ; fair weight_mode=idle no_rr; }

Sp l i t t i n g r e q u e s t s b a s e d o n v a r i o u s c o n d i t i o n s u s i n g s p l i t -c l i e n t s This recipe will take a look at how we can potentially separate client requests based on various conditions that can arise. We will also understand how we can potentially set up a simple page for A-B testing using this module.

132


Chapter 7

H o w t o d o i t ... This module is fairly simple to use and comes inbuilt with Nginx. All you need to do is to insert the following configuration in your n gi n x. c o nf : ht t p {

split-clients "${remote-addr}AAA" $variant { 50.0% .one; 50,0% .two; - ""; } ... server { l i st en 80; s e r v e r _ n a me e x a mp l e 1 . c o m; a c c e s s _ l o g / v a r / www/ e x a mp l e 1 . c o m/ l o g/ n gi n x. a c c e s s . l o g; e r r o r _ l o g / v a r / www/ e x a mp l e 1 . c o m/ l o g/ n gi n x_ e r r o r . l o g d e bu g; l o c at i o n / { r o o t / v a r / www/ e x a mp l e 1 . c o m;

index index${variant}.html; } } }

H ow i t w o r k s . .. This particular configuration sets up a system which is based upon the remote client address, assigns the values . o n e , . t wo , or "" to a variable $ va r i a nt . Based upon the variable value, a different page is picked up from the file location. 133


Nginx as a Reverse Proxy The following table shows the various probabilities and actions from the above configuration: Variable value

Probability

Page served

. one

50%

/ va r / www/ e xa mpl e 1. c om/ i nde x. one . h t ml

. t wo

50%

/ va r / www/ e xa mpl e 1. c om/ i n de x. t wo. ht ml

""

0%

/ va r / www/ e xa mpl e 1. c om/ i n de x. ht ml

The preceding pie chart clearly displays the split across the two pages. Utilizing this approach, we are able to test out interactions with the page changes that you have made. This forms the basis of usability testing.

134


Where to buy this book You can buy Nginx 1 Web Server Implementation Cookbook from the Packt Publishing website: http://www.packtpub.com/nginx-1-web-serverimplementation-cookbook/book. Free shipping to the US, UK, Europe and selected Asian countries. For more information, please read our shipping policy.

Alternatively, you can buy the book from Amazon, BN.com, Computer Manuals and most internet book retailers.

www.PacktPub.com


4965 Chapter 7 Nginx as a Reverse Proxy

Recommend Documents