Pertanyaan Bagaimana cara memilih MPM Apache mana yang akan digunakan?


Ini adalah sebuah Pertanyaan Kanonis tentang memilih Apache httpd MPM yang tepat.

Saya sedikit bingung antara MPM berbeda yang ditawarkan oleh Apache - 'pekerja', 'acara', 'prefork', dll.

Apa perbedaan utama di antara mereka, dan bagaimana saya bisa memutuskan yang mana yang terbaik untuk penyebaran yang diberikan?


243
2018-04-26 18:40




Jika Anda mendukung mod_php, maka Anda melakukan prefork. - Zoredache
@Zoredache:? dia tidak pernah menyebutkan PHP, dan bahkan jika dia punya, mod_php hanya akan mengesampingkan event. Atau apakah Anda masih menempel pada pernyataan yang dibuat oleh RL 8 tahun yang lalu? Bug terakhir yang di-login di PHP terkait dengan threaded apache adalah pada tahun 2005. - symcbean
Maaf - harus memilih untuk menutup ini - adalah pertanyaan yang terlalu luas untuk dijawab di sini. - symcbean
@symcbean Re: PHP dan Threads - Inti PHP adalah threadsafe hari ini tetapi banyak hal lain yang Anda akan menemukan orang-orang yang menyusun tidak. Saya telah digigit baru-baru ini tahun lalu, jadi ini sangat "uji (ekstensif) sebelum mengandalkannya dalam produksi" situasi masih ... - voretaq7
Tergantung pada OS yang Anda gunakan, Anda mungkin tidak memiliki semua opsi yang tersedia dengan pemasangan standar. - John Gardeniers


Jawaban:


Ada sejumlah Modul MPM (Multi-Processing Modules), tetapi sejauh ini yang paling banyak digunakan (setidaknya pada * platform nix) adalah tiga yang utama: prefork, worker, dan event. Pada dasarnya, mereka mewakili evolusi server web Apache, dan cara yang berbeda bahwa server telah dibangun untuk menangani permintaan HTTP dalam kendala komputasi waktu selama sejarahnya (dalam istilah perangkat lunak).


prefork

mpm_prefork ini .. yah .. cocok dengan semuanya. Ini berputar dari sejumlah proses anak untuk melayani permintaan, dan proses anak hanya melayani satu permintaan dalam satu waktu. Karena ada proses server yang duduk di sana, siap beraksi, dan tidak perlu berurusan dengan marshaling benang, sebenarnya lebih cepat daripada MPM yang lebih modern ketika Anda hanya berurusan dengan satu permintaan pada satu waktu - tetapi permintaan bersamaan menderita, karena mereka dibuat untuk menunggu dalam antrean hingga proses server gratis. Selain itu, mencoba untuk memperbesar dalam hitungan proses anak prefork, Anda akan dengan mudah menyedot beberapa RAM yang serius.

Mungkin tidak disarankan untuk menggunakan prefork kecuali Anda memerlukan modul yang tidak aman.

Gunakan jika: Anda perlu modul yang pecah ketika benang digunakan, seperti mod_php. Bahkan kemudian, pertimbangkan untuk menggunakan FastCGI dan php-fpm.

Jangan gunakan jika: Modul Anda tidak akan rusak dalam threading.

worker

mpm_worker menggunakan threading - yang merupakan bantuan besar untuk konkurensi. Pekerja memutar beberapa proses anak, yang pada gilirannya akan memutus benang anak; mirip dengan prefork, beberapa thread cadangan tetap siap jika memungkinkan, untuk melayani koneksi masuk. Pendekatan ini jauh lebih ramah pada RAM, karena jumlah thread tidak memiliki pengaruh langsung pada penggunaan memori seperti jumlah server di prefork. Ini juga menangani konkurensi lebih mudah, karena koneksi hanya perlu menunggu untaian gratis (yang biasanya tersedia) daripada server cadangan di prefork.

Gunakan jika: Anda menggunakan Apache 2.2, atau 2.4 dan Anda menjalankan terutama SSL.

Jangan gunakan jika: Anda benar-benar tidak bisa salah, kecuali Anda memerlukan prefork untuk kompatibilitas.

Namun, perhatikan bahwa tapak terpasang koneksi dan tidak permintaan - yang berarti koneksi keep-alive selalu menahan sebuah thread sampai tertutup (yang bisa lama, tergantung pada konfigurasi Anda). Itu sebabnya kami punya ..

event

mpm_event sangat mirip dengan pekerja, secara struktural; itu baru saja dipindahkan dari status 'eksperimental' ke status 'stabil' di Apache 2.4. Perbedaan besar adalah menggunakan thread khusus untuk menangani koneksi yang disimpan-hidup, dan permintaan tangan ke bawah ke utas anak hanya ketika permintaan benar-benar telah dibuat (memungkinkan utas tersebut untuk kembali ke cadangan segera setelah permintaan selesai). Ini bagus untuk konkurensi klien yang tidak selalu semua aktif dalam satu waktu, tetapi membuat permintaan sesekali, dan ketika klien mungkin memiliki waktu tunggu terus-hidup yang panjang.

Pengecualian di sini adalah dengan koneksi SSL; dalam hal ini, ia berperilaku identik dengan pekerja (menempelkan koneksi yang diberikan ke suatu thread tertentu sampai koneksi tertutup).

Gunakan jika: Anda berada di Apache 2.4 dan menyukai utas, tetapi Anda tidak suka ada untaian yang menunggu koneksi tidak aktif. Semua orang suka utas!

Jangan gunakan jika: Anda tidak menggunakan Apache 2.4, atau Anda membutuhkan prefork untuk kompatibilitas.


Di dunia sekarang ini Kukang, AJAX, dan browser yang suka multipleks 6 koneksi TCP (dengan tetap-hidup, tentu saja) ke server Anda, konkurensi merupakan faktor penting dalam membuat skala dan skala server Anda dengan baik. Sejarah Apache telah mengikatnya dalam hal ini, dan sementara itu benar-benar masih tidak setara dengan orang-orang seperti nginx atau lighttpd dalam hal penggunaan sumber daya atau skala, jelas bahwa tim pengembangan sedang bekerja untuk membangun server web yang masih relevan dalam dunia konkret permintaan tinggi saat ini.


396
2018-04-27 02:27



-1: IME, pekerja hanya mengurangi ukuran jejak httpd di wilayah 15% (laporan IIRC Linux SAP dalam RSS yang membuat tampilan pra-garpu seolah-olah menggunakan lebih banyak memori daripada yang ada). Ada perbedaan yang dapat diabaikan antara jejak kernel untuk sebuah proses dan sebuah thread NPTL. Ini jauh dari menghancurkan bumi. Saya tidak mengerti mengapa Anda berpikir bahwa menunggu dan mengalokasikan sebuah thread lebih efisien dalam hal penjadwalan daripada menunggu / menjadwalkan proses (pra-forked). Atau apa yang Anda pikirkan tentang SSL secara keseluruhan. - symcbean
@symcbean Jadi, Anda mengatakan bahwa penggunaan RAM 15% tidak signifikan? Tidak apa-apa, tetapi pendapat saya adalah sebaliknya. Klaim kinerja konkret bukanlah milik saya. Lihat sini. Dan perbedaan SSL terbilang jelas dalam dokumentasi untuk acara MPM: The improved connection handling does not yet work for certain connection filters, in particular SSL. For SSL connections, this MPM will fall back to the behaviour of the worker MPM and reserve one worker thread per connection. - Shane Madden♦
@ShaneMadden `dan sementara itu masih benar-benar tidak setara dengan orang-orang seperti nginx atau lighttpd dalam hal penggunaan sumber daya atau skala. Saya sudah memiliki lantai apache kedua sistem tersebut. - Kelly Elton
@ShaneMadden sehubungan dengan masalah dengan SSL dan kejadian MPM: Apakah Anda tahu jika nginx menangani ini secara signifikan lebih baik daripada apache? - DASKAjA
Tampaknya jika Anda mengkompilasi apache 2.4 tanpa mengetahui tentang modul mpm datang dengan modul bernama event mpm module dan bekerja dengan mod_php7 (sekarang saya mn mpm meneliti karena apache2.4 melebihi batas koneksi mysql sementara apache 2.2 dengan server mysql yang sama adalah tidak) - BioHazard


Sebagian besar tergantung pada modul Apache mana yang ingin Anda gunakan. Saya pikir pekerja pada umumnya adalah pilihan default, tetapi beberapa modul (yang lebih tua) memerlukan forking dan bergantung pada prefork.

Jika Anda tidak memiliki preferensi, saya sarankan Anda pergi dengan ketergantungan yang disukai dari distribusi OS Anda. Ubuntu misalnya secara default akan menginstal mpm-worker ketika Anda menginstalasi Apache2.


5
2018-04-26 19:32





Berikut adalah penjelasan yang bagus tentang cara kerjanya dengan gif:

https://www.datadoghq.com/blog/monitoring-apache-web-server-performance/

Secara singkat: jika Anda di 2.4 dan Anda perlu httpd sebagai reverse proxy (dispatcher) jadi pilihan Anda adalah Acara MPM


5
2018-06-21 13:10





Pada Februari 2018, dokumentasi Apache 2.4 untuk Peristiwa MPM menyatakan bahwa menggunakan Apache sebagai proxy akan menjaga "penanganan koneksi yang ditingkatkan" sejak 2.4.24 bekerja sebagaimana dirancang. Lihat Keterbatasan bagian.

Masalahnya adalah bahwa, sebagai proxy, pekerja tidak dapat mengetahui di mana akhir dari respons, dan akan dipaksa untuk menunggu sampai seluruh tanggapan terlihat sebelum mengembalikan kontrol kepada pendengar.

Untuk alasan ini, tampaknya menggunakan model Worker mungkin yang terbaik ketika apache digunakan sebagai proxy. Tidak jelas bagi saya jika ada keuntungan untuk model acara di lingkungan proksi, tapi mungkin ada.


3
2018-02-14 15:01