node.js 자체 또는 정적 파일 제공을위한 nginx 프런트 엔드?

node.js 자체 또는 정적 파일 제공을위한 nginx 프런트 엔드?

---

더 빠른 벤치 마크 또는 비교가 있습니까? 노드 앞에 nginx를 배치하고 정적 파일을 직접 제공하거나 노드 만 사용하고이를 사용하여 정적 파일을 제공합니까?

nginx 솔루션이 나를 위해 더 관리하기 쉬운 것 같습니다.

---

나는 여기에 대한 답변에 동의하지 않을 것입니다. Node는 잘 작동하지만 nginx는 올바르게 구성되면 가장 확실히 더 빠릅니다. nginx는 작은 메모리 풋 프린트로 비슷한 패턴 (필요할 때만 연결로 돌아 가기)에 따라 C에서 효율적으로 구현됩니다. 또한, 작업을 수행하는 것은 OS 커널 자체이기 때문에 가능한 한 빨리 파일을 제공하기 위해 sendfile syscall을 지원합니다 .

이제 nginx는 프런트 엔드 서버로서 사실상의 표준이되었습니다. 정적 파일, gzip, SSL 및 나중에로드 밸런싱을 제공 할 때 성능을 위해 사용할 수 있습니다.

추신 : 이것은 파일이 요청 당시 디스크에있는 것처럼 실제로 "정적"이라고 가정합니다.

---

nginx, Express.js (정적 미들웨어) 및 클러스터 된 Express.js를 비교 ab -n 10000 -c 100하여 정적 1406 바이트를 제공하기 위해 신속하게 수행했습니다 favicon.ico. 도움이 되었기를 바랍니다:

불행히도 내 컴퓨터에서 nginx가 오류를 발생시키기 시작하므로 1000 또는 10000 동시 요청을 테스트 할 수 없습니다.

편집 : artvolk에서 제안한대로 클러스터 + static미들웨어 (느림) 의 결과는 다음과 같습니다.

---

I have a different interpretation of @gremo's charts. It looks to me like both node and nginx scale at the same number of requests (between 9-10k). Sure the latency in the response for nginx is lower by a constant 20ms, but I don't think users will necessarily perceive that difference (if your app is built well). Given a fixed number of machines, it would take quite a significant amount of load before I would convert a node machine to nginx considering that node is where most of the load will occur in the first place. The one counterpoint to this is if you are already dedicating a machine to nginx for load balancing. If that is the case then you might as well have it serve your static content as well.

---

Either way, I'd setup Nginx to cache the static files...you'll see a HUGE difference there. Then, whether you serve them from node or not, you're basically getting the same performance and the same load-relief on your node app.

I personally don't like the idea of my Nginx frontend serving static assets in most cases, in that

1) The project has to now be on the same machine - or has to be split into assets (on nginx machine) & web app (on multiple machines for scaling)

2) Nginx config now has to maintain path locations for static assets / reload when they change.

---

That's a tricky question to answer. If you wrote a really lightweight node server to just serve static files, it would most likely perform better than nginx, but it's not that simple. (Here's a "benchmark" comparing a nodejs file server and lighttpd - which is similar in performance to ngingx when serving static files).

Performance in regard to serving static files often comes down to more than just the web-server doing the work. If you want the highest performance possible, you'll be using a CDN to serve your files to reduce latency for end-users, and benefit from edge-caching.

If you're not worried about that, node can serve static files just fine in most situation. Node lends itself to asynchronous code, which it also relies on since it's single-threaded and any blocking i/o can block the whole process, and degrade your applications performance. More than likely you're writing your code in a non-blocking fashion, but if you are doing anything synchronously, you may cause blocking, which would degrade how fast other clients can get their static files served. The easy solution is to not write blocking code, but sometimes that's not a possibility, or you can't always enforce it.

---

I am certain that purely node.js can outperform nginx in a lot of aspect.

NginX에는 내장 캐시가 있지만 node.js는 공장 설치된 상태로 제공되지 않습니다 (사용자 고유의 파일 캐시를 구축해야 함). 사용자 정의 파일 캐시는 매우 간단하기 때문에 nginx 및 시장의 다른 서버보다 성능이 뛰어납니다.

또한 Nginx는 다중 코어에서 실행됩니다. Node의 잠재력을 최대한 활용하려면 노드 서버를 클러스터링해야합니다. 방법을 알고 싶다면 오후를 기쁘게 해주세요.

노드로 성능 열반을 달성하려면 심층 파기가 필요합니다. 그게 유일한 문제입니다. 일단 완료되면 네 ... Nginx를 이깁니다.

참고 URL : https://stackoverflow.com/questions/9967887/node-js-itself-or-nginx-frontend-for-serving-static-files