Konfigurasi Apache / PHP apa yang Anda ketahui dan seberapa bagusnya?

8

Saya ingin bertanya tentang metode konfigurasi PHP / Apache yang Anda tahu, pro dan kontra mereka. Saya akan mulai sendiri:

---------------- PHP sebagai modul Apache ----------------

Pro : kecepatan yang baik karena Anda tidak perlu memulai exe setiap kali terutama dalam mode mpm-pekerja . Anda juga dapat menggunakan berbagai akselerator PHP dalam mode ini seperti APC atau eAccelerator.

Cons : jika Anda menjalankan apache dalam mode mpm-worker, Anda mungkin menghadapi masalah stabilitas karena setiap kesalahan dalam skrip php apa pun akan menyebabkan ketidakstabilan ke seluruh rangkaian utas proses apache itu. Juga dalam mode ini semua skrip dieksekusi atas nama pengguna apache. Ini buruk untuk keamanan. konfigurasi mpm-worker membutuhkan PHP yang dikompilasi dalam mode thread-safe. Setidaknya repositori default CentOS dan RedHat tidak memiliki versi PHP thread-safe sehingga pada OS ini Anda perlu mengkompilasi setidaknya PHP sendiri (ada cara untuk mengaktifkan mpm pekerja di Apache). Penggunaan binari PHP aman-thread dianggap eksperimental dan tidak stabil. Plus, banyak ekstensi PHP tidak mendukung mode aman-thread atau tidak diuji dengan baik dalam mode aman-thread.

---------------- PHP sebagai CGI ----------------

Ini tampaknya merupakan konfigurasi default paling lambat yang tampaknya merupakan "penipu" itu sendiri;)

---------------- PHP sebagai CGI via mod_suphp ----------------

Pro : suphp memungkinkan Anda untuk mengeksekusi skrip php atas nama pemilik file skrip. Dengan cara ini Anda dapat memisahkan situs yang berbeda dengan aman di mesin yang sama. Juga, suphp memungkinkan untuk menggunakan file php.ini yang berbeda per host virtual.

Cons : PHP dalam mode CGI berarti lebih sedikit kinerja. Dalam mode ini Anda tidak dapat menggunakan akselerator php seperti APC karena setiap kali proses baru muncul untuk menangani skrip rendering cache dari proses sebelumnya yang tidak berguna. BTW, apakah Anda tahu cara menerapkan beberapa akselerator dalam konfigurasi ini? Saya mendengar sesuatu tentang menggunakan shm untuk cache bytecode php. Selain itu, Anda tidak dapat mengonfigurasi PHP melalui file .htaccess dalam mode ini. Anda perlu menginstal P ECL htscanner untuk ini jika Anda perlu mengatur berbagai opsi per-skrip melalui .htaccess (arahan php_value / php_flag)

---------------- PHP sebagai CGI via suexec ----------------

Konfigurasi ini terlihat sama dengan suphp, tapi saya dengar, itu lebih lambat dan kurang aman. Pro dan kontra yang hampir sama berlaku.

---------------- PHP sebagai FastCGI ----------------

Pro : Standar FastCGI memungkinkan proses php tunggal untuk menangani beberapa skrip sebelum proses php dimatikan. Dengan cara ini Anda mendapatkan kinerja karena tidak perlu memunculkan proses php baru untuk setiap skrip. Anda juga dapat menggunakan akselerator PHP dalam konfigurasi ini (lihat bagian kontra untuk komentar). Juga, FCGI hampir seperti suphp juga memungkinkan proses php dijalankan atas nama beberapa pengguna. mod_fcgid tampaknya memiliki dukungan fcgi paling lengkap dan fleksibilitas untuk apache.

Cons : Penggunaan php accelerator dalam mode fastcgi akan menyebabkan konsumsi memori tinggi karena setiap proses PHP akan memiliki cache bytecode sendiri (kecuali ada beberapa akselerator yang dapat menggunakan memori bersama untuk cache bytecode. Apakah ada seperti itu?). FastCGI juga sedikit rumit untuk dikonfigurasi. Anda perlu membuat berbagai file konfigurasi dan membuat beberapa modifikasi konfigurasi.

Tampaknya, fastcgi adalah konfigurasi PHP yang paling stabil, aman, cepat dan fleksibel, namun agak sulit untuk dikonfigurasi. Tapi, mungkin, saya melewatkan sesuatu?

Komentar dipersilahkan!

— Vladislav Rastrusny
sumber

3

Menjalankan PHP melalui FastCGI tentu akan memberi Anda fleksibilitas paling. Anda tidak hanya dapat menggunakan Apache mpm-pekerja dengan aman, Anda bahkan dapat menggunakan server web lain secara bersamaan (mis. Nginx).

Tetapi bahkan ketika tinggal dengan Apache, "PHP via FastCGI" pada saat ini bukan satu pilihan, tetapi setidaknya dua: mod_fastcgi, mod_fcgid. Selain itu, Anda dapat menggunakan proses FastCGI dinamis, statis, atau eksternal; dengan atau tanpa suexec. Dan kemudian ada manajer proses FastCGI internal PHP, yang sekarang digantikan oleh PHP-FPM yang sangat bagus di PHP 5.3. Semua opsi tersebut memiliki pro dan kontra yang berbeda dan dapat menyebabkan masalah yang berbeda.

Diberi pilihan, saya akan memilih mod_fastcgi dengan PHP-FPM saat ini, terutama karena memungkinkan untuk pengaturan yang sangat fleksibel dan stabil.

— pangeran
sumber

1

> Saya akan memilih mod_fcgid dengan PHP-FPM. Ini akan mencegah Anda menggunakan APC. Hanya mod_fastcgi yang memungkinkan untuk menggunakan server FCGI eksternal (yaitu PHP-FPM). Jika Anda menggunakan mod_fcgid, semua keuntungan yang diberikan oleh php-fpm akan menjadi nol.

— Vladislav Rastrusny

Itu, tentu saja, kesalahan ketik bodoh. Maaf atas kebingungannya, saya memperbaikinya.

— earl

2

Tidak benar-benar menjawab pertanyaan Anda, tetapi saya tidak mendapatkan hal ini tentang FastCGI yang sulit dikonfigurasi. Berbeda dengan metode lain yang harus diganti (mod_php, mod_python, ...) sehingga mungkin diperlukan penulisan ulang sebagian kode. Itu bisa menjadi bagian yang sulit, tetapi untuk mengkonfigurasi Apache, setidaknya, saya menemukan itu mudah. Sebagai contoh, saya sedang menguji aplikasi WSGI dengan python, dan saya ingin melihat bagaimana kinerjanya dengan semua protokol yang didukung WSGI. Ini adalah file host virtual dengan konfigurasi untuk semua protokol (dengan 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>

Sepertinya tidak rumit bagi saya. Tentu saja, FastCGI mendukung banyak opsi dan dapat di-tweak sampai mati, tetapi itu masalah lain.

Untuk menjalankan adalah sebagai pengguna yang berbeda, gunakan suexec dan FastCGIWrapper, maka itu menjadi:

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>

Dan lihat tautan ini untuk php.ini khusus, tetapi Anda harus dapat menentukannya dengan -initial-envopsi, yaitu

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

— Dan Andreatta
sumber

Ya, menambahkan config ke apache itu sederhana. Tetapi konfigurasi Anda tidak memungkinkan untuk mengeksekusi skrip atas nama pemiliknya atau setidaknya oleh pengguna tertentu. Juga, custom php.ini tidak dapat digunakan dalam kasus Anda (Saya lebih suka membatasi open_basedir untuk setiap virtualhost hanya untuk direktori-nya)

— Vladislav Rastrusny

Saya tidak tahu PHP dengan baik, tetapi itu adalah masalah yang sama yang Anda hadapi dengan CGI langsung. Dan Anda dapat dengan mudah menjalankan fastcgi sebagai server eksternal seperti halnya pengguna yang Anda suka.

— Dan Andreatta

Menambahkan info tambahan ke jawabannya.

— Dan Andreatta

1

Kandidat yang baik adalah: Apache 2 ITK MPM

apache2-mpm-itk (singkatnya mpm-itk) adalah MPM (Multi-Processing Module) untuk server web Apache. mpm-itk memungkinkan Anda untuk menjalankan masing-masing vhost Anda di bawah uid dan gid yang terpisah - singkatnya, skrip dan file konfigurasi untuk satu vhost tidak lagi harus dapat dibaca untuk semua vhost lainnya.

Telah bekerja untuk salah satu klien kami dengan sangat baik dengan ratusan VirtualHosts dengan pengunjung yang cukup banyak.

Anda mendapatkan semua Pro dari menjalankan PHP sebagai modul dan memilah-milah beberapa kontra.

— rkthkr
sumber

Ya, tetapi terakhir diperbarui setahun sebelumnya. Dan apa yang lebih penting membuka potensi keamanan keseluruhan. "Karena mpm-itk harus dapat setuid (), ia berjalan sebagai root (walaupun dibatasi dengan kemampuan POSIX jika memungkinkan) sampai permintaan diuraikan dan vhost ditentukan. Ini berarti bahwa lubang keamanan apa pun sebelum permintaan diuraikan akan sebuah lubang keamanan root. (Tempat yang paling mungkin adalah di mod_ssl.) "

— Vladislav Rastrusny

Kode berfungsi, sangat stabil dan mungkin tidak ada alasan untuk memperbaruinya. Modul ini mendapat pengembang Debian aktif (tidak tahu tentang pengembang asli). Dan itu FOSS dan tidak terlalu rumit.

— rkthkr

0

Bagi saya, pertanyaannya adalah apa tujuan dari server web. Apakah ini melayani lebih dari satu host virtual? Jika demikian, maka Anda perlu mengorbankan kinerja untuk keamanan yang terisolasi. Ya kinerja memang menderita, tetapi dengan perangkat keras saat ini masih harus mengambil sedikit lalu lintas untuk membawa masalah kinerja utama.

Jika kinerja itu penting, jalankan satu situs di VPS atau server khusus dan konfigurasikan untuk kinerja.

— Justin Higgins
sumber

Saya hanya bertanya tentang kemungkinan varian. Bukan tentang memilih yang terbaik. Saya akan memilih sendiri.

— Vladislav Rastrusny