Category: ColdFusion

Nginx is that popular webserver that’s been increasingly eating up the webserver market share. Wikipedia says over 30% of the top 100K sites run on Nginx. The Nginx wiki speaks of the webserver as a high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server.

The most striking feature of Nginx though, is that it adopts a non-blocking, event driven architecture to serve requests. Unlike Apache or IIS, which spawn a new process (or worker) or thread to handle new requests, Nginx is single-threaded and new connections are placed within an event loop, with requests processed asynchronously. This provisions memory and CPU usages to be consistent, irrespective of the number of connections. Simultaneous connections on Apache and IIS on the other hand, would incrementally hog resources, upping the memory footprint. Wikipedia notes Nginx to use ~2.5 MB memory per 10k inactive HTTP keep-alive connections.

Now, to make sense of all this in ColdFusion’s context, let’s see how Nginx works with ColdFusion.
This post walks you through two aspects,

1. Configuring Nginx to serve ColdFusion requests
2. Using Nginx as a load balancer between CF instances

 

Configure Nginx to serve ColdFusion requests

Now, there are two ways (you will figure out there are actually three ways) to get ColdFusion configured with Nginx – with the AJP protocol as done for Apache or IIS, or using Nginx as a reverse proxy to ColdFusion.

Through the AJP Protocol
Nginx speaks only HTTP, FastCGI, SCGI, uWSGI and MemCache – hence, no native support for AJP. We will use a third party AJP module to connect to ColdFusion.

Configuring ColdFusion with Nginx over AJP comes with limitations. A modified Tomcat Connector is used while configuring through the ColdFusion Connector, and things could go haywire, to an extent that something as simple as CGI variables could break!
The AJP Module is also not listed in on nginx.org, though Nginx maintains the list is community updated.
That leaves us with the option of reverse proxy.

As a Reverse Proxy
Configuring a reverse proxy is extremely simple. Directive’s for a reverse proxy to Apache are already in place in the vanilla configuration file. All you need to do is edit it!
Here’s a configuration file for an Nginx server running on port 85, and a ColdFusion server running on port 8501.

#user  nobody;
worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    #tcp_nopush     on;
    keepalive_timeout  65;
    #gzip  on;
    server {
        listen       85;
        server_name  localhost;
        #charset koi8-r;
        #access_log  logs/host.access.log  main;
        location / {
            root   html;
            index  index.html index.htm index.cfm;
        }
        #error_page  404              /404.html;
        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
        # proxy the CFC, CFM scripts to ColdFusion listening on 127.0.0.1:8501
        #
        location ~ \.cfm$ {
            proxy_pass   http://127.0.0.1:8501;
        }
        location ~ \.cfc$ {
            proxy_pass   http://127.0.0.1:8501;
        }
    }
}

The complete configuration file can be downloaded from, https://bitbucket.org/immanuelnoel/coldfusion-nginx-proxy

A handful of limitations exist here too.

1. Since the connector does not come into play, ColdFusion is unable to process CFM / CFC files that exist within the Nginx webroot
2. SES URLs – again introduced by ColdFusion connector, are not available
3. CGI variable for server port shows up ColdFusion port

Another way to reverse proxy
To have absolute support for ColdFusion, while also extracting Nginx’s powerful static file handling, you might have to configure Nginx as a reverse proxy to Apache, and have ColdFusion configured with Apache. Having Nginx frontend Apache, is a common use-case, especially when the requirement is to absolutely use Apache (for things like directory level configurations – Nginx has nothing on the lines of .htaccess), while also benefiting from Nginx’s serviceability. The idea here, is to have static resources served by Nginx, with Nginx forwarding requests it doesn’t understand to Apache, and eventually, Apache ends up serving only ColdFusion requests.

Before you start to contemplate whether or not this is good, let’s look at some numbers.
I ran a quick test for the request roundtrip for 1000 requests in the below scenarios. In the first case, a CF script that dumps CGI variables was used, and in the second, a CFM that loads a large image, dumps now(), and dumps CGI variables was used.

Request Flow	cfdump(CGI) (seconds)	image, now(), cfdump(CGI) (seconds)
Client -> ColdFusion	57.395676	43.312573
Client -> Nginx -> ColdFusion	42.997750	40.502565
Client -> Apache -> ColdFusion	50.277571	41.127564
Client -> Nginx -> Apache -> ColdFusion	46.539902	45.562761

Now, take a call whether or not the last line affects you. If not, the only change you would need to do to the above configuration file, is swap 8501 with 80 (Assuming Apache is running on 80), and configure Apache with ColdFusion.

 

That’s it! Now, if one of you have Nginx in production, do share your experiences about how it fares in comparison to Apache.