For a SaaS running on Node.JS, is a web-server necessary?
If yes, which one and why?
What would be the disadvantages of using just node? It's role is to just handle the CRUD requests and serve JSON back for client to parse the date (like Gmail).
"is a web-server necessary"?
Technically, no. Practically, yes a separate web server is typically used and for good reason.
In this talk by Ryan Dahl in May 2010, at 37'30" he states that he recommends running node.js behind a reverse proxy or web server for "security reasons". To elaborate on that, hardened web servers like nginx or apache have had their TCP stacks evolve for a long time in terms of stability and security. Node.js is not at that same level yet. Thus, since putting node.js behind nginx is easy, doesn't have many negative consequences, and in theory increases the security of your deployment somewhat, it is a good choice. At some point in time, node.js may be deemed officially "ready for live direct Internet connections" but wait for Ryan/Joyent to make some announcement to that effect.
Secondly, binding to sub-1024 ports (like 80 and 443) requires the process to be root. nginx and others automatically handle binding as root and then dropping privileges to a safer user account (www-data or nobody typically). Although node.js has system call wrappers in the process module to drop root privileges with setgid and setuid, AFAIK other than coding this yourself the node community hasn't yet seen a convention emerge for doing this. More on this topic in this discussion.
Thirdly, web servers are good at virtual hosting and in general there are convenient things you can do (URL rewriting and such) that require custom coding in node.js to achieve otherwise.
Fourthly, nginx is great at serving static files. Better than node.js (at least by a little as of right now). Again as time goes forward this point may become less and less relevant, but in my mind a traditional static file web server and a web application server still have distinct roles and purposes.
"If yes, which one and why"?
nginx. Because it has great performance and is simpler to configure than apache.
Related
Looking at the CKAN deployment documentation, there are several web server options:
Apache with the modwsgi Apache module proxied with Nginx for caching
Apache with the modwsgi Apache module
Apache with paster and reverse proxy
Nginx with paster and reverse proxy
Nginx with uwsgi
I'm wondering what the merits are of using Apache/modwsgi over Nginx/uwsgi, and how much value Nginx's proxying adds.
The core question, I guess, is if I wanted to avoid using two separate web servers in a single installation, what should I consider when choosing one or the other?
The CKAN Tech Team document one particular config: apache/modwsgi + nginx reverse proxy. They encourage people to use that, so that when difficulties occur we can fix them as a community.
I'm not clued up enough to give technical arguments between uwsgi and modwsgi. I think there are some CKAN sites on uwsgi and it being more modern there may be some technical advantages. However the installs I've worked with have mostly been apache/modwsgi + nginx reverse proxy. That's probably more down to familiarity and the blessing of the CKAN tech team than anything else.
However I believe nginx is better than apache2 for SSL/TLS termination. We found it was far simpler to configure SSL/TLS, with plenty of new best practices to keep up with in the past few years. And last time I looked several years ago there was an argument that the asynchronous design avoided e.g. slow loris attacks. So I think having nginx on your front-end makes a lot of sense.
You suggest having two HTTP servers is too much, but I think nginx is pretty low overhead and isn't usually a concern.
paster is a toy - no-one uses it for servers.
I am choosing a better web server for big SPA application with dozens of JS and css files. With HTTP/2 we are now able to not merge them into two big files (3 MB for JS), that take pretty long time to load when on slow connection. But which server is better for the new HTTP/2 paradigm?
Nginx was designed to solve http/1 problems, and it's advantage was better serving numerous connections, with HTTP/2 there is only one connection for all the files, so the feature seems redundant now. What do you think, what can you advise me?
That's a very subjective question, and probably not a good fit for StackOverflow so imagine this will get closed. But here's my two cents...
Full disclosure: I primarily use Apache.
For a start let's address one of your incorrect points: Nginx wasn't designed to solve HTTP/1 problems. Nginx was designed to solve some of the scalability problems of previous web servers by being based on an asynchronous, event-driven model. Under HTTP/2 there should be less connections per client, which you could argue makes scalability less of an issue as each client uses only 1/6th of the resources they did previously - but that's probably a little simplistic. Apache has an event-driven MPM module for years now too (though often not turned on by default in case of any thread unsafe PHP applications - but this would also be a problem with Nginx!). This brings them more back in line, though there's still a lot of debate about this and many say Nginx is still faster. In my experience, unless you are dealing with truly huge volumes (in which case you should be looking at CDNs, load-balancers and cache accelerators), few will ever notice the difference between Nginx and Apache. This is especially true when downstream applications and systems come into play - a slow PHP application will quickly negate any performance or scalability issues at the web server level.
Anyway, back to your main question:
For HTTP/2 support, my choice would be Apache over Nginx. It has had better HTTP/2 support for some time. Nginx only added HTTP/2 Push support in early 2018 for example, whereas Apache has had that for a number of years now. Apache also supports a PushDiary (based on the now-abandon Cache-Digests proposal) to prevent pushing resources that have already been sent, supports 103 Early Hints for pushing early, and push prioritisation options. Moving on from HTTP/2 push, Apache also supports using HTTP/2 in proxy mode (though it's still marked as experimental and the usefulness of this is questionable at the moment), and HTTP/2 over HTTP (h2c - though again usefulness is questionable since browsers do not support this). I also find the main developer of the Apache HTTP/2 implementation very responsive on the GitHub page for the mod_http2 module (included as part of core Apache since 2.4.18 and no longer marked as "experimental" since 2.4.26).
On the flip side, I understand that Cloudflare uses a customised Nginx based web server, and they have HTTP/2 push for over a year now (it was them that backported this implementation to Nginx). So, given Cloudflare's scale, that speaks volumes to the implementation of that though not sure how customised it is from the core Nginx code.
There is also a HTTP/2 conformance Testing tool available and when I ran this against some common HTTP/2 servers (for a book I wrote on the subject btw) I got the following results which clearly shows Apache as the most compliant with the spec:
Now to be fair, most of the causes of errors are in not responding correctly to bad requests, that in a perfect world should never be sent anyway so aren’t that important. But still, we don’t live in a perfect world, and error checking is an important part of technology so I for one would certainly prefer the more compliant server. Similarly as pointed out in the comments below, the tool and web servers themselves, can be subject to race conditions and other problems which may incorrectly report errors.
Ultimately you are best choosing the implementation you are most comfortable with. The general feel has always been that Nginx is lighter and easier to configure, but on the flip side perhaps isn't as fully featured as Apache because of that. HTTP/2 support seems to continue that theme. If you want to play with upcoming HTTP/2 features then, to me, Apache definitely has the edge at the moment (though nothing to say that won't change in the future). However, for the basic use cases of HTTP/2, they probably can be considered similar. Even HTTP/2 Push is not used much yet, and there are serious concerns it could degrade performance if not used appropriately or due to implementation issues, which is probably why it has not been a priority for Nginx and while they only implemented it later.
I am learning Erlang and found out it contains httpd which I managed to configure and make serve to my needs for creating an API service.
I know there are other solutions like mochiweb and Cowboy which must be undoubtedly great choice but I want to begin lean and bare bones.
When I decide to release my project, will it be a good plan to use Erlang's httpd regarding performance and HTTP features like HTTPS, HTTP/2, performance, or should I choose another server?
httpd is powerful webserver and a perfectly valid choice for production, as long as it fits your needs. I think the main reason to go for other alternative webservers is that you find that some functionality is missing in httpd that you find somewhere else. For example, I don't think httpd supports websockets, however websockets are supported by for instance cowboy and yaws.
When I decide to release my project, will it be a good plan to use
Erlang's httpd regarding performance and HTTP features like HTTPS,
HTTP/2, performance, or should I choose another server?
I can't find any benchmarks comparing httpd with the other solutions that you mention, like cowboy and mochiweb, but I've not heard any complaints about the peformance of httpd and I would guess that it's as good as cowboy and mochiweb for production. The fact that it's shipped with the erlang language is a good reason for assuming that the code is performant and battle-tested, if you want to go in depth you can always:
look at the source: https://github.com/erlang/otp.
Make your own benchmarks.
I currently have one server with nginx that reverse_proxy to apache (same server) for processing php requests. I'm wondering if I drop apache so I'd run nginx/fastcgi to php if I'd see any sort of performance increases. I'm assuming I would since Apache's pretty bloated up, but at the same time I'm not sure how reliable fastcgi/php is especially in high traffic situations.
My sites gets around 200,000 unique visitors a month, with around 6,000,000 page crawls from the search engines monthly. This number is steadily increasing so I'm looking at perfomrance options.
My site is very optimized code wise and there isn't any caching (don't want that either), each page has a max of 2 sql queries without any joins on other tables, indexes are perfect as well.
In a year or so I'll be rewriting everything to use ClearSilver for the templates, and then probably use python or else c++ for extreme performance.
I suppose I'm more or less looking for any advice from anyone who is familiar with nginx/fastcgi and if willing to provide some benchmarks. My sites are one server with 1 quad core xeon, 8gb ram, 150gb velociraptor drive.
nginx will definitely work faster than Apache. I can't tell about fastcgi since I never used it with nginx but this solution seems to make more sense on several servers (one for static contents and one for fastcgi/PHP).
If you are really targeting performance -and even consider C/C++- then you should give a try to G-WAN, an all-in-one server which provides (very fast) C scripts.
Not only G-WAN has a ridiculously small memory footprint (120 KB) but it scales like nothing else. There's work ahead of you if you migrate from PHP, but you can start with the performance-critical tasks and migrate progressively.
We have made the jump and cannot consider to go back to Apache!
Here is a chart showing the respective performances of nginx, apache and g-wan:
g-wan.com/imgs/gwan-lighttpd-nginx-cherokee.png
apache does not seem to lead the pack (and that's a -Quad XEON # 3GHz).
Here is an independent benchmark for g-wan vs nginx, varnish and others http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwan/
g-wan handles much more requests per second with much less CPU time.
NGINX is the best choice as a webserver now a days.
The main difference between Apache and NGINX lies in their design
architecture. Apache uses a process-driven approach and creates a
new thread for each request. Whereas NGINX uses an event-driven
architecture to handle multiple requests within one thread.
As far as Static content is concerned, Nginx overpasses Apache.
Both are great at processing Dynamic content.
Apache runs on all operating systems such as UNIX, Linux or BSD and
has full support for Microsoft Windows & NGINX also runs on several
modern Unix-like systems and has support for Windows, but its
performance on Windows is not as stable as that on UNIX platforms.
Apache allows additional configuration on a per-directory basis via
.htaccess files. Where Nginx doesn’t allow additional configuration.
Request Interpretation-Apache pass file System location. Nginx
Passes URI to interpret requests.
Apache have 60 official dynamically loadable modules that can be
turned On/Off.Nginx have 3rd Party core modules (not dynamically
loadable).NGINX provides all of the core features of a web server,
without sacrificing the lightweight and high-performance qualities
that have made it successful.
Apache Supports customization of web server through dynamic modules.
Nginx is not flexible enough to support dynamic modules and loading.
Apache makes sure that all the website that runs on its server are
safe from any harm and hackers. Apache offers configuration tips for
DDoS attack handling, as well as the mod_evasive module for
responding to HTTP DoS, DDoS, or brute force attacks.
When Choose Apache over NGINX?
When needs .htaccess files, you can override system-wide settings on
a per-directory basis.
In a shared hosting environment, Apache works better because of its
.htaccess configuration.
In case of functionality limitations – use Apache
When Choose NGINX over Apache?
Fast Static Content Processing
Great for High Traffic Websites
When Use Both of them -Together
User can use Nginx in front of Apache as a server proxy.
Apache has been the de facto standard web server for over a decade, but recent years have brought us web servers that consume less RAM and handle many more requests per second using fewer threads and asynchronous i/o. In my opinion, I also find the configuration of these servers to be more straightforward and minimal.
Why do people use Apache when asynchronous servers are so much more lightweight? Is there any clear benefit?
Ubiquity, "good enough", and familiarity.
Apache's .htaccess provides flexible configuration. This allows users on a shared host to customize certain settings of an apache without having to alter the core apache configs.
It is the standard server bundled in typical LAMP setups, although, many services use other web servers for in conjunction (like static files, video streaming, etc.).
Since Apache is popular, it's easy to find a solution to any problems.
Other than that, other solutions would probably be better.
Apache IS asynchronous if you want it to be with the Event MPM. Unlike Nginx and Cherokee, etc., it is not the default.
Apache's made some important moves in 2.4 so it can be more competitive — esp. as it pertains to serving static requests using the Event MPM. Various benchmarks don't speak well of this, but:
It's very difficult to ascertain how much slower Apache is in 2.4 because Apache's out of the 'box' configuration is detrimental to performance and legacy holds it back in some respects. For example, .htaccess requires stat/reading a multitude of files on every request, which may include many rules and regexes. Nginx doesn't have this problem, nor does Cherokee. Litespeed has .htaccess support in Apache's style, but only if you pay for it. Most benchmarks don't turn off features like those.
Most of the benchmarks are also ridiculous in that they're run locally and over a GbE network or similar. A real web server has to cope well with various speeds, including 3G phones. It could be that Apache's performance is better in the real world.
I doubt it.
Nginx is still faster, and I might choose it, but Apache isn't asleep.