NGINX vs Apache | TechSNAP 39

NGINX vs Apache | TechSNAP 39

How NGINX stacks up to Apache, and which server is right for the job!

PLUS: The EFF has raised a red flag over the new version of AOL’s instant messenger we’ll share the details on how it’s logging your conversations, and pre-loading your links.

All that and more, in this week’s episode TechSNAP!

Thanks to: Use our codes TechSNAP10 to save 10% at checkout, or TechSNAP20 to save 20% on hosting!

Pick your code and save:
techsnap7: $7.49 .com
techsnap10: 10% off
techsnap20: 20% off 1, 2, 3 year hosting plans
techsnap40: $10 off $40
techsnap25: 25% off new Virtual DataCenter plans
techsnapx: 20% off .xxx domains


Direct Download Links:

HD Video | Large Video | Mobile Video | MP3 Audio | OGG Audio | YouTube

Subscribe via RSS and iTunes:


Show Notes:

StratFor database full of incredibly weak passwords

  • A total of over 860,000 password hashes were released in successive leaks
  • Researchers at TheTechHerald were able to crack over 80,000 of the passwords in under 5 hours
  • To increase their success rate, TheTechHerald uses existing word lists of common passwords, including those from Facebook, MySpace,, Hotmail, and Gawker database exposures
  • Horribly insecure passwords such as 123456, 11111111, qwerty, Robert, James, 19871987, etc were found in great number
  • StratFor and its customers should have been using far more secure passwords, this should have been enforced by basic password policies that prevent passwords shorter than 9 characters and passwords that contained insufficient entropy (not enough unique characters, no non-alpha characters, etc)
  • While StratFor failed to force its customers to use strong passwords (in fact, it allowed single character passwords), and failed to cryptographically hash those passwords, it still shows a surprising lack of password management skills on the part of of the users
  • Due to the weak hashing (straight single round md5), even passwords up to 10 characters were cracked in great numbers
  • Many of the users of the StratFor system were from organizations and institutions that are considered high security, and from which you would expect better password behaviours
  • Full research methodology and breakdown

EFF warns users about privacy issues with the new AIM chat client

  • The EFF is warning users not to upgrade to the latest version of the AOL Instant Messenger client due to some disturbing changes
  • The new client logs all conversations by default, worse, the logs are stored on AOLs servers. The goal of this feature is to have your chat history follow you from device to device, however it has serious security and privacy implications, as well as legal implications if such logs are subpoenaed by law enforcement. With instruments such as ‘National Security Letters’, the government can gain access to those lows, and AOL may be prevented from warning you that your private IM chats, are no longer private
  • The AIM client also scans all chat sessions for links, and pre-loads the links, while this seems like a handy feature, it is definitely a security issue, but also a privacy issue as AOL now has a list of URLs you are likely to have visited. The EFF also pointed out to AOL that the links may contain private authentication information, or be one-time-use links, such as activation links or unsubscribe links, which if prefetched, could have unintended consequences to the befuddlement of the users
  • Once you have logged in once with the new version, your account is opted in to the logging option without your knowledge or consent, there is currently no way to disable logging
  • IM is one of the most popular methods of spreading browser borne infections, because of users’ propensity for clicking links shared by their friends. These viruses then repeat the link to everyone on your contact list, spreading further and damaging your credibility
  • AOL has agreed to examine the EFFs recommendations

Lilupophilupop SQL Injection attack spreading rapidly

  • The lilupophilupop SQL injection attack, originally identified by researchers at SANS ISC in early december, when it had infected a few 1000 websites, has now spread to over a million sites
  • The attack targets sites based on Microsoft’s IIS/ASP architecture with MS SQL
  • The goal of the attack is to hijack traffic, redirecting visitors to the victim website to pages for fake AV and other scareware
  • Such an attack could further compromise the visitors machine if it were to take advantage of the known Java and Flash exploits that surface on a regular basis

Nginx overtakes Microsoft as No. 2 Web server

  • NGINX, the BSD licenses high performance web server has taken the number two spot from microsoft for having the most active websites
  • While IIS is used on 84 million sites, to NGINXs 56 million, when you consider only active sites, both come in at 22 million domains, NGINX edging out IIS by less than a hundred thousand
  • NGINX was also the only major web server experiencing growth during the January survey
  • The netcraft servey queried 582 million sites for january, and considered 175 million of those to be active
  • Netcraft Survey – January 2012


Q: Apache vs. nginx?
A: NGINX and Apache both have their strengths and weaknesses, and therefore each has their place depending what your requirements and goals are.

NGINX is fast and light, designed to serve static content as quickly as possible. Out of the box, it lacks the ability to do any type of interpretation or CGI. NGINX is however a great load balancer, with the ability to handle requirements such as ‘sticky’ backends, last resort backends, and unfair load balancing. NGINX is event driven, so uses a small number of single threaded workers, which allows it to easily meet the C10K requirement (10,000 concurrent clients), using only 10mb of ram.

Apache is far more powerful and versatile. Apache has a number of different ‘mpm’s (Multi-Processing Modules). The most common is prefork, where apache will start a number of worker processes that then wait for incoming client connections. When the number of idle workers gets to low, Apache starts more in an attempt to ensure that there is always a worker ready to handle the next request, rather than making that user wait while the worker starts up. The issue with this approach is that each worker must load all of the the capabilities of the web server, for example, things like PHP and webdav. This means that, even a worker which is only going to server a simple image, requires the memory and resources of a worker that is processing a much more complex request. There is a limit to how many workers can be running at once, due to limited resources on the machine such as RAM. If the Apache MPM is not tuned with a proper MaxClients setting, to limit the number of workers that are started, the server can quickly enter ‘swap death’, as it is constantly paging memory in and out of swap to try to service the requests, slowing down the rate at which the requests can be served, further increasing the number of pending requests. Also, the Apache worker is not free to start work on the next request, until the client has received the response, and closed the connection. This means that ‘keep alive’ connections, which a great performance improvement, can also reduce the available capacity of the server, as many workers are tied up simply waiting to see if there will be an additional request.

NGINX is however not incapable of dealing with things like PHP. NGINX is designed as a reverse proxy, allowing it to pass off requests that it cannot handle itself, to the appropriate server that can handle them. For most items, there are 2 major options; FastCGI (works much like the apache mechanism described above, a number of php, perl or other processes preforked and waiting to answer requests, however a major difference is that these workers never receive simple requests for things such as image, NGINX handles those internally); The other option is to proxy the requests to another server, such as an Apache server, which will then handle the more complex requests. An advantage to this solution is that NGINX will receive the response from apache (usually over localhost or an internal LAN) very quickly, freeing that Apache worker for the next request, while NGINX handles returning the response to the client at little to no cost due to the event driven nature of NGINX.

Some notable shortcomings of NGINX: For performance and security reasons, NGINX does not support .htaccess files, all configuration must be done in the server config file. Extensive rewrite rules are possible, but are done in a very different format from standard apache mod_rewrite rules. There are currently no webhosting control panels that support NGINX.

While both servers are very useful, if you need versatility or generalized solution, value ease of use, or have to support many customers, Apache is likely the better solution. If you have a very busy site, and you need to get the most out of your hardware, NGINX is quite likely the right solution for you. Even just placing an NGINX in front of your apache server can greatly increase performance.

Q: Common Questions!

We would love to answer common sysadmin questions, in fact, that is what I am doing right now :p. Just send them in to and we’ll try to keep throwing knowledge at you. Developer questions are a bit more complicated, neither Chris nor I are developers, although we can answer a lot of DevOps questions. Send it in anyway, and we’ll see if we can come up with an answer for you.

Server to busy pages, such as the failwhale, are static, and so require little to no resources to return to the user. If you are using a server like NGINX, you can serve 1000s of failwhale pages per second from a laptop without issue. Most sites big enough to need an ‘overloaded’ page have a dedicated set of web servers or load balances infront of the actual application servers that run the site, and it is these front end servers that return the overloaded page, when they cannot find a backend server that is available to serve the user request.

For your second question, you’ll need to be more specific. Email us back with a use case, and I’ll try to walk you through some potential solutions.


Question? Comments? Contact us here!