node.js chính nó hoặc giao diện người dùng nginx để cung cấp các tệp tĩnh?


90

Có điểm chuẩn hoặc so sánh nào nhanh hơn: đặt nginx trước nút và để nó phân phát tệp tĩnh trực tiếp hay chỉ sử dụng nút và phân phát tệp tĩnh bằng cách sử dụng nó?

giải pháp nginx dường như dễ quản lý hơn đối với tôi, bất kỳ suy nghĩ?


3
Tôi muốn nói rằng nó cũng phụ thuộc vào số lượng cấu hình và mã bạn phải viết để sử dụng một máy chủ này hơn máy chủ kia. Nếu bạn không mong đợi IPO và máy chủ ứng dụng của bạn đã được định cấu hình và làm mọi thứ bạn cần, thì bạn có thể tiếp tục với nó cho đến khi nó không đủ.
m33lky

Câu trả lời:


118

Tôi sẽ không đồng ý với câu trả lời ở đây. Mặc dù Node sẽ hoạt động tốt, nhưng nginx chắc chắn sẽ nhanh hơn khi được định cấu hình chính xác. nginx được triển khai hiệu quả trong C theo một mô hình tương tự (chỉ quay lại kết nối khi cần thiết) với một dấu chân bộ nhớ nhỏ. Hơn nữa, nó hỗ trợ syscall sendfile để cung cấp các tệp đó nhanh nhất có thể khi bạn có thể nhận được khi cung cấp tệp, vì chính nhân hệ điều hành đang thực hiện công việc.

Đến nay nginx đã trở thành tiêu chuẩn trên thực tế với tư cách là máy chủ giao diện người dùng. Bạn có thể sử dụng nó cho hiệu suất của nó trong việc cung cấp các tệp tĩnh, gzip, SSL và thậm chí cân bằng tải sau này.

Tái bút: Điều này giả định rằng các tệp thực sự "tĩnh" như ở trạng thái còn lại trên đĩa tại thời điểm yêu cầu.


7
Chỉ cần một lưu ý nhỏ: node.js cũng hỗ trợ sendfile- nhưng có vẻ như bạn phải viết một số mã, xem ví dụ: blog.std.in/2010/09/09/using-sendfile-with-nodejs
tuomassalo

Ngoài việc cung cấp nội dung tĩnh, tại sao Nginx hoạt động tốt hơn so với việc chỉ hiển thị máy chủ web chính (Tomcat / Jetty / IIS, v.v.) trên miền công khai?
raffian

1
Nếu một yêu cầu được gửi đến ứng dụng của bạn, yêu cầu đó sẽ không được thực hiện nhanh hơn một cách kỳ diệu bằng cách định tuyến nó qua nginx trước (nó có thể nhanh hơn đáng kể trong trường hợp tốt nhất khi nginx xử lý CSS tĩnh và js, gzip và SSL). Tuy nhiên, nginx cũng là một trong những trình cân bằng tải phần mềm tốt nhất, vì vậy điều này có thể rất quan trọng vì hầu hết các máy chủ đều nổi tiếng với việc lật ra ở mức tải cao vừa phải.
m33lky

Nhưng bạn có thể phục vụ các tệp theo cách không liên tục bằng Node.js. Bạn có thể làm điều đó với NGINX không?
Dragos C.

1
@lwansbrough đưa những điểm chuẩn đó lên bàn. Ít nhất một người trong chủ đề này đã thực hiện thử nghiệm của riêng mình.
m33lky

73

Tôi đã nhanh chóng phân ab -n 10000 -c 100phát một byte tĩnh 1406 favicon.ico, so sánh nginx, Express.js (phần mềm trung gian tĩnh) và Express.js được phân cụm. Hi vọng điêu nay co ich:

nhập mô tả hình ảnh ở đây

Rất tiếc, tôi không thể kiểm tra 1000 hoặc thậm chí 10000 yêu cầu đồng thời vì nginx, trên máy của tôi, sẽ bắt đầu phát ra lỗi.

CHỈNH SỬA : theo gợi ý của artvolk, đây là kết quả của cluster + staticmiddleware (chậm hơn):

nhập mô tả hình ảnh ở đây


Cảm ơn bạn, rất hữu ích! Bạn đã sử dụng phần mềm trung gian này cho favicon: senchalabs.org/connect/favicon.html hay chỉ cung cấp nó dưới dạng tệp tĩnh?
artvolk

@artvolk một favicon :)
gremo

3
Bạn đã đặt NODE_ENV = production cho các bài kiểm tra chưa? Bởi vì điều đó sẽ tạo ra sự khác biệt đáng kinh ngạc do staticphần mềm trung gian bộ nhớ đệm sẽ làm trong quá trình sản xuất.
ruffrey,

19
đối với những bạn không nói được tiếng Ý, trục x là số yêu cầu và trục Y là số mili giây cần để phân phát tệp. Tôi đã phải google dịch điều đó vì tôi muốn đảm bảo rằng tôi không đọc nhầm dữ liệu. dữ liệu này hữu ích đến khó tin và tôi thực sự đánh giá cao bài kiểm tra điểm chuẩn ở đây. sau tất cả sẽ gắn bó với nginx
JL Griffin

1
NODE_ENV = đã được thiết lập sản xuất chưa?
basickarl

11

Tôi có cách hiểu khác về biểu đồ của @ gremo. Đối với tôi, nó giống như cả quy mô nút và nginx với cùng một số lượng yêu cầu (từ 9-10k). Chắc chắn độ trễ trong phản hồi cho nginx thấp hơn 20ms không đổi, nhưng tôi không nghĩ rằng người dùng nhất thiết sẽ cảm nhận được sự khác biệt đó (nếu ứng dụng của bạn được xây dựng tốt). Với một số lượng máy cố định, sẽ mất một lượng tải đáng kể trước khi tôi chuyển đổi một máy nút thành nginx vì xem nút đó là nơi phần lớn tải sẽ xảy ra ngay từ đầu. Một điểm đối phó với điều này là nếu bạn đã dành một máy cho nginx để cân bằng tải. Nếu đúng như vậy thì bạn cũng có thể để nó phân phát nội dung tĩnh của mình.


1
"Chắc chắn độ trễ trong phản hồi cho nginx thấp hơn 20ms không đổi, nhưng tôi không nghĩ rằng người dùng nhất thiết sẽ cảm nhận được sự khác biệt đó"? Tôi thực sự hy vọng các bạn không làm điều này. Có bằng chứng cho thấy người dùng sẽ cảm nhận được sự khác biệt 1ms!
Navin

4
Cần trích dẫn
David Burrows

9

Dù bằng cách nào, tôi sẽ thiết lập Nginx để lưu vào bộ đệm các tệp tĩnh ... bạn sẽ thấy sự khác biệt LỚN ở đó. Sau đó, cho dù bạn phân phát chúng từ nút hay không, về cơ bản bạn sẽ nhận được cùng một hiệu suất và cùng một mức giảm tải trên ứng dụng nút của bạn.

Cá nhân tôi không thích ý tưởng giao diện người dùng Nginx của mình phân phát nội dung tĩnh trong hầu hết các trường hợp, trong đó

1) Dự án hiện phải ở trên cùng một máy - hoặc phải được chia thành nội dung (trên máy nginx) & ứng dụng web (trên nhiều máy để mở rộng)

2) Cấu hình Nginx bây giờ phải duy trì vị trí đường dẫn cho nội dung tĩnh / tải lại khi chúng thay đổi.


0

Đó là một câu hỏi khó trả lời. Nếu bạn đã viết một máy chủ nút thực sự nhẹ để chỉ phục vụ các tệp tĩnh, nó rất có thể sẽ hoạt động tốt hơn nginx, nhưng nó không đơn giản như vậy. ( Đây là "điểm chuẩn" so sánh máy chủ tệp nodejs và lighttpd - có hiệu suất tương tự như ngingx khi cung cấp tệp tĩnh).

Hiệu suất liên quan đến việc cung cấp các tệp tĩnh thường phụ thuộc vào nhiều hơn là chỉ máy chủ web thực hiện công việc. Nếu bạn muốn có hiệu suất cao nhất có thể, bạn sẽ sử dụng CDN để phân phát tệp của mình nhằm giảm độ trễ cho người dùng cuối và hưởng lợi từ bộ nhớ đệm cạnh.

Nếu bạn không lo lắng về điều đó, nút có thể phân phát các tệp tĩnh tốt trong hầu hết các tình huống. Node tự sử dụng mã không đồng bộ, mã này cũng dựa vào vì nó là một luồng đơn và bất kỳ i / o chặn nào cũng có thể chặn toàn bộ quá trình và làm giảm hiệu suất ứng dụng của bạn. Nhiều khả năng bạn đang viết mã của mình theo cách không chặn, nhưng nếu bạn đang thực hiện đồng bộ bất cứ điều gì, bạn có thể gây ra việc chặn, điều này sẽ làm suy giảm tốc độ phục vụ các tệp tĩnh của các khách hàng khác. Giải pháp dễ dàng là không viết mã chặn, nhưng đôi khi đó không phải là một khả năng hoặc bạn không thể luôn thực thi nó.


9
Đây là tất cả những điều vô nghĩa. Câu hỏi này là về nginx không phải Apache. Cả nginx và nút đều sử dụng libev cho vòng lặp sự kiện của chúng. Nginx sẽ nhanh hơn nhiều lần so với nút. Một trong số chúng không có chi phí của máy ảo và được viết riêng để thực hiện thao tác này trên hệ thống tệp của bạn.
Evan Carroll

1
libev là nút sớm. Libuv đã sử dụng vai trò này để cho phép nút chạy crossplatform.
tsturzl,

1
Tôi không thấy yếu tố mã không đồng bộ này như thế nào. Hiệu suất của Node sẽ kém hơn nhiều so với Nginx và có thể là do chặn I / O mà bạn gặp phải khi có một loạt khách hàng yêu cầu bạn đọc tệp từ đĩa. Cách tốt nhất là luôn sử dụng Nginx cho các nội dung tĩnh để ứng dụng Node của bạn có thể xử lý logic ứng dụng. Chúng ta có thể nói về kịch bản lý thuyết nơi Node sẽ thực hiện tốt hơn nhưng trong thế giới thực Nginx sẽ giành chiến thắng bởi một dặm 9 lần trong số 10
WGP

-11

Tôi chắc chắn rằng node.js thuần túy có thể vượt trội hơn nginx ở nhiều khía cạnh.

Tất cả đều nói rằng tôi phải ở lại NginX có một bộ nhớ cache tích hợp, trong khi node.js không được cài đặt tại nhà máy (BẠN PHẢI XÂY DỰNG FILE CACHE CỦA RIÊNG MÌNH). Bộ đệm tệp tùy chỉnh hoạt động tốt hơn nginx và bất kỳ máy chủ nào khác trên thị trường vì nó siêu đơn giản.

Ngoài ra Nginx cũng chạy trên nhiều lõi. Để sử dụng hết tiềm năng của Node, bạn phải phân cụm các máy chủ nút. Nếu bạn quan tâm để biết làm thế nào thì vui lòng pm.

Bạn cần phải đào sâu để đạt được hiệu suất niết bàn với nút, đó là vấn đề duy nhất. Sau khi hoàn thành, yeah ... nó đánh bại Nginx.


1
bạn cần đưa ra một số dữ kiện, vì tôi muốn tin những gì bạn đang nói nhưng, cần các điểm chuẩn, nếu dựa trên thế giới thực, thật tuyệt! nhưng không phải trường hợp cạnh
Stefan Rogin.

5
Điều buồn cười là câu trả lời này có nhiều dữ kiện như câu trả lời được chọn với nhiều phiếu bầu nhất. Tôi nghĩ mọi người chỉ thích một máy chủ web phía trước bởi vì đó là cách họ được dạy để làm điều đó trong [chèn bất kỳ công nghệ ứng dụng web nào khác]. Đây không phải là một câu trả lời hay nhưng đáng tiếc +1.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.