nginx produces four times more traffic than node-http-proxy - node.js

we are using node-http-proxy for a while and it works fine. But as our system grows bigger, we want to move to nginx.
We consume about 100 request per second at the moment, which produce an outgoing traffic of about 1mb/s.
Our tests with nginx (same amount of requests, same backend servers and same responses) produce an outgoing traffic of about 4mb/s.
We checked the headers, because that could have been the only difference in the response, but the headers didn't change that much.
Does anyone have an idea what else could produce this traffic increase?
Thanks, Kim
EDIT:
We don't use clustering, they are just dumb reverse proxies. Requests from domain A go to server A, domain B to server B, ...
We did tests in our production environment, so the backend servers stayed the same during tests, just the proxies changed.

We found out what happens: The old node.js server doesn't send all the required ssl certificates. The nginx sends all certificates (intermediate, etc.) with every request.

Related

Throttling only for users, Skip throttle for frontend server and getServerSideProps

I'm developing an app with NestJs where I'm using throttle module for banning abusive requests.
One thing that I couldn't find a clear answer is that if it's going to block abusive requests (for example, more than 20 requests per minute) will it also block the frontend requests made by nodejs server?
I mean getServerSideProps will make a request in every render. If our website has more than 100 visitors per minute, what will be happened in this situation? Considering that
Frontend and backend projects both are on same server with same IP
They are hosted on different servers with different IP addresses
Your suspicion is valid because #nestjs/throttler does not differentiate between local and remote requests so yes your NextJs server will be blocked quickly.
I'd suggest you to use reverse proxies instead which are more mature and also does not check local requests.

Redirect all requests from one server to another

I have two servers, Server 1 (A Windows Server VPS) and Server 2 (A Linux VPS).
Both servers are running NodeJS API using PM2 without anything like apache or nginx or whatever.
What I want is to redirect all requests from Server 1 to Server 2 because I want to shut Server 1 down after a while.
Server 1 address: www.pharmart.sy
Server 2 address: www.pharmartco.com
I don't want to redirect using the res.redirect method because that would break my application.
The application is a Mobile Application that's why I don't want to use the res.redirect method, and I have the link to the server hardcoded in the app so I need to upload another version of it in order to change the link to the second server. I also can't make sure that everyone updates the app and that's why I need to redirect all the requests to the second server.
So all the redirection handling should be done on the Windows machine.
What is the best way of doing that?
Here are a couple ideas:
DNS
Change the DNS for the server 1 domain to point to the server 2 host. So, then all requests to either DNS name will go to server 2. You may have to wait a little while until any local DNS caching effects time out. An advantage of this approach is that while you are waiting for DNS caching effects to expire, everything stays up as requests either go to a working server1 or a working server2. When cached DNS has finally expired, all requests will be going to server2 and you can then take server1 down.
Your Proxy
You could replace the current server 1 process with a proxy that points to server 2. So, any requests incoming to server 1 will be proxied over to server 2. Since a change like this probably can't be made instantly, you might have a short amount of downtime for requests coming into server1.
Hosting Proxy
If this is running at a hosting provider, then they probably have a proxy service already running that proxies your public DNS IP address to your actual host. That hosting proxy could be reconfigured to direct requests for server1 to server2 instead.

NGINX, THe Edge, HAPRoxy

I was going through Uber Engineering website where I came across this paragraph and I it confused me a lot, if anyone can make it clear for me then I would be thankful to him/her:
The Edge The frontline API for our mobile apps consists of over 600
stateless endpoints that join together multiple services. It routes
incoming requests from our mobile clients to other APIs or services.
It’s all written in Node.js, except at the edge, where our NGINX front
end does SSL termination and some authentication. The NGINX front end
also proxies to our frontline API through an HAProxy load balancer.
This is the link.
NGINX is already a reverse proxy + load balancer, then from where HAProxy load balancer came in the picture and where exactly it fits in the picture? What is "the edge" he talked about? Either the guy who wrote his he wrote confused words or I dont know English.
Please help.
It seems like they're using HAProxy strictly as a load balancer, and using NGINX strictly to terminate SSL and for authentication. It isn't necessary in most cases to use HAProxy along with NGINX, as you mentioned, NGINX has load-balancing capabilities, but being Uber, they probably ran into some unique problems that required the use of both. According to the information I've read, such as http://www.loadbalancer.org/blog/nginx-vs-haproxy/ and https://thehftguy.com/2016/10/03/haproxy-vs-nginx-why-you-should-never-use-nginx-for-load-balancing/, NGINX works extremely well as a web server, including the use case where it is serving as a reverse proxy for a node application, but its load-balancing capabilities are basic and not nearly as performant as HAProxy. Additionally, HAProxy exposes many more metrics for monitoring, and has more advanced routing capabilities.
Load balancing is not the core feature of NGINX. In the context of a node.js application, usually what you would see NGINX used for is to serve as a reverse proxy, meaning that NGINX is the web server, and http requests come through it. Then, based on the hostname and other rules, it forwards on the HTTP request to whatever port your node.js application is running on. As part of this flow, often NGINX will handle SSL termination, so that this computationally-intensive task is not being handled by node.js. Additionally, NGINX is often used to serve static assets for node.js apps, as it is more efficient, especially when compressing assets.

Node.js Reverse Proxy/Load Balancer

I am checking node-http-proxy and nodejs-proxy to build a DIY reverse proxy/load balancer in Node.js. After coding a small version, I setup 2 WEBrick servers for the same Rails app so I could load balance (round robin) between them. However each HTTP request is sent to one or another server which is very inefficient since the loading process of CSS and Javascript files from the home page is performed with more than 25 GET requests.
I tried to play a bit with socket events but I didn't get anywhere because by default it uses keep-alive connections (possibly this is why nginx just support http/1.0).
Ok, so I am wondering how can my proxy send a block of HTTP requests (for instance loading a webpage entirely, etc) to only one server so I could send the next block to another server.
You need to consider stickiness or session persistence. This will ensure future connections after the first connection inbound will get 'stuck' to the chosen server for the duration of the session or until the persistence connection times out.

on varnish, how can i see how many requests to each server are sent?

I'd like to see how many requests varnish is sending to each backend via round-robin director.
i haven't found out how so far. thanks for any idea
You can't get this numbers from varnish directly, but if youre using round-robin director I'd guess the traffic to each backend will be nearly the 1/n of total ammount where n is number of backends. This is true only if backends all healthy and not skipped from round.
You can still get theese stattistics from backend access log or server-status page or similar, depending on http daemon used.
I'm a bit rusty on the varnish log file, but you should be able to use varnishlog and sample it.
http://linux.die.net/man/1/varnishlog
The sample, should give you an idea of the distribution.
Another option, would be to do a netstat and see how many connections are open to the background server.
-daniel

Resources