You seem to have a few misconceptions which I feel needs to be addressed.
First of all, mod_php is only marginally faster, all my tests have shown that the difference is so minuscule that it's not worth factoring in. I also doubt that the security aspect is relevant to you as you seem to be looking at a dedicated server and mod_php really only has an advantage in a shared environment - in fact, in a dedicated environment php-fpm will have the advantage as PHP and your web server now runs as different processes, and that's not even factoring in the awesome logging options in php-fpm such as slow log.
If the world was black and white I'd say go with a pure nginx setup and compile php with php-fpm. More realistically if you already have Apache working then make nginx a reverse proxy to apache and you might save a few hours of setup time and the difference in performance will be tiny.
But lets assume the world is black and white for a second, because this makes for far more awesome setups. You do nginx + php-fpm for your web server. To solve the uploads you use the upload module and upload progress module for nginx. This means that your web server accepts the upload and passes the file path onto PHP when it's done, so that the file doesn't need to be streamed between nginx and PHP via fastcgi protocol, sweet. (I have this in a live setup and it's working great, btw!)
For user downloading you use nginxs x-send-file-like feature called x-accel-redirect, essentially you do your authentication in PHP and set a header which nginx picks up on and starts transfer that file. PHP ends execution and your web server is handling the transfer, sweet! (Again, I have this in a live setup and it's working great)
For distributing files across servers or other long running operations we realize that PHP isn't really best suited for this, so we install gearman, which is a job server that can distribute jobs between workers on different servers, these workers can be written in any language. Therefore you can create a distribute worker and spawn 5 of them using a total of 200 KB of memory instead of the 100 MB PHP would use. Sweet. (I also have this running live, so it's all actually possible)
In case you haven't picked up on it yet, I think many of your problems aren't related to your web server at all, you just think that way because Apache forces it to be related to your web server due to it's structure, often there are far better tools for the job than PHP and PHP is a language which knows this and provides excellent options to off-loading work without ever leaving PHP.
I'd highly recommend nginx, but I also think you should look at other options for your other problems, if you have a scaling or performance problem then feel free to write me. I don't know if you can send messages through here but otherwise write me at martin@bbtn.us as I don't stalk server fault for anything not tagged with nginx. :)
I think it is useful to do this.
nginx has a lot of code to shovel files efficiently from the disc to the network socket in a non-blocking way. It does this much more efficiently than node.
Of course, if you're not doing much static content serving then it might not be useful.
But nginx can also load balance over multiple node servers, so that's another potential advantage. Your app has to be written to be scalable like that though.
Best Answer
Having just completed an app involving lots of nginx reverse proxying, I would be more inclined to go with either your second or third option. ...or maybe something slightly different. Lets break it down to individual points to consider:
Static Files
For serving static files (for either the website or the app), node and nginx are the clear choices as they don't fork themselves for each new request like Apache does. Node is faster than nginx at serving static files, but depending on the amount of traffic you'll see, this might not be a meaningful difference.
I would choose nginx as the public-facing server and reverse proxy requests to other things as necessary. Even though it is slightly slower than node at serving static files, its flexibility and ease of configuration make up for it. PHP, if you choose to use it, is faster (configured properly) with nginx than with Apache, and nginx's configuration files are similar to Apache's but more concise. It shouldn't be too foreign-looking when you dive into it.
SSL
If you are planning to use SSL, save yourself the trouble now and get the latest version of nginx so that you can utilize the latest version of Google's SPDY module. Currently, the latest version is 1.7.3. Some package managers are behind quite a bit, so you may have to compile from source. If this is the case, make sure that the
--with-http_spdy_module --with-http_ssl_module
flags are used, among others. Here is a guide for that as well as setting up the configuration files to use SPDY.Because all your requests go through nginx and a single domain name, you only have to set up SSL in one place. Any reverse proxied requests do not need to be over HTTPS because they happen internally. If you make node.js run your app, you just have to make sure it only listens on localhost and doesn't serve external requests directly.
Application
Node is a good choice for the application code and the long polling that you wish to accomplish. It is also fairly straightforward to proxy these long polling requests through nginx. With these two nginx options...
... you can adjust the timeout of requests. You will want to make sure your application code puts an end to the requests before nginx does. Otherwise, you will get a
504 Gateway Timeout
instead of a200 ok
. If the nginx timeout is set to 60 seconds, you should end and restart a long polling request every 55 seconds or so.Website
If you aren't set in stone with using PHP, node.js or a static site generator written in node.js could also work for your needs. Docpad is one that I use, but there are many great options. Node packages like Grunt make deployment automation easy. A few of the things I use it for are HTML, CSS, and JavaScript minification and cache busting.