Jauder Ho - links and things

After reading Jeff Moser’s excellent article on “The First Few Milliseconds of a HTTPS connection”, I thought I would share my setup for SSL for nginx.

By default, the ciphers used tend to be comparatively weak (for instance, you should disable SSLv2 if at all possible to meet PCI Compliance). For a list of recommended ciphersuites to use, check out this post.

You can test your current site configuration with Benjamin Black’s excellent TLS Report site. It will test a given site and assign a score based on a variety of parameters. For example, Amazon scores a D.

When I was looking at this last year, nginx did not have support for ephemeral keys but Igor Sysoev was able to quickly add this.

  server {
    # port to listen on. Can also be set to an IP:PORT
    listen 443;

    # Turn SSL on. Also disable weaker SSL schemes.
    ssl on;
    ssl_certificate /usr/nginx/conf/certs/dot.com.crt;
    ssl_certificate_key /usr/nginx/conf/certs/dot.com.key;
    ssl_dhparam /usr/nginx/conf/certs/dot.com.dh1024.pem; 

    ssl_prefer_server_ciphers on;
    ssl_protocols SSLv3 TLSv1;
 
    ssl_session_cache shared:SSL:2m;

    # Set the ciphers to use. You may have to fix formatting. 
    ssl_ciphers DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:\
                EDH-RSA-DES-CBC3-SHA:AES256-SHA:DES-CBC3-SHA:\
                AES128-SHA:RC4-SHA:RC4-MD5;
    # ssl_ciphers HIGH:MEDIUM:+TLSv1:!SSLv2:+SSLv3:\
                !ADH:!aNULL:!eNULL:!NULL;

    # set keepalive for ssl connection
    keepalive_timeout 70;

    # Set the charset
    charset utf-8;
    
    # Set the max size for file uploads to 10Mb
    client_max_body_size 10M;

    # sets the domain[s] that this vhost server requests for
    server_name dot.com; 

    # doc root
    root /var/www/dot.com;

    # vhost specific access log
    access_log  /var/log/nginx_access.log  main;

  }

Typically, when you upgrade, there is usually a short downtime while the application is restarted.

However, nginx has come up with an elegant way of upgrading without any downtime by using different signals to manage the master and worker processes. The process is outlined on the nginx wiki.

Essentially, the upgrade happens in the following steps:

1. Send USR2 signal to the existing master process
2. This starts up a new master process and renames the pid file for the old process to nginx.pid.oldbin
3. Send QUIT signal to old master process to shut down master & worker processes

Since the default nginx init script does not account for this, I have added an “upgrade” option to the init file.

Note: Recent versions of the development branch now have a -s switch that can be used to pass signals.

UPDATE: Switched the init file to using kill directly instead of start-stop-daemon as it was generating errors.

It appears that there are quite a few complaints on the forums about Magento being slow and this is probably true with an out of the box installation. There are quite a few things that can be done to improve things and response time in general.

The following shows the before and after times as recorded by Pingdom for http://furoshiki.com/. The initial installation reflected a stock LAMP based installation with average response time of about 9 seconds.

With a switch to nginx as well as tuning of various components, the response time subsequently dropped by over half to about 4 seconds which is in the sweet spot for ecommerce sites.

The following are some of the changes made:

• Switch to using nginx as a front end.
• Set Expires to far in the future
• Utilize PHP FPM.
• Implement APC
• PHP tuning
• MySQL tuning

Before (8.9 seconds):

After (3.9 seconds):

As you can see, the site is now very responsive (buy some furoshiki while you are there). I am investigating additional improvements as traffic increases.

Why does this matter? Surveys have shown that there is a correlation from site response time to sales with higher abandonment rates with a slow site. For further reading, see:

• Are Your Website Response Times Costing You Sales?
• Website Response Time - 4 Seconds
• Site Response Time

As you may know, nginx is a fairly new web server alternative to Apache and rapidly gaining popularity with Rails implementations

Starting with Ezra’s nginx config, I noticed that gzip compression was set to be on for all browsers.

However, this is incorrect as older versions of IE (before IE SP1) do not properly handle gzip compression. Additionally, with the use of larger javascript and CSS files now, the default config configuration may not be sufficient.

The following changes should address these issues. Please let me know if you have any questions.

   # output compression saves bandwidth
  gzip  on;
  gzip_http_version 1.1;
  gzip_vary on;
  gzip_comp_level 6;
  gzip_proxied any;
  gzip_types text/plain text/html text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

  # make sure gzip does not lose large gzipped js or css files
  # see http://blog.leetsoft.com/2007/7/25/nginx-gzip-ssl
  gzip_buffers 16 8k;

  # Disable gzip for certain browsers.
  gzip_disable “MSIE [1-6].(?!.*SV1)”;