Hangi Apache MPM'nin kullanılacağını nasıl seçerim?

261

Bu, doğru Apache httpd MPM'nin seçilmesiyle ilgili Kanonik bir Soru .

Apache'nin sunduğu farklı MPM'ler - 'işçi', 'etkinlik', 'prefork' vb.

Aralarındaki temel farklar nelerdir ve verilen dağıtım için hangisinin en iyi olacağına nasıl karar verebilirim?

— Tiffany Walker
kaynak

4

Mod_php'yi destekliyorsanız, prefork yapıyorsunuz demektir.

— Zoredache

6

@Zoredache:? PHP'den hiç bahsetmedi ve olsaydı bile, mod_php sadece olayı dışladı. Yoksa 8 yıl önce RL tarafından yapılan bir açıklamaya hâlâ sarılıyor musunuz? PHP'de iş parçacığı apache ile ilgili son giriş 2005 yılında yapıldı.

— symcbean

2

Üzgünüz - bunu kapatmak için oy kullanmak zorundayım - burada cevaplamak için çok geniş bir soru.

— symcbean

1

@symcbean Re: PHP ve Konular - PHP'nin çekirdeği bugünlerde iş parçacığı kadar güvenli ama derleyen insanları bulabileceğiniz pek çok şey yok. Geçen yıl olduğu gibi kısa bir süre önce ısırıldım, bu yüzden hala "üretimde ona güvenmeden önce bir test" durumu hala ...

— voretaq7

Kullanmakta olduğunuz işletim sistemine bağlı olarak, standart bir kurulumla mevcut tüm seçeneklere sahip olmayabilirsiniz.

— John Gardeniers

415

Orada bir dizi olan MPM modüllerinden (Çok İşleme Modülleri), ama bugüne kadar en yaygın olarak (en azından * nix platformlarında) kullanılan üç ana olanları şunlardır: prefork, workerve event. Temel olarak, Apache web sunucusunun evrimini ve sunucunun uzun süredir (yazılım terimleriyle) geçmişindeki hesaplama kısıtlamaları dahilindeki HTTP isteklerini yerine getirmek için oluşturulmuş farklı şekilleri temsil eder.

`prefork`

mpm_prefork... iyi .. her şeyle uyumlu. İstekleri yerine getirmek için bir takım alt süreçleri iptal eder ve alt süreçler bir seferde yalnızca bir talepte bulunur. Sunucu işlemi orada oturuyor, harekete hazır ve iş parçacığı marşaljesiyle uğraşmak zorunda olmadığından, sadece bir seferde yalnızca tek bir istekle ilgilenirken daha modern dişli MPM'lerden daha hızlı - ama aynı anda talepler acı çekiyor, Bir sunucu işlemi ücretsiz olana kadar sırada bekletildiklerinden. Ek olarak, prefork çocuk işlemlerinin sayısında artış yapmaya çalışırken, bazı ciddi RAM'leri kolayca emebileceksiniz.

İş parçacığı güvenli olmayan bir modüle ihtiyacınız olmadıkça prefork kullanmanız büyük olasılıkla tavsiye edilmez.

Kullanılırsa: İplik kullanıldığında kopan modüllere ihtiyacınız olur mod_php. O zaman bile, FastCGI ve php-fpm.

Aşağıdaki durumlarda kullanmayın: Modülleriniz diş açmaya zorlamaz.

`worker`

mpm_workeriş parçacığı kullanır - eşzamanlılık için büyük bir yardımdır. İşçi, bazı çocuk süreçlerini döndürür; prefork'a benzer şekilde, bazı yedek dişler mümkün olduğunda gelen bağlantılara servis vermek için hazır tutulur. Bu yaklaşım RAM'de çok daha hassastır; Aynı zamanda, eşzamanlılığı çok daha kolay bir şekilde ele alıyor, çünkü bağlantıların ön-yedek bir sunucu yerine ücretsiz bir iş parçacığı (genellikle kullanılabilir) beklemesi gerekiyor.

Kullanıyorsanız: Apache 2.2 veya 2.4'tasınız ve öncelikle SSL kullanıyorsunuz.

Aşağıdaki durumlarda kullanmayın: Uyumluluk için önceden bilgi istemediğiniz sürece, gerçekten yanlış gidemezsiniz.

Bununla birlikte, basamakların bağlantılara bağlı olduğunu ve isteklere bağlı olmadığını unutmayın; bunun anlamı, canlı tutma bağlantısının kapalı olana kadar her zaman bir ipi tutmasıdır (bu, yapılandırmanıza bağlı olarak uzun sürebilir). Bu yüzden elimizde ..

`event`

mpm_eventyapısal olarak işçiye çok benzer; Apache 2.4'te “deneysel” den “stabil” duruma getirildi. En büyük fark, canlı bağlantılarla başa çıkmak için özel bir iş parçacığı kullanması ve yalnızca bir istek yapıldığında alt iş parçacıkları için el talepleri (istekleri tamamlandıktan hemen sonra derhal serbest bırakılmasına izin vermek). Bu, bir anda mutlaka aktif olmak istemeyen, ancak ara sıra talepte bulunan müşterilerin eşzamanlılığı için ve müşterilerin uzun süre hayatta kalma zaman aşımına uğraması için harikadır.

Buradaki istisna, SSL bağlantılarıyla; Bu durumda, çalışanla aynı şekilde davranır (verilen bir bağlantıya verilen bağlantıyı, bağlantı kapanana kadar yapıştırma).

Kullanıyorsanız: Apache 2.4'tesiniz ve benzeri konularsınız, fakat boşta bağlantıları bekleyen konulara sahip olmaktan hoşlanmıyorsunuz. Herkes konuları sever!

Aşağıdaki durumlarda kullanmayın: Apache 2.4'te değilsiniz veya uyumluluk için ön desteğe ihtiyacınız var.

Günümüzün slowloris , AJAX ve 6 TCP bağlantısını (tabii ki canlı tutularak) sunucunuzla çoğaltmak isteyen tarayıcılarda, eşzamanlılık sunucunuzu ölçeklendirmek ve ölçeklendirmek için önemli bir faktördür. Apache'nin tarihi, bu bağlamda bunu çözmüştür ve kaynak kullanımı veya ölçek açısından nginx veya lighttpd gibi şeylerle gerçekten aynı düzeyde olmasa da, geliştirme ekibinin hala ilgili bir web sunucusu oluşturmak için çalıştığı açıktır. bugünün yüksek istek eşzamanlılık dünyasında.

— Shane Madden
kaynak

3

-1: IME, işçi yalnızca httpd ayakizinin boyutunu% 15 oranında azaltır (IIRC Linux, RSS’de COW’yu rapor eder; bu da çataldan önce olduğundan daha fazla bellek kullanıyormuş gibi görünmesini sağlar). Bir işlem için çekirdek ayak izi ile NPTL iplik arasında önemsiz bir fark var. Toprak paramparça olmaktan çok uzun bir yol. Neden bir iş parçacığını beklemenin ve tahsis etmenin, zamanlama teriminde bir (önceden-çatallanmış) işlemi beklemekten / programlamaktan daha etkili olduğunu düşündüğünüzü anlamıyorum. Sence SSL’nin tümüyle üzerinde ne düşündüğünü düşünüyorsun.

— symcbean

9

@symcbean Yani% 15 RAM kullanımının anlamlı olmadığını mı söylüyorsunuz? Bu iyi, ama benim fikrim aksi takdirde olur. Eşzamanlılık performans iddiaları benim değil. Buraya bakınız . Ve SSL farkı açıkça MPM etkinliğinin belgelerinde açıklanmıştır:

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

3

@ShaneMadden `ve hala kaynak kullanımı ya da ölçek açısından nginx ya da lighttpd gibi şeylerle gerçekten uyuşmuyor olsa da, her iki sistemin de apache tabanını kullandım.

— Kelly Elton

@ShaneMadden, SSL ve MPM olayıyla ilgili olarak: nginx'in bunu apache'den önemli ölçüde daha iyi idare edip etmediğini biliyor musunuz?

— DASKAjA

Eğer appm 2.4'ü mpm modüllerini bilmeden derlerseniz, olay mpm modülü isimli modül ile gelir ve mod_php7 ile çalışır (şu anda mpm'yi araştırıyorum çünkü apache2.4 aynı mysql sunucusuyla apache 2.2 mysql bağlantı sınırını aştığı için) değil)

— BioHazard

8

İşte giflerle nasıl çalıştığının iyi bir açıklaması:

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

Kısaca: üzerinde eğer 2.4 ve bir şekilde httpd ihtiyaç ters vekil (hareket memuru) böylece seçim bir olduğunu Event MPM

— Yura
kaynak

SSL kullansak bile mi? Apache'yi SSL olmayan bir web sitesinde proxy ve SSL etkinleştiricisi olarak kullanıyorum.

— bokan

@bokan evet gibi görünüyor, bu en iyisi, ama yine de proxy sunucusu SSL ile sınırlıdır

— Yura

Vay ~ Blog yazısı kabul edilen cevaptan çok daha iyi ve gifler harika! Thankssss. Günümü kurtardın.

— Rick

6

Şubat 2018'den itibaren, Event MPM için Apache 2.4 belgeleri, Proache'yi bir vekil olarak kullanmanın 2.4.24'ten beri "gelişmiş bağlantı yönetimi" nde tasarlandığı gibi çalışmaya devam edeceğini belirtir. Bkz Sınırlamalar bölümüne.

Mesele şu ki, bir vekil olarak, işçi cevabın sonunun nerede olduğunu söyleyemiyor ve kontrolü dinleyiciye geri vermeden önce tüm cevabın görünmesini beklemek zorunda kalacak.

Bu nedenle, İşçi modelinin kullanılması, apache'nin proxy olarak kullanıldığı durumlarda en iyisi olabilir. Proxy ortamında olay modelinin avantajları olup olmadığı benim için net değil, ama belki de var.

— Andor
kaynak

5

Hangi Apache modüllerini kullanmak istediğinize bağlı. İşçi genel olarak varsayılan seçenek olduğunu düşünüyorum, ancak bazı (eski) modüller çatal gerektirir ve prefork'a bağlıdır.

Tercihleriniz yoksa, işletim sistemi dağıtımınızdan tercih edilen bağımlılıkla devam etmenizi öneririm. Örneğin Ubuntu, Apache2'yi kurarken varsayılan olarak mpm-worker'ı kuracaktır.

— Jeroen
kaynak