In fact it has been proved that it's theorically similar to handle connections with threads or with events. Some runtime allow happily to manage hundred of thousand of concurrent threads. Think of the framework/languages they for telecomunication management.

So one approach or the other is more the opportunity to use an existing good implementation of on way or another than to give a theoretical adventage.

Number of systems call? Who care. Sorry to say that but show some benchmarks if you want to show that Nginx perform better.

I pinned the problem down to using OpenDNS (or indeed any other DNS service that doesn't “Fail” outright when a DNS look-up is done for an externally invisible server name).  

In my case, I would find that for certain networks, the Outlook over VPN would work perfectly, yet on a different network on the same day it would not.

What was happening was that despite having an entry in my hosts file which looked like:

<ip address=”"> server

Windows would always do a DNS look-up.  (this feels like a bug to me).  On networks where the DNS lookup fails (i.e. not OpenDNS or similar), Windows would then go to the hosts file, get the right IP address and Outlook would connect over the VPN without a problem.

On Open DNS, all DNS requests succeed.  What would happen is the DNS query would return the OpenDNS web address, and Outlook would then try to connect to that, and fail.

For some reason, adding the explicit

<ip address=”"> server.companyname.com 

line to the hosts file prevents the DNS look-up from taking place, and makes everything work.</ip></ip>

In my case, the hosts file already had the Exchange server in it, but without the domain name.  i.e. an entry like:
<ip address=”"> server

This wasn't working, with Outlook failing to connect over the VPN.  With a packer sniffer I could see Outlook trying to resolve a full DNS query for server.companyname.com and getting an external IP address, and then trying to connect to that directly, rather than over the VPN (and failing).

I then tried changing the hosts file to the full server name including the domain and it started to work.  i.e.

<ip address=”"> server.companyname.com

This shouldn't work, but it does.  There may be a bug somewhere, but having gotten it to work easier to get on with life….</ip></ip>

The issue has nothing to do with Nginx. As the logs say, you had a permission issue. Anyone with an absolutely basic understanding of Linux could have figured this issue out.

I am running nginx under user “nginx”, and this user is in the group “nginx”. 

I am running PHP as a Fastcgi process and php is running as user “website”, and this user is in the group “website”. 

The website files are located in the directory “/home/website” and the “website” user is the owner of this directory.  

I could execute any PHP file from any subdirectory, but I could not execute/read/write any other file from any other subdirectory other than the /home/website directory because nginx did not have access to those directories and files.

My solution is to set permissions of the subdirectories that I wish to give nginx access to, to 0711 and set the permissions to all of the files in the subdirectories to 0755.  It works perfectly!