provides software and services that enable enterprises
Live Chat 1-888-673-6564

Open Source Software Technical Articles

  • Home
  • Search
  • Source Code Scanning Tools
  • Products and Support
  • Services
  • Cloud Services
  • Open Source Training
  • Enterprise OSS Blog
  • Wazi Technical Blog
  • About Wazi
  • Attributions and Licensing
  • Supply Chain Compliance
  • How to Contribute
  • Contributors
  • Resources Library
  • Partners
  • Customers
  • Community
  • Company
  • Careers
  • News and Events
  • Contact Us

Subscribe to Wazi by Email

Your email:

click-here-to-chat-with-an-online-representative


Enterprise Developer Support 24 x 7 for Apache, CentOS, Tomcat, PostSQL and more. Get a Support Quote by clicking here!


Latest Posts

  • Build your own custom modules for Drupal 7
  • CentOS system administration using text-based user interfaces
  • Quickly create custom software packages with FPM
  • More easy RSS for your websites via Google and Yahoo! APIs
  • Get RSS for your website using jQuery and PHP
  • JSF tip: How to create bookmarkable pages
  • MySQL Workbench simplifies MySQL management tasks
  • Use Perl to enhance ModSecurity
  • The secret to great reporting with Drupal 7
  • A more colorful LibreOffice unveiled

Connect with Us!

Current Articles | RSS Feed RSS Feed

Add a Nginx Reverse Proxy to Your LAMP Setup

Posted by Manolis Tzanidakis on Wed, Aug 31, 2011
  
Email This Email Article  
Tweet  
  

Apache is a reliable HTTP server that still holds more than 65% of the web server market, according to Netcraft. Unfortunately, Apache was not designed with performance or scalability in mind. While alternative solutions might be more efficient, switching is not always the best option. But that doesn't mean you don't have other alternatives to improve your web server's performance.



Switching away from Apache can be more trouble than it's worth. Almost all popular web applications – including content management systems (CMS) such as WordPress and Drupal – officially support only Apache servers. This can cause headaches for admins of other web servers. Most CMSes use .htaccess files for URL rewrite rules to create pretty permalinks or to set other directory-specific server options on the fly without accessing the main server configuration files. Alternative servers lack direct support for .htaccess files and Apache configuration directives, so you need to manually recreate the .htaccess in each virtual host configuration. This can be time-consuming, especially if you host a number of websites. Plus, each time a website's users or developers need to change an option they must contact a server admin. Another problem is that some useful features, such as bandwidth consumption monitoring, are typically available only for Apache through third-party modules, and all popular hosting control panels support Apache exclusively. Finally, switching to another web server means learning a new product and creating a new setup, with a corresponding investment in time and money.



Rather than give up Apache, you can speed up your current HTTP server while keeping your current setup (almost) intact by installing a reverse proxy server in front of it. A reverse proxy fetches resources from one or more servers and returns them to the client as if they originated from the proxy server itself. Apache can act as a reverse proxy with the mod_proxy module, but there is no actual benefit to running mod_proxy on the same system the Apache web server runs on, plus it consumes more system resources. Therefore, for this setup, we will use an alternative web server, nginx, which is lighter and more efficient. With this approach you can have Apache serve all dynamic content and nginx handle all static files without consuming lots of system resources, combining the benefits of both servers without changing the whole infrastructure.


19a98812-f823-48dc-841e-bf029c63c6d7

Nginx Installation and Configuration


Debian and Ubuntu users can install the nginx package right off the official repositories. No official package is available for CentOS, but if you enable the EPEL repository you can install nginx with a regular yum install nginx.



Stop the nginx server if it was started automatically by the package manager and create a new nginx.conf configuration file – installed in /etc/nginx by default – by pasting the following and adjusting the paths to those of your installation:




user apache; #change to the same user apache runs as
worker_processes 2; #change to the number of your CPUs/Cores
worker_rlimit_nofile 8192;

error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;

events {
worker_connections 1024;
use epoll;
accept_mutex off;
}

http {
server_names_hash_bucket_size 64;
include /etc/nginx/mime.types;
default_type application/octet-stream;
access_log /var/log/nginx/access.log;
sendfile on;
tcp_nopush on;
keepalive_timeout 65;

# reverse proxy options
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

# gzip compression options
gzip on;
gzip_http_version 1.0;
gzip_comp_level 6;
gzip_min_length 0;
gzip_buffers 16 8k;
gzip_proxied any;
gzip_types text/plain text/css text/xml text/javascript application/xml application/xml+rss application/javascript application/json;
gzip_disable "MSIE [1-6]\.";
gzip_vary on;

# include virtual hosts configuration
include /etc/nginx/virtual.d/*.conf;
}


Nginx should run as the same user Apache runs, to avoid file permission problems. Replace apache with the Apache user of your setup – for instance, www-data in default Debian and Ubuntu installations. Besides the proxy setup this configuration file includes some generic performance tuning, such as use epoll as the event model method, which works effectively on Linux 2.6+ kernels. This works in tandem with the next line, accept_mutex off, to improve performance a bit more. Enabling sendfile allows nginx to use the kernel's sendfile support to send files to the client regardless of their contents. This can help with large static files, such as images, that have no need for a multiple request/confirmation system to be served. Enabling gzip compression for static files can make a big performance difference. The lines starting with gzip enable compression for common web files, such as .css and .js files, on supported browsers. You can find more information about these options, as well as the complete documentation for nginx, on the project's wiki.



Create the /etc/nginx/virtual.d directory and in it create a file named DOMAIN.TLD.conf for each virtual host you have defined in Apache, with the following content:




server {
listen 80;
server_name DOMAIN.TLD www.DOMAIN.TLD;
access_log off;
error_log off;
location / { proxy_pass http://127.0.0.1:8080; }
location ~* ^.+\.(htm|html|jpg|jpeg|gif|png|ico|css|zip|tgz|gz|bz2|pdf|odt|txt|tar|bmp|rtf|js|swf|avi|mp4|mp3|ogg|flv)$ {
expires 30d; #adjust to your static content's update frequency
root /srv/DOMAIN.TLD/html;
}
}


Replace DOMAIN.TLD with the actual domain name and /srv/DOMAIN.TLD/html with that domain's public HTML directory. Also add or remove file extensions that represent your static content; these files will be served by nginx.



Apache Configuration



Since nginx now acts as the front-end web server – waiting for requests on port 80 – you need to configure Apache to listen on a different port (8080 in this case) and preferably only on localhost. On Debian and Ubuntu systems open the file /etc/apache2/ports.conf and change the line Listen 80 to Listen 127.0.0.1:8080. On CentOS the same changes should be applied to the /etc/httpd/conf/httpd.conf file. Regardless of your distribution, if you use name-based virtual hosts you should have a line NameVirtualHost *:80 in the same file. Change that to NameVirtualHost *:8080.



If you have configured Keep-Alive support in Apache you should disable it since it is already enabled in nginx. Change KeepAlive On to KeepAlive Off in /etc/httpd/conf/httpd.conf (CentOS) or /etc/apache2/apache2.conf (Debian/Ubuntu). You can also disable the mod_deflate module since nginx already provides gzip compression. A good practice is to disable all unused Apache modules to reserve more system resources.



Both servers should start now without problems. If either one fails to start, check your configuration with nginx -t and apachectl configtest (or apache2ctl configtest in Debian/Ubuntu).



At this point if you check the Apache access log files you should see that all incoming requests are coming from 127.0.0.1. To fix this you need to install mod_rpaf, the reverse proxy add forward module for Apache. Debian and Ubuntu users can install the libapache2-mod-rpaf package and restart Apache. On CentOS you need to install the module from source. Additional required packages are httpd-devel and gcc. After grabbing and unpacking the current version (0.6 at the time of this writing) you should type /usr/sbin/apxs -i -c -n mod_rpaf-2.0.so mod_rpaf-2.0.c in the source directory. Then create the file /etc/httpd/conf.d/mod_rpaf.conf with the following content:




LoadModule rpaf_module modules/mod_rpaf-2.0.so

<IfModule mod_rpaf-2.0.c>
RPAFenable On
RPAFsethostname On
RPAFproxy_ips 127.0.0.1
</IfModule>


Debian users should also check in /etc/apache2/mods-enabled/rpaf.conf that the line RPAFproxy_ips looks exactly like the CentOS example above. After restarting Apache your access logs should show the correct client IP addresses, but also contain less information than before. This is normal, because all static files are now served by nginx.



If you use a log monitoring or visitor analysis program you should change the access_log line in the nginx virtual hosts configuration to log to actual files, and periodically merge those files with the Apache access logs before having them parsed by the analytics program.



After enabling mod_rpaf you should have no problem with CMS plugins that use the client IP address, such as Akismet for WordPress. To further improve the performance of your hosted CMS installations you should also use a caching plugin such as W3 Total Cache for WordPress and convert dynamic pages to static HTML, which allows them to be served directly by nginx and minimizes database access. Another option is to add caching to the nginx reverse proxy; you can learn how to do that from the nginx documentation.



This setup might not be as lightweight as straight nginx (with PHP-FPM) but is comparable in performance and easier than migrating away from Apache altogether. With it, your hosted websites should scale to serve many more visitors than with a standard LAMP setup, without dumping Apache or upgrading your hardware.

Follow @openlogic
Follow @CloudSwing

This work is licensed under a Creative Commons Attribution 3.0 Unported License
Creative Commons License.Follow @openlogic
Follow @OSCloudServices

This work is licensed under a Creative Commons Attribution 3.0 Unported License
Creative Commons License.
Tags: Linux, Apache, CentOS, Technical, Drupal, Tutorial, WordPress, GCC, Nginx, LAMP

Comments

Currently, there are no comments. Be the first to post one!
Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics

Loading...
Error sending email
Email sent successfully

Email article
Email To : 
Your name : 
Message : (maximum 200 characters)
Home | Search | Source Code Scanning Tools | Products and Support | Services | Cloud Services | Open Source Training | Enterprise OSS Blog | Wazi Technical Blog | Resources Library | Partners | Customers | Community | Company | Careers | News and Events | Contact Us
Products
OpenLogic Exchange (OLEX)
License Compliance Module
OSS Discovery
OSS Deep Discovery
OpenUpdate
Services
Open Source Support
CentOS Support
Scanning & Compliance
Open Source Training
Professional Services
Solutions
Support & Indemnification
Open Source Governance
Open Source Scanning
Open Source Provisioning
Consulting & Training
Contact Us
1-888-673-6564


© 2013 OpenLogic, Inc. All rights reserved.
Site Map  |  Privacy Policy