So sánh hiệu suất của các máy chủ web RPi 3: Apache, Nginx và Lighttpd


10

Có ai đã thực hiện bất kỳ thử nghiệm so sánh hiệu suất thực tế nào trên RPi 3 trên các máy chủ web phổ biến không:

  1. Apache2 - máy chủ phổ biến nhất
  2. Nginx - máy chủ tuyên bố là hoạt động tốt nhất
  3. Lighttpd - máy chủ nhẹ nhất
  4. Hoặc một gói tôi chưa nghe nói đến

Một cái gì đó giống như bài đăng 4 năm tuổi này cho RPi 2 . Theo lời khuyên trong bài đăng đó, tôi đã mở rộng nghiên cứu của mình một cách tổng quát hơn và tìm thấy bài viết này , nhưng xem xét nó hơi nghi ngờ vì đây là một công ty lưu trữ và tôi cần một câu trả lời phù hợp với phần cứng của RPi 3.


4
Off Topic: Tôi không hiểu tại sao ai đó bỏ phiếu một câu hỏi mà không đưa ra gợi ý điều gì sai với nó.
Joe Platano

2
Tôi không thụ động, cũng không tìm cách xóa câu hỏi của bạn. Tôi đã quá bận rộn vào thời điểm đó để đăng một bình luận giải thích về downvote của tôi. Vấn đề đầu tiên là bạn đang tối ưu hóa sớm. Bạn chưa xác định rõ trường hợp sử dụng (những mô-đun / chức năng nào sẽ cần thiết, v.v.). Tôi có thể tiếp tục viết thêm một vài đoạn nhưng tôi sẽ để những lời của chính bạn tự nói: "Nếu Nginx sẽ làm những gì tôi cần, thì có vẻ như đó là một thứ tốt hơn (hoặc không phù hợp -get) giải pháp kết hợp lại trước khi bắt đầu điều chỉnh hiệu suất. "
Steve Robillard

2
Nếu Nginx sẽ làm những gì tôi cần (vì vậy bạn có thể loại trừ một hoặc nhiều máy chủ dựa trên yêu cầu; do đó làm cho câu hỏi của bạn không liên quan. Bạn đang đặt xe trước ngựa. Thứ hai, để trả lời câu hỏi của bạn sẽ phụ thuộc vào khối lượng công việc cụ thể, việc sử dụng DB sẽ được đọc nặng hay viết nặng? hệ thống sẽ bị ràng buộc DB hay bị ràng buộc IO? Nếu DB không có khả năng điều chỉnh máy chủ web của bạn để giúp đỡ.
Steve Robillard

2
Một lần nữa trích dẫn bạn "có thể phục vụ họ tất cả mọi thứ mà không có độ trễ lớn là điều quan trọng." Bao nhiêu là quá nhiều độ trễ? và Cuối cùng "Tôi đã thấy các bài đăng khác về cách điều chỉnh Apache và Nginx để có hiệu suất tốt hơn nhưng có vẻ như rất nhiều công việc chỉ để xây dựng một cấu hình thử nghiệm để đánh giá các tùy chọn." Đây không phải là chính xác những gì bạn đang yêu cầu ai đó làm cho bạn trong câu hỏi này? Không có lợi ích của dữ liệu lưu lượng truy cập thực hoặc thông số kỹ thuật đầy đủ của vấn đề. Nếu không có những điều này, họ cũng có thể tham khảo một quả cầu pha lê.
Steve Robillard

Xem xét các hạn chế về bộ nhớ và bộ xử lý của PI, liệu một thiết lập dựa trên nút có cùng với express trong máy chủ điều khiển IO không chặn được sử dụng nhiều hơn không? Một lần nữa, tùy thuộc vào trường hợp sử dụng của bạn. Bạn đang phục vụ các tệp tĩnh hoặc tệp động. Là chảo của bạn để có một ứng dụng web hoặc một trang web.
CoderX

Câu trả lời:


5

Đây sẽ là một nhận xét, nhưng nó hơi dài.

Mặc dù tôi chưa (chưa) thử nghiệm các máy chủ web khác nhau trên Pi của mình, trước đây tôi đã chạy rất nhiều thử nghiệm trên máy chủ web chạy trên phần cứng máy chủ x86. Những gì tôi biết từ đó là:

  1. hầu hết mọi người đều nhầm lẫn về sự khác biệt giữa hiệu suất và công suất - bạn sẽ thấy rất nhiều bài đăng cho rằng nginx nhanh hơn apache (pre-fork), điều này không đúng , ngoại trừ tải nặng. Nginx (và nhẹ) đều tốt hơn nhiều về năng lực. Và đó là ở cấp độ phân tích tầm thường nhất.

  2. Rất ít người phục vụ nội dung tĩnh độc quyền với máy chủ web của họ (trong trường hợp này, tux và G-Wan rời khỏi các máy chủ mà bạn đã đề cập trong bụi của họ). Cấu hình hiệu suất phụ thuộc nhiều vào công nghệ lớp logic và sự tích hợp của nó với máy chủ web.

  3. Hiệu suất (và dung lượng) phụ thuộc vào mọi thứ khác đang chạy trên thiết bị.

Có rất nhiều tính năng của máy chủ trung tâm dữ liệu rất dễ sống nếu bạn không có dự phòng cấp cụm phù hợp (psu kép, mạng kép, bảng điều khiển từ xa ...) tuy nhiên Raspberry PI không có ý nghĩa tốt nhất như một trang web nền tảng phục vụ do I / O đĩa chậm - bạn thực sự cần một cái gì đó với kết nối SATA, [i] SCSI, AOE hoặc infiniband để lưu trữ. Pi không có giao diện SATA, chỉ có một cổng ethernet và tôi không biết về giao diện infiniband hoặc SCSI.

(có những máy tính bảng nhỏ, đơn lẻ là lựa chọn hợp lý hơn để xây dựng khả năng giám sát web trên - và một cụm trong số này có thể có ý nghĩa kinh tế tốt, nhưng trong một kịch bản như vậy, bạn đang xem xét nhiều nút có khả năng phân lớp SSL, HTTP bộ nhớ đệm, webserving, logic ứng dụng và quản lý dữ liệu).

Câu hỏi nhanh nhất là khó xác định, khác nhau cho từng trường hợp và không thể trả lời.

Tuy nhiên, sai lầm lớn nhất tôi gặp lại nhiều lần trong CNTT, là mọi người chọn sản phẩm dựa trên một thuộc tính duy nhất thay vì xem xét tác động rộng hơn cả về công nghệ và những người liên quan.


Điểm tốt tất cả. Tôi sợ dự án này đã bị đốt cháy trở lại.
Sandor Dosa

2

Tôi sợ bạn cần phải tự tìm hiểu. Khi tôi có câu hỏi này cho RPi2 của mình, tôi tình cờ gặp Siegeomeperf . Tôi đã làm theo ví dụ này để chạy các điểm chuẩn - thay vì các trang html đơn giản, tôi đã yêu cầu các tệp php. Hiệu suất của máy chủ web cũng phụ thuộc vào các mô-đun cgi bạn sẽ chọn. Một lighttpd vanilla đơn giản có thể nhanh hơn một vanilla Apache. Nếu bạn đang chọn / định cấu hình CGI không phù hợp, điều này có thể thay đổi và Apache có thể vượt trội hơn Lighty.


Tôi sợ bạn đúng. Tôi sẽ bắt đầu thử sắp xếp một phương pháp thử nghiệm và báo cáo lại.
Sandor Dosa

@SandorDosa, hãy cập nhật cho tôi, xin vui lòng
Joe Platano

2

Tôi đã chọn tùy chọn lighttpd, vì những lý do sau:

  1. nhẹ
  2. một trong những dễ cài đặt nhất
  3. chạy trên RPi2 của tôi trong hai năm qua mà không gặp vấn đề gì (24x7)
  4. cần một thiết bị tốt và đơn giản để sử dụng làm thiết bị thử nghiệm của tôi

Tôi sử dụng nó như:

  1. theo dõi nhiệt độ cpu hệ thống của tôi, nhiệt độ môi trường / phòng và bộ ghi đồ thị độ ẩm
  2. Máy chủ FTP để trao đổi tệp với các đối tác kinh doanh của tôi và tránh lưu trữ dữ liệu nhạy cảm trên máy chủ thư miễn phí của bên thứ 3
  3. Nhiều widget web để kiểm tra chỉ số thị trường như ngoại hối, trái phiếu, cổ phiếu, v.v.
  4. kiểm tra mã html
  5. chạy một kịch bản tôi đã thực hiện để kiểm tra thư, vì tôi có nhiều tài khoản thư, tránh bị khóa thẻ địa lý
  6. chạy một blog đơn giản (blog Nibble)
  7. làm việc như một honeypot để phát hiện (và chặn) tin tặc trên dây của tôi

chỉ để đặt tên cho một vài cách sử dụng

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.