Nhược điểm của việc sử dụng nginx như một máy chủ web chính?


12

Tôi đã thấy hàng triệu trang web sử dụng nginx như một máy chủ web chuyên nghiệp làm việc cùng với Apache. Nhưng tôi đã thấy rất ít máy chủ chỉ chạy nginx như máy chủ web mặc định của họ. Nhược điểm chính của cấu hình như vậy là gì?

Tôi có thể thấy một số:

  • Không thể sử dụng các tệp cấu hình trên mỗi thư mục như .htaccess, vì vậy mọi thay đổi cấu hình nên được thực hiện đối với tệp cấu hình máy chủ chính và yêu cầu tải lại máy chủ. Nhưng htscanner pecl có thể bù chúng cho các cài đặt php
  • Không có sẵn mod_php cho nginx, có thể được bù bằng php-fpm chẳng hạn.

Những người khác là gì? Tại sao mọi người không bỏ Apache và chuyển sang nginx hoặc bất kỳ giải pháp nhẹ nào khác? Có thể, có một số lý do đặc biệt?

EDIT: câu hỏi này chủ yếu là về làm việc với LAMP stack.


1
Mindshare, quán tính, đầu tư. Vẫn như mọi khi.
Ignacio Vazquez-Abrams

Đầu tư nào cần thiết để thiết lập nginx trên một máy chủ mới? Đó là phần mềm mã nguồn mở miễn phí.
Vladislav Rastrusny

3
Đầu tư thời gian cần thiết để nghiên cứu, triển khai, thử nghiệm, v.v.
ThatGraemeGuy

Nếu chúng ta đang nói về số lượng, IMHO lý do lớn nhất là số lượng lớn các máy chủ được chia sẻ sử dụng Apache. Thiết lập nginx như một dịch vụ chia sẻ (ví dụ như trong cPanel, Plesk, v.v.) vẫn chưa dễ dàng như làm với Apache, đặc biệt là đối với người dùng cuối. Và tôi biết nhiều máy chủ chuyên dụng chạy một trang web và sử dụng cPanel / Plesk / etc chỉ vì sự dễ dàng, quen thuộc và chi phí thiết lập thấp.
Halil Özgür

Câu trả lời:


9

Từ trải nghiệm #nginx của tôi, hầu như luôn luôn là do quen thuộc với các tệp .htaccess của Apache và không muốn mất điều đó hay nói cách khác tùy thuộc vào nó. Ví dụ, những người đang chạy lưu trữ máy chủ được chia sẻ, những người chỉ muốn giảm tải các tệp tĩnh và giữ trạng thái apache để người dùng của họ sử dụng.

Và tôi thực sự không thể nghĩ ra bất kỳ lý do nào khác để ủy quyền cho Apache ngoài việc giữ .htaccess cho người dùng cuối.

Chỉnh sửa: Trên thực tế mod_php cộng với phpsuexec cho các máy chủ được chia sẻ có thể là một lý do khác để gắn bó với Apache.


Theo kinh nghiệm của tôi, thật khó để có được hiệu suất tốt từ tomcat qua nginx, vì ajp-worker của apache2 nhanh hơn đáng kể dưới áp lực cao. Tôi biết rằng nginx có triển khai ajp13 thử nghiệm, nhưng nó không ổn định và tài liệu kém.
pauseka

1
Điều đó rất có thể. Nginx hoạt động tốt nhất dưới dạng proxy đảo ngược fastcgi hoặc HTTP 1.0. Tôi biết có các mô-đun bên thứ 3 để nói chuyện với scgi, wsgi, v.v. nhưng tôi không thể nói chúng ổn định như thế nào, hoặc thậm chí là chúng nhanh như thế nào.
Martin Fjordvald

BTW, mod_php không hoạt động với suexec. Suexec dành cho các ứng dụng cgi.
Vladislav Rastrusny

Vâng, bạn đi, không có lý do thực sự. Đã là người dùng nginx quá lâu để thậm chí không nhớ đến Apache nữa. : D
Martin Fjordvald

6

Nếu bạn có một nhóm người có thể làm cho Apache hoạt động tốt, tại sao lại phải học lại một ứng dụng và cấu hình hoàn toàn mới, di chuyển các quy tắc mod_rewrite, làm lại cấu hình mod_perl / php / etc, kiểm tra lại, triển khai lại?

Cả hai ngăn xếp phần mềm có thể miễn phí, nhưng "đào tạo lại, phát triển lại, kiểm tra lại" thì không, và đã đến lúc bạn có thể thêm các tính năng mà người dùng quan tâm về 1 , thay vì mày mò vì mục đích mày mò.

1 Tôi rõ ràng không nói về các dự án cá nhân, ở đó.


2

Tôi thích Nginx, nhưng có hai điều ngăn tôi sử dụng nó cho các trang web của mình.

  • Thật khó để thiết lập PHP-FPM . Tôi đã không thành công để làm điều đó với phiên bản PHP mới nhất.

  • Nginx chưa hỗ trợ cho HTML5 Websockets, mà tôi đã can thiệp vào.


1
Bạn có thể kể tên những khó khăn bạn gặp phải với nginx và php-fpm không? Về HTML5 WebSockets, nó trông giống như Apache có không họ được nêu ra: issues.apache.org/bugzilla/show_bug.cgi?id=47485
Vladislav Rastrusny

Tôi cũng muốn biết các vấn đề về php-fpm. Nếu bạn có thể biên dịch PHP từ nguồn mà không có nó thì thật đơn giản để làm điều đó với nó.
Martin Fjordvald

1
Chi nhánh 5.3 đã có nó bên trong, vì vậy chỉ cần ./mình --enable-fpm và bạn đã hoàn thành.
Vladislav Rastrusny
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.