#throwawaygames

Korra fan-art

We at Throw Away Games are happy to be working with a local Toronto start up to build out their MPV.  Because of the nature of these things, we can’t publicly disclose exactly what the project is, but we ARE good to talk about all the technical stuff we’re doing.  So this will be our first public post about Project: FlashBang! 

So far we’re in the very beginning stages of the process.  I’s started setting up a development environment currently consisting of 3 servers:

An HTTP server using NGINX

An app server running PHP-FPM

A database server running MariaDB

For anyone who’s still wondering in 2015 what’s so special about the cloud, this is it.  We can spin up small servers whenever we want, and scale them at a moments notice.  These three servers are all using the lowest possible resources our host provides, as it’s all private right now anyway.  Once we really start testing things we can figure out how many server’s we’ll actually need, and what resources each one will require.

But why have a different server for each item?  Shared hosts will put both your HTTP server(usually Apache rather than NGINX, which is what we’re using) and PHP on the same machine.  By separating them, we’re allowing each one to focus only on it’s task, while also allowing for some neat things like load balancing and caching.

Load balancing is used to reduce the number of connections to a particular machine.  As you've probably seen when you have too many programs open on your own computer(or in my case, too many chrome tabs), the more stuff going on at once, the slower your computer will go.  Well, the same is true for web servers.  They are just computers, and if too many people ask for too many things at once then everything could come crashing to a halt.  So a load balancer will distribute the user connections to different servers on the network, with the hope of making sure no one server has too much to handle at once.

This is where NGINX comes in.  I’ve referred to it as an HTTP server, but what does that actually mean?  In simple terms, it takes requests for something over HTTP(Hyper Text Transfer Protocol, the language of the web), and sends something back to your web browser.  Pretty straight forward.  Compare this to our app server.  This is the server our program, or APPlication, runs.  It takes instructions, executes functions, and does most of the fancy logic to determine what the HTTP server should be sending.  If you then make 3 of the same app servers, you can use NGINX’s built in load balancing to split the user connections between them.  So for example, if you’re on www.fancycats.com, and click the “give me a fancy cat” button, you’ll send your request for a fancy cat to the HTTP server.  The HTTP server will forward your request for a fancy cat to one of your app servers.  The app server will look at your request, look through the list of cats, and know to return only a fancy one to the HTTP server.  The HTTP server then gives you the cat.

How NGINX actually does load balancing is pretty simple.  If you’re reading this part, I’m assuming you know how to install NGINX and PHP-FPM, or you just like reading server configuration snippets for some reason.  In the http block of your nginx.conf, create the following:

upstream appserver {     server xx.xx.xx.01:9001;     server xx.xx.xx.02:9001;     server xx.xx.xx.03:9001; }

This sets up a group of servers, labelled appserver(change this to your liking), which NGINX will choose from.  Replace the dummy ip addresses with your own, same with the port number.  By default, the balancing method is one called round robbin, which basically takes the first request and sends it to server 1, the second request to server two, and etc.  You can also specify the least connections method(least_conn), which sends the request to the server with the lease number of connections to it at the time, or the ip hash method(ip_hash), which assigns a user to a particular server, so each request from that user goes to that same app server every time.  To use one of those methods, place the method name above the ip addresses.

Next, in the location block of your HTTP servers config, have something like the following:

location ~* \.(php)($|/) {         fastcgi_index index.php;         include fastcgi_params;         fastcgi_pass appserver;         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }

The key part here is the fastcgi_pass.  This is what sends the request to PHP.  It would normally point to 127.0.0.1, or to a PHP socket on your machine, but instead we have it pointing to the appserver group, which will then direct it to the proper APP server.

Finally, on our actual app server.  You’ll need to open up your conf file for the pool you’re using(for example on Ubuntu, /etc/php5/fpm/pool.d/www.conf), and set the following:

listen = 9001 listen.allowed_clients = xx.xx.xx.xx

These lines tell PHP-FPM where to look for incoming connections, and who’s allowed to connect.  Note that listen is set to the port listed in the appserver group.  allowed_clients should be the ip address of the HTTP server(s) your using to connect from.  You can use more than one ip address by separating them with commas.