Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
This question is not nginx vs apache. I am more interested in the architectural advantages of NGinx over Apache. As I was able to understand -
nginx is an asynchronous, event-driven, web-server which outperforms Apache by a huge margin.
Why is this? Where does Apache fall behind?
There is no single reason why nginx strictly "outperforms" Apache. For many load patterns you may configure Apache so that it handles this load. For some (very busy) load patterns nginx in default configuration can exhibit performance degradations, and can require fine tuning to work right.
However, it has been the experience of many, that nginx actually works "better" out of the box, or with simple tuning. Many systems' performance clearly improved when nginx was installed as a front-end, with Apache moved to back end.
The primary reason is that nginx is event-driven, and contains the state machine which handles the lifecycle of connections. That way, you can have very few "worker" processes, each handling many hundreds or even thousands of connections simultaneously. For Apache you will have to run the same number of child processes (or threads) as the number of connections.
It is obvious that three processes against a thousand processes should be a huge win, at very least.
In particular, nginx easily allows to greatly reduce the load of serving static files (images, Javascript, CSS). Handling each additional connection in nginx is very cheap, so as the static files are usually a majority in terms of number of requests, you get efficient processing.
Also, nginx performance is better for "slow clients". When you have Apache looking straight to the Internet, and clients send requests over (congested) lines, your (fast) server will have to patiently feed the (slow) client, waiting until it consumes the entire response. Thus the Apache child (or thread) cannot do anything useful. Nginx worker, on the other hand, simply keeps this slow connection in epoll set of descriptors, all the while processing other connections.
From the conceptual point of view, you should always try to separate the "classes" of requests, with their own performance profile and demands. E.g., serving small static files is one of such classes; serving dynamic pages is another such class; serving huge static files is yet another. Introducing nginx to your system implicitly handles this separation.
Related
There are several discussions around the web about some "anonymous" benchmarks released by Litespeed Technologies on http2benchmark.org (etc) allegedly showing that their LS servers are faster than Nginx LEMP stacks (apparently, they knowingly disabled FastCGI caching):
https://hostedtalk.net/t/litespeed-servers-publishing-fake-benchmarks/4431
https://www.reddit.com/r/selfhosted/comments/f06vse/litespeed_servers_seem_like_a_marketing_scam_are/
https://community.centminmod.com/threads/is-lsapi-litespeed-faster-than-php-fpm-nginx-etc-or-not.19153/
My question is three-fold:
As far as LSAPI on Litespeed vs PHP-FPM on Nginx is concerned, what would be a "fair" way to compare performance re: processing PHP queries since the environments are different?
Besides the PHP handler, is there any other part of the Litespeed stack that can be accurately benchmarked at the application-level (e.g. LS Cache) instead of the stack?
Have any unbiased third parties compared these two stacks in an accurate fashion?
I'd rather post this as a comment but it's pretty full already up there.
This benchmark routine by Ike Devolder is probably one of the most fair and detailed that I've come across in the past few years comparing Litespeed and Nginx:
https://blog.herecura.eu/blog/2020-06-16-openlitespeed-vs-apache-vs-nginx/
Some of the confusion is re: Litespeed vs. OpenLitespeed, but for this purpose it doesn't really matter since the biggest difference with Nginx is LSAPI, the PHP processor, rather than using PHP-FPM, and since OLS supports the same server-level caching that Litespeed does...
One of the best things about Ike's review is that he doesn't definitively say one is "better" or "faster" and instead talks about different components of either stack, while monitoring resources.
The TLDR for 2021 is probably something like this:
Both Nginx and Litespeed serve static assets extremely well
Litespeed as a stack scales higher than Nginx currently, partially due to HTTP/3 support... but 99% of websites probably will not notice this since we are talking about insane traffic levels, which almost never reach the origin server these days due to things like CDNs or remote MySQL servers, and since HTTP/3 is not fully integrated into the internet yet... in fact, even in Ike's own tests he seems to have tested both internally (not over i.e. UDP) which further reinforces this point since HTTP/3 is UDP-only. However, regardless of protocol, Litespeed does appear to scale to a higher level than Nginx... keep in mind, this is not the same as saying that LS delivers requests "faster" than Nginx, because real world requests at a typical traffic level are probably indistinguishable in terms of speed/response times. It does mean that i.e. a shared hosting environment with 500 cPanel websites would probably scale better using Litespeed... so it makes sense why that seems to be Litespeed's main target.
Litespeed appears to use more RAM memory than Nginx in general
Nginx appears to use a lot more CPU than Litespeed at high traffic levels
TCP (not Unix socks, the Litespeed default) performed a lot better, and this is true for Nginx as well, since it avoids disk I/O... so, using default Litespeed settings is still a bad idea
Anyway, best not to get too detailed, since software changes all the time really. The next version of Nginx will probably support HTTP/3, among other features. I do wish that the Litespeed guys would let the unique quality of their software speak for itself, and chill out on the aggressive (inaccurate) claims being made... but most of their web hosting partners probably benefit from that hype, which is maybe why not many people are questioning the claims being made...
We use Apache with Nginx(as reverse proxy) for more concurrency level because of the way that Nginx handles static contents and use fewer connections something that Apache lacks.
The question now is that is there any difference between the above scenario and using another server for serving static content (css,js,images,etc) with nginX and your primary server with Apache installed?
In my project there are millions of user with avatar,banner and ofcourse photo gallery. Project is nearly ready, and I want to make sure I'm on the right direction. Which scenario is the best?
EDIT:
What would happen if slow clients cause Apache to keep threads busy for longer than needed in the primary server?
One of the main purposes of nginx behind Apache is to handle slow clients to ensure that Apache doesn't have to keep its threads busy for this.
btw, I think it's relevant to the topic http://www.aosabook.org/en/nginx.html
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why do we need apache under Node.js express web framework?
I wonder why I should install a server such as Nginx or Apache with Node.js. I used to think that the server can help me to handle cache control or something more. But I found out that the Connect static middleware already does it, right?
If you don't know why you need Nginx or Apache on top of Node.js, then you don't need it.
Nginx does a few things faster (and in some cases easier to configure) than Node.js: proxying, url rewriting, http caching, redirection, static file serving, and load balancing.
If you experience that your Node.js code for any of these roles are growing complex, or turn out to be performance bottlenecks, it's worth investigating. Until then, no need to bother.
Using stable and solid web server software as front end can bring several advantages. For example, you can use Nginx for load balancing. Furthermore, security risks can be reduced by not presenting your application server directly to the internet.
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.