Những cấu hình Apache / PHP nào bạn biết và chúng tốt như thế nào?


8

Tôi muốn hỏi bạn về các phương thức cấu hình PHP / Apache mà bạn biết, ưu và nhược điểm của chúng. Tôi sẽ tự bắt đầu:

---------------- PHP là mô-đun Apache ----------------

Ưu điểm : tốc độ tốt vì bạn không cần phải khởi động exe mỗi lần, đặc biệt là ở chế độ mpm-worker . Bạn cũng có thể sử dụng các trình tăng tốc PHP khác nhau trong chế độ này như APC hoặc eAccelerator.

Nhược điểm : nếu bạn đang chạy apache trong chế độ MPM nghiệp, bạn có thể phải đối mặt với các vấn đề ổn định vì mỗi trục trặc trong bất kỳ kịch bản php sẽ dẫn đến bất ổn cho toàn hồ bơi thread về điều đó quá trình apache. Cũng trong chế độ này, tất cả các tập lệnh được thực hiện thay mặt cho người dùng apache. Điều này là xấu cho an ninh. Cấu hình mpm-worker yêu cầu PHP được biên dịch trong chế độ an toàn luồng. Ít nhất các kho lưu trữ mặc định của CentOS và RedHat không có phiên bản PHP an toàn luồng, vì vậy trên các HĐH này, bạn cần phải tự biên dịch ít nhất PHP (có một cách để kích hoạt worker mpm trên Apache). Việc sử dụng các nhị phân PHP an toàn luồng được coi là thử nghiệm và không ổn định. Thêm vào đó, nhiều phần mở rộng PHP không hỗ trợ chế độ an toàn luồng hoặc không được kiểm tra tốt ở chế độ an toàn luồng.

---------------- PHP là CGI ----------------

Đây có vẻ là cấu hình mặc định chậm nhất dường như là chính "con";)

---------------- PHP là CGI thông qua mod_suphp ----------------

Ưu điểm : suphp cho phép bạn thực hiện các scip php thay mặt cho chủ sở hữu tệp tập lệnh. Bằng cách này, bạn có thể tách các trang web khác nhau một cách an toàn trên cùng một máy. Ngoài ra, suphp cho phép sử dụng các tệp php.ini khác nhau trên mỗi máy chủ ảo.

Nhược điểm : PHP trong chế độ CGI có nghĩa là hiệu suất thấp hơn. Trong chế độ này, bạn không thể sử dụng các trình tăng tốc php như APC vì mỗi lần tiến trình mới được sinh ra để xử lý tập lệnh khiến bộ đệm của quá trình trước đó trở nên vô dụng. BTW, bạn có biết cách áp dụng một số máy gia tốc trong cấu hình này không? Tôi đã nghe một cái gì đó về việc sử dụng shm cho bộ đệm cache bytecode php. Ngoài ra, bạn không thể định cấu hình PHP thông qua các tệp .htaccess trong chế độ này. Bạn sẽ cần cài đặt htscanner P ECL cho việc này nếu bạn cần đặt nhiều tùy chọn cho mỗi tập lệnh thông qua .htaccess (chỉ thị php_value / php_flag)

---------------- PHP là CGI qua suexec ----------------

Cấu hình này trông giống như với suphp, nhưng tôi nghe nói, nó chậm hơn và kém an toàn hơn. Hầu như cùng một ưu và nhược điểm áp dụng.

---------------- PHP là FastCGI ----------------

Ưu điểm : Tiêu chuẩn FastCGI cho phép quy trình php đơn xử lý một số tập lệnh trước khi quy trình php bị hủy. Bằng cách này bạn có được hiệu suất do không cần phải quay quá trình php mới cho mỗi tập lệnh. Bạn cũng có thể sử dụng các trình tăng tốc PHP trong cấu hình này (xem phần khuyết điểm để bình luận). Ngoài ra, FCGI gần giống như suphp cũng cho phép các quy trình php được thực hiện thay mặt cho một số người dùng. mod_fcgid dường như có sự hỗ trợ và linh hoạt fcgi đầy đủ nhất cho apache.

Nhược điểm : Việc sử dụng trình tăng tốc php trong chế độ fastcgi sẽ dẫn đến mức tiêu thụ bộ nhớ cao bởi vì mỗi quy trình PHP sẽ có bộ đệm mã byte riêng (trừ khi có một trình tăng tốc nào đó có thể sử dụng bộ nhớ dùng chung cho bộ đệm của mã byte. Có như vậy không?). FastCGI cũng hơi phức tạp để cấu hình. Bạn cần tạo các tệp cấu hình khác nhau và thực hiện một số sửa đổi cấu hình.

Dường như, fastcgi là cấu hình PHP ổn định, an toàn, nhanh chóng và linh hoạt nhất, tuy nhiên, hơi khó để được cấu hình. Nhưng, có thể, tôi đã bỏ lỡ một cái gì đó?

Bình luận được chào đón!

Câu trả lời:


3

Chạy PHP thông qua FastCGI chắc chắn sẽ cung cấp cho bạn sự linh hoạt nhất. Bạn không chỉ có thể sử dụng Apache mpm-worker một cách an toàn, thậm chí bạn có thể sử dụng hoàn toàn một máy chủ web khác (ví dụ nginx).

Nhưng ngay cả khi ở lại với Apache, "PHP thông qua FastCGI" hiện tại không phải là một lựa chọn, mà ít nhất là hai: mod_fastcgi, mod_fcgid. Trên hết, bạn có thể sử dụng các quy trình FastCGI động, tĩnh hoặc bên ngoài; có hoặc không có suexec. Và sau đó là trình quản lý quy trình FastCGI nội bộ của PHP, hiện được thay thế bằng PHP-FPM rất đẹp trong PHP 5.3. Tất cả các tùy chọn có ưu và nhược điểm khác nhau và có thể dẫn đến các vấn đề khác nhau.

Đưa ra lựa chọn, tôi sẽ chọn mod_fastcgi với PHP-FPM vào lúc này, chủ yếu là vì nó cho phép các thiết lập cực kỳ linh hoạt và ổn định.


1
> Tôi sẽ chọn mod_fcgid với PHP-FPM Điều này sẽ ngăn bạn sử dụng APC. Chỉ mod_fastcgi cho phép sử dụng các máy chủ FCGI bên ngoài (là PHP-FPM). Nếu bạn sử dụng mod_fcgid, tất cả các lợi thế được cung cấp bởi php-fpm sẽ bằng không.
Vladislav Rastrusny

Tất nhiên, đó là một lỗi đánh máy ngu ngốc. Xin lỗi vì sự nhầm lẫn, tôi đã sửa nó.
bá tước

2

Không thực sự trả lời câu hỏi của bạn, nhưng tôi không hiểu điều này về việc FastCGI khó cấu hình. Điều khác biệt là các phương thức khác cần thay thế (mod_php, mod_python, ...) để có thể yêu cầu viết lại một phần mã. Đó có thể là phần khó khăn, nhưng để cấu hình Apache, ít nhất, tôi thấy đó là một cinch. Ví dụ, tôi đã thử nghiệm một ứng dụng WSGI bằng python và tôi muốn xem nó hoạt động như thế nào với tất cả các giao thức mà WSGI hỗ trợ. Đây là tệp máy chủ ảo với các cấu hình cho tất cả các giao thức (có mod_fastcgi):

<VirtualHost *:8888>
DocumentRoot "/home/test/"
#FastCGIExternalServer /home/test/wsgi -host 127.0.0.1:3333
#SCGIMount / 127.0.0.1:3333
FastCgiServer /home/test/wsgi/fcgi.py -idle-timeout 60 -processes 1
<Directory "/home/test/wsgi/">
    Options +ExecCGI +FollowSymLinks
    AddHandler fastcgi-script .py
    #AddHandler wsgi-script .py
    #AddHandler cgi-script .py
</Directory>
</VirtualHost>

Nó không có vẻ phức tạp đối với tôi. Chắc chắn, FastCGI hỗ trợ nhiều tùy chọn và nó có thể được điều chỉnh cho đến chết, nhưng đó là một vấn đề khác.

Để chạy là một người dùng khác, hãy sử dụng suexec và FastCGIWrappersau đó nó trở thành:

FastCGIWrapper On
<VirtualHost *:8888>
SuexecUserGroup test test
DocumentRoot "/home/test/"
FastCgiServer /var/www/test/fcgi.py -idle-timeout 60 -processes 1
<Directory "/var/www/test/">
    Options +ExecCGI +FollowSymLinks
    AddHandler fastcgi-script .py
</Directory>
</VirtualHost>

Và xem liên kết này cho một php.ini tùy chỉnh, nhưng bạn sẽ có thể chỉ định nó với -initial-envtùy chọn, nghĩa là

FastCgiServer /var/www/test/fcgi.py -idle-timeout 60 -processes 1 -inital-env PHPRC=/blah/

Phải, thêm config vào apache rất đơn giản. Nhưng cấu hình của bạn không cho phép thực thi các tập lệnh thay mặt cho chủ sở hữu của họ hoặc ít nhất là bởi người dùng cụ thể. Ngoài ra, php.ini tùy chỉnh không thể được sử dụng trong trường hợp của bạn (tôi thích hạn chế open_basingir cho mỗi virtualhost cho thư mục của mình)
Vladislav Rastrusny

Tôi không biết rõ về PHP, nhưng đó là những vấn đề tương tự mà bạn gặp phải với CGI thẳng. Và bạn có thể dễ dàng chạy fastcgi như máy chủ bên ngoài như bất kỳ người dùng nào bạn muốn.
Dan Andreatta

Đã thêm thông tin bổ sung cho câu trả lời.
Dan Andreatta

1

Một ứng cử viên sáng giá là: MPM Apache 2 ITK

apache2-mpm-itk (gọi tắt là mpm-itk) là MPM (Mô-đun đa xử lý) cho máy chủ web Apache. mpm-itk cho phép bạn chạy từng vhost của mình dưới một uid và gid riêng - nói tóm lại, các tập lệnh và tệp cấu hình cho một vhost không còn phải đọc đối với tất cả các vhost khác.

Đã làm việc cho một trong những khách hàng của chúng tôi rất tốt với hàng trăm Virtualhost với khá nhiều khách truy cập.

Bạn nhận được tất cả các Ưu điểm từ việc chạy PHP dưới dạng một mô-đun và sắp xếp một số nhược điểm.


Phải, nhưng được cập nhật lần cuối một năm trước. Và những gì thậm chí còn quan trọng hơn mở ra một tổng thể bảo mật tiềm năng. "Vì mpm-itk phải có khả năng setuid (), nên nó chạy dưới quyền root (mặc dù bị hạn chế với khả năng POSIX nếu có thể) cho đến khi yêu cầu được phân tích cú pháp và vhost xác định. Điều này có nghĩa là bất kỳ lỗ hổng bảo mật nào trước khi yêu cầu được phân tích cú pháp sẽ được một lỗ hổng bảo mật gốc. (Nơi có khả năng nhất có lẽ là trong mod_ssl.) "
Vladislav Rastrusny

Mã này hoạt động, rất ổn định và có lẽ không có lý do để cập nhật nó. Mô-đun có một nhà phát triển Debian hoạt động (không biết về nhà phát triển ban đầu). Và đó là FOSS và không phức tạp lắm.
rkthkr

0

Đối với tôi, câu hỏi là mục đích của máy chủ web là gì. Có phải nó phục vụ nhiều hơn một máy chủ ảo? Nếu vậy, thì bạn cần phải hy sinh hiệu năng cho bảo mật bị cô lập. Có hiệu năng bị ảnh hưởng, nhưng với phần cứng ngày nay, nó vẫn cần khá nhiều lưu lượng để mang lại các vấn đề hiệu suất lớn.

Nếu hiệu suất là quan trọng, hãy chạy một trang web trên VPS hoặc Máy chủ chuyên dụng và định cấu hình cho hiệu suất.


Tôi chỉ hỏi về các biến thể có thể. Không phải về việc lựa chọn một trong những tốt nhất. Tôi sẽ chọn mì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.