Nginx vs Apache - Orada herhangi bir gerçek kullanım karşılaştırması ve istatistik var mı?


45

Oynayacak yeni bir sunucum var ve boş bir tuvale bakıyorum. İstediğim her şeyi koyabilirim. Apache ile rahat ederken, nginx'in Apache'den çok daha fazla trafikte nasıl işleyebileceğini duymaya devam ediyorum, 10, 100, hatta daha fazla faktör. Sadece "çok daha hızlı" değil.

Makaleleri ararken, Drupal ile ilgisi olmayan birçok şey bulabilirim. Veya, Drupal ile ilgili bir makaleyle karşılaştığımda, ya 1) birinin nasıl kurulacağını açıklamaya çalışan bir yapılandırma dosyası ya da 2) "hayır, nginx kullanma, PHP ile Apache kullan fcgid "ama neden olarak hiçbir zaman açıklama yok.

Peki, Drupal'a gelince, buradaki gerçek nedir?

Örnek olarak, bu 2bits.com makalesinin satırları boyunca bir şey arıyorum . Burada yazar, Apache'nin mod_php vs Apache'ye fcgid ile oldukça kapsamlı bir şekilde bakıp, her birinin artılarını ve eksilerini tartıştı ve gerçek dünyadaki etkiyi göstermek için bir örnek olay incelemesi yaptı. Bu makalede, durumum için hangi yaklaşımın en iyi olacağı konusunda bilinçli bir karar vermem için yeterli bilgi var.

Bu yazar mod_php ile fcgid'yi karşılaştırırken, Apache ve Nginx arasında aynı tür kapsamlı ve gerçek dünyaya bakıyorum.

Herkes Nginx'e geçti ve Apache'ye kıyasla yaptığı farktan dolayı “havaya uçtu”? Zaten APC, Memcache ve Varnish gibi agresif önbellekleme kullanan, en iyi duruma getirilmiş ortamlar için bile, değişen tek değişken Apache'yi Nginx ile değiştirmek olduğunda, bu yeni, alternatif teknolojiye yatırım yapmayı hak edecek kadar büyük bir fark yaratıyor. ?

Bu sunucuda devam edecek site ayda 2 milyon Avv PV alıyor. Cent OS 6. çalıştıran LAMP yığını. 8 GIGS ram ile 4 çekirdekli işlemci. Memcached ve APC karışımın bir parçası olacaktır. Drupal kurulumu hakkında özel bir şey yok - temel olarak yaklaşık 50 modül içeren vanilya 7.


2
Belirli bir siteyi performans için ayarlamak istiyorsanız, diğer kişilerin çalışmalarına güvenmekten ziyade kendi testlerinizi yapmaktan daha iyidir. Örneğin, oturum açmış kullanıcılara karşı anonim karışımı, büyük bir faktördür. Genelde anonim trafik alan bir sitenin performans istatistiklerine bakarsanız ve sizinkiniz böyle değilse, rahatsız etmeyebilirsiniz. Ancak siteniz büyük oranda isimsiz trafik içeriyorsa, deneyimime göre Varnish'i web sunucunuzun önüne koymak, arkasındaki sunucudan çok daha büyük bir fark yaratıyor.
Alfred Armstrong

Yanıtlar:


60

Açıkçası, bu sorduğunuz soruyu cevaplamıyor. Yine de faydalı olacağını umuyorum.

Apache / Nginx / Lighttpd / diğer bir web sunucusu. Hangisini seçtiğimin önemi var mı? Kısacası, hayır .

Çok daha uzun cevap:

Eğer ve ancak eğer, oturum açan kullanıcılarınızın çok büyük bir yüzdesine sahipseniz, web sunucunuzun performansını hiç umursamamanız gerekir. Kullanıcılarınız anonim ise, kaynaklarınızı daha iyi önbelleğe alınabilir hale getirmeye kıyasla teorik olarak bu katmanlarda mutlak pales optimizasyonundan elde edebileceğiniz herhangi bir fark. Eğer css dosyalarınızda uygun önbellek başlıkları varsa, UA ikinci kez onlardan bile istemez. Bu önemli. Sayfalarınızı Varnish veya benzer bir yazılım çözümünde önbelleğe alabilirseniz, o sayfaya hizmet etmek karma arama yapma ve ardından doğrudan RAM'den büyük miktarda veri döndürme meselesidir. Bu önemli. Bu senaryoların her ikisinde de, HTTP arka plan programı asla dahil olmaz, PHP çağrılmaz. Drupal önyükleme yapmaz. RAM'e büyük modül dizileri yüklenmemelidir, zaman alan veritabanı sorgulamaları yapılmaz.

Tam sayfa yüklemesi yaparken, soğuk bir önbellekten, giriş yapmış bir kullanıcı için karmaşık bir sayfada; bir sürü şey oluyor. Evet, web sunucusu gelen istekle uğraşmakta, bazı başlıkları belirlemekte ve yanıtı geri almakla ilgilenmektedir. Ancak geçen süre, Drupal'ın tam bir önyükleme gerçekleştirmesi ve yanıtını vermesi bağlamında bile alakalı değil. Yürütülen yüzlerce veritabanı sorgusu olabilir. PHP'deki oldukça karmaşık mantık çözümleyici tarafından değerlendirilir. Çok sayıda modül RAM'e yüklenmektedir. Bunlardan herhangi birinin performansını arttırmak, performansa ciddi bir katkı yapması daha muhtemeldir.

Argüman uğruna: Diyelim ki her şeyi optimize etmek için çok fazla zaman harcadınız.

  1. Sen çalıştırmak APC (Ya Doktoru + ) ve PHP en son ve en hızlı versiyonu.
  2. DB sorguları azdır.
  3. PHP mantığı azaltıldı.
  4. Varnish'te yapabileceklerini önbelleğe al.
  5. Tüm sitenizi, çok sayıda istemci tarafını önbelleğe alabilmeniz ve ECMAScript'te çok fazla ağır kaldırma yapabilmeniz için yeniden yapılandırdınız .

Çok sayıda oturum açmış kullanıcınız varsa ve yukarıdakilerin hepsiyle ilgilendiyseniz, muhtemelen performans ayarlaması veya web sunucunuzu değiştirmekten başka bir fark yaratabilirsiniz. Ancak, tahmin et ne oldu. Siteniz çok karmaşık ve belirli kullanıcılarınızın kullanım şekilleri benzersiz . Genel bir cevap yok. Tüm farklı web sunucularını bir yük dengeleyicisinin arkasına kurmanız ve senaryonuz altında nasıl davrandıklarını görmeniz gerekir .

Yukarıdakiler, web sunucusunu optimize etmek için zaman performansının harcanan zamanın kötü kullanımı olduğu sonucuna mantıklı bir şekilde ulaşma çabasıydı. Yine de birisinin yukarıda delik açmasını isterdim, muhtemelen bundan yeni bir şeyler öğrenebilirim. :)

Diğer bazı notlar:

  1. Sırasında DrupalCon Kopenhag keynote , PHP yaratıcısı Rasmus Lerdorf , Nginx kendisi kullanarak, Drupal performans konu üzerine konuşan "İnsanlar her zaman gerçekten, web sunucusu oldukça fazla ilgisiz değil meselesidir gelmez ... web sunucuları hakkında bana sor" dedi . (Kabaca 26:30 da videoda)
  2. Facebook, PHP kodunu% 100 “kızarmak” ile hızlandırmak için Drupal'ın kendisinden önemli ölçüde daha büyük bir kod üssü olan Hiphop'u yazmak için sayısız saat harcadı . $ wc -l $(find . -type f | grep -v "^\.git" | grep -v "^\.hphp/third_party") | sort -nr | head -n1Hiphop'u inceledim ve 1.512.481 kod satırından oluştuğunu gördüm. Bu, PHP'nin hızını artırmak için harcanan delice bir iş. Sanırım PHP'nin hızı onlar için çok önemli.
  3. İyi önbelleğe almanın, web sunucusunu ayarlamaktan çok daha büyük bir etkiye sahip olacağını söylemiş miydim?
  4. Apache 2.4'ün piyasaya sürülmesiyle Jim Jagielski temel olarak Apache 2.4'ün olaya dayalı sunuculardan daha hızlı olduğunu iddia ediyor .
  5. Sadece bu sorunun ortaya çıktığı The Dream Team ile Drupal Performance ve Ölçeklenebilirlik'e katıldım . Hangisini seçeceğinizle ilgili tüm cevapların performansla ilgisi yoktu. "Hangisini nasıl yapılandırdığınızı zaten biliyorsunuz" ve "Hangisi en basit teknoloji yığınını oluşturmanıza izin verir" gibi şeyler, diğerinin üstesinden gelmek için belirtilen nedenler arasındaydı. Performans vermedi değil giriyor.

4
CSS, JS ve resim isteklerinin büyük çoğunluğunun web sunucusuna çarpmasını önlemek için CDN'yi unutmayın.
mpdonadio

Mükemmel nokta! Sanırım bir noktada drupal.stackexchange.com/questions/24180/… yazmam gerekecek . Apache / Nginx ile ilgili bir tartışma, kapsamlı bir performans optimizasyonu listesi oluşturmak için en uygun yer gibi görünmüyor.
Letharion

1
Bu harika bir cevap. Sadece bir nitpick: "ECMAScript" ve "JavaScript" değişmeli olarak kullanmamalısınız. JavaScript'te ECMAScript'ten daha fazlası var.

Önbelleğin web sunucusu hızından çok daha önemli olduğunu söylüyorsunuz. Bil bakalım ne oldu? Bir web sunucusu diğerinden daha az bellek kullanıyorsa, önbelleğe almak için daha fazla RAM kullanabilirsiniz. Biz söyleyebiliriz Yani olup web sunucunuzun doğru, tüm RAM yemez düzgün böylece ayarlamak için önemli?
pqnet

Sunucunuzu daha az RAM kullanmak için ayarlamak kesinlikle iyidir, ancak yüksek performanslı bir bölgeye girmeye çalışıyorsanız, büyük olasılıkla özel bir sunucuda vernik kullanıyorsanız, http sunucunuz ve önbelleğiniz aynı bellek için rekabet etmeyecektir.
Letharion

32

Tamam, bu soru zaten cevaplandırılmış olmasına rağmen, bir kez daha necromancing ediyorum, çünkü öncelikle bu cevapların bir fark yaratmadığı konusundaki imalarından hoşlanmıyorum ve bir web geliştiricisi olarak tutkuyla önbelleğe almaktan nefret ediyorum .

Apache ve nginx arasındaki fark, "bir talebe ne kadar hızlı cevap verebilecekleri" değil, aynı miktarda donanımda (özellikle sınırlı kaynaklarda) ne kadar talep sunabilecekleridir.

Apache süreç tabanlı bir sunucudur. Yani her istek için bir süreç gerektiriyor. Nginx, olaya dayalı bir sunucudur; anlam, işlemler ya da iş parçacığı yerine (zaman uyumsuz) bir olay döngüsü kullanır.

Ve (Apache gibi) süreç tabanlı sunucu ise olabilir örneğin 10'0000 eşzamanlı istek gibi ağır yükler, nginx kullanımlar sadece birkaç altında, hafif yükler altında (nginx gibi) bir zaman uyumsuz olay tabanlı sunucu ile az ya da çok par gerçekleştirmek megabayt RAM, Apache'nin yalnızca web sunucusu için birkaç yüz megabayt gerektirdiği halde (bunu yapabilmek için çok daha fazla kaynak gerektiren web uygulaması dahil değil).

Bu yüzden ağır yükler altında Apache'nin çok fazla RAM tükettiğini göreceksiniz ki bu da performansı şaşırtıcı derecede düşürüyor.

Daha da önemlisi, daha yüksek RAM tüketimi, Apache'nin aynı donanım için nginx'ten daha az istekte bulunabileceği anlamına gelir; bu, Apache'nin aynı miktarda kullanıcı için daha fazla donanım gerektirdiği anlamına gelir, bu da daha yüksek bir TCO'ya (toplam sahip olma maliyeti) YG'nizi azaltan Apgin ile nginx'e göre (yatırım getirisini).

X eşzamanlı bağlantı tarafından kullanılan toplam hafıza (daha az iyidir)

Hafıza kullanımı

1 donanım setinde eşzamanlı bağlantılarda X saniyede yapılabilecek talepler (dahası daha iyidir)

Saniyedeki istek

Kaynak: ApacheBench, dreamhost.com tarafından

Ayrıca bu dijital okyanus yazısına bakınız.
Görünüşe göre, Apache için seçtiğiniz Bağlantı İşleme Mimarisine bağlı.


6
Kafasına çiviyi çarptın "... ne kadar hızlı bir talebe cevap verebileceklerini değil, aynı miktarda donanımda ne kadar istekte bulunabileceklerini de ..." Aslında sonuçta paranın karşılığını en iyi şekilde almak istiyorum . Aynı donanım ve diğer değişkenlerden oluşan bir makine göz önüne alındığında, eğer apache'nin sadece 200.000 hizmet verebileceği nginx ile günde 1.000.000 kullanıcıya hizmet verebilirsem, kesinlikle maliyet açısından en iyi seçenek nginx'dir. Belli bir donanım konfigürasyonu göz önüne alındığında, nginx'in apache'ye göre neler yapabileceği arasında büyük bir fark gördünüz mü?
blue928

2
Mevcut sürüm olan Apache 2.4, olaya dayalı bir modele sahip: httpd.apache.org/docs/current/mod/event.html
Greg

1
Ayrıca, bunun önemli olmadığını söyleyenler için “bir şeyleri önbelleğe aldığınız sürece iyi olacak”: önbelleğe alma konusunda ne yapmanız gerektiğini biliyor musunuz? ÜCRETSİZ RAM'e ihtiyacınız var.
pqnet

Genel olarak "Nginx daha müthiş" iddialarını sık sık görüyorum, ancak nadiren (hiç?) Kimsenin bunu sağlam kanıtlarla karşıladığını görüyorum. Her zaman "Yüksek yapılandırılmış nginx örneğim bir hisse senedi apache sunucusunu yendiği için artık havalı olduğumu kanıtladım çünkü diğer havalı çocuklar gibi nginx kullanıyorum". Nginx, bildiğim kadarıyla Apache'den çok daha iyi olabilir, ama henüz kimsenin bunun böyle olduğunu gösterdiğini görmedim.
Letharion

@Letharion: Yapıldı (dreamhost.com tarafından) ve isteğinize göre eklendi. Bu kıyaslama sonuçlarında gördüğünüz gibi, nginx açıkça bellek açısından daha verimli. Ayrıca muhtemelen: stock-nginx örneğim, stock-Apache örneğimi aynı bilgisayardaki aynı kıyaslamada yendi.
Quandary

16

Birkaç ay önce Apache'den Nginx / PHP-FPM'ye geçiyorum.

Bir drupal web sitesi ile bazı tezgah çalışmaları yaptım ve birkaç kullanım durumunu test ettim. 1 CPU ve 512 Mo RAM'e sahip bir VPS sunucusunda

Sadece önbellek ile drupal

nginx

ab -n 100 -c 30 xxx
Server Software:        nginx
Document Path:          /
Document Length:        24902 bytes

Concurrency Level:      30
Time taken for tests:   2.775 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      2529500 bytes
HTML transferred:       2490200 bytes
Requests per second:    36.04 [#/sec] (mean)
Time per request:       832.394 [ms] (mean)
Time per request:       27.746 [ms] (mean, across all concurrent requests)
Transfer rate:          890.28 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10
Maximum connect burst length: 1

Total: connections 100 requests 1000 replies 1000 test-duration 48.946 s

Connection rate: 2.0 conn/s (489.5 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 470.6 avg 489.5 max 522.2 median 488.5 stddev 9.5
Connection time [ms]: connect 0.2
Connection length [replies/conn]: 10.000

Request rate: 20.4 req/s (48.9 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 20.0 avg 20.4 max 20.8 stddev 0.2 (9 samples)
Reply time [ms]: response 46.8 transfer 2.1
Reply size [B]: header 450.0 content 24902.0 footer 2.0 (total 25354.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 6.50 system 17.58 (user 13.3% system 35.9% total 49.2%)
Net I/O: 507.3 KB/s (4.2*10^6 bps)

Apaçi

ab -n 100 -c 30 xxx
Server Software:        Apache/2.2.16
Document Path:          /
Document Length:        24902 bytes

Concurrency Level:      30
Time taken for tests:   28.364 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      25346000 bytes
HTML transferred:       24902000 bytes
Requests per second:    35.26 [#/sec] (mean)
Time per request:       850.918 [ms] (mean)
Time per request:       28.364 [ms] (mean, across all concurrent requests)
Transfer rate:          872.66 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10
Maximum connect burst length: 1

Total: connections 100 requests 1000 replies 1000 test-duration 52.261 s

Connection rate: 1.9 conn/s (522.6 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 499.0 avg 522.6 max 591.0 median 518.5 stddev 19.4
Connection time [ms]: connect 0.6
Connection length [replies/conn]: 10.000

Request rate: 19.1 req/s (52.3 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 18.2 avg 19.2 max 19.6 stddev 0.5 (10 samples)
Reply time [ms]: response 46.9 transfer 5.3
Reply size [B]: header 453.0 content 24902.0 footer 2.0 (total 25357.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 6.80 system 18.88 (user 13.0% system 36.1% total 49.1%)
Net I/O: 475.2 KB/s (3.9*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Önbellek ve artırma ile drupal

nginx

ab -n 10000 -c 30 xxx
Server Software:        nginx
Document Path:          /
Document Length:        25002 bytes

Concurrency Level:      30
Time taken for tests:   2.275 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      253780000 bytes
HTML transferred:       250020000 bytes
Requests per second:    4395.52 [#/sec] (mean)
Time per request:       6.825 [ms] (mean)
Time per request:       0.228 [ms] (mean, across all concurrent requests)
Transfer rate:          108934.95 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=1000 --num-calls=30
Maximum connect burst length: 1

Total: connections 1000 requests 30000 replies 30000 test-duration 5.971 s

Connection rate: 167.5 conn/s (6.0 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 4.2 avg 6.0 max 13.0 median 4.5 stddev 2.6
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 30.000

Request rate: 5024.0 req/s (0.2 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 5017.2 avg 5017.2 max 5017.2 stddev 0.0 (1 samples)
Reply time [ms]: response 0.2 transfer 0.0
Reply size [B]: header 405.0 content 25002.0 footer 0.0 (total 25407.0)
Reply status: 1xx=0 2xx=30000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.79 system 2.56 (user 13.2% system 42.9% total 56.1%)
Net I/O: 125016.7 KB/s (1024.1*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Apaçi

ab -n 1000 -c 30 xxxx
Server Software:        Apache/2.2.16
Document Path:          /
Document Length:        25002 bytes

Concurrency Level:      30
Time taken for tests:   0.753 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      25291000 bytes
HTML transferred:       25002000 bytes
Requests per second:    1327.92 [#/sec] (mean)
Time per request:       22.592 [ms] (mean)
Time per request:       0.753 [ms] (mean, across all concurrent requests)
Transfer rate:          32797.26 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=100 --num-calls=10
Maximum connect burst length: 1

Total: connections 100 requests 1000 replies 1000 test-duration 1.148 s

Connection rate: 87.1 conn/s (11.5 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 6.2 avg 11.5 max 14.1 median 11.5 stddev 1.3
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 10.000

Request rate: 870.8 req/s (1.1 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 1.1 transfer 0.1
Reply size [B]: header 260.0 content 25002.0 footer 0.0 (total 25262.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.13 system 0.57 (user 11.1% system 49.5% total 60.6%)
Net I/O: 21544.9 KB/s (176.5*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Kimliği doğrulanmış kullanıcı için kıyaslama (sayfa yükleme)

nginx

Page load times : 2.85 s

Apaçi

Page load times : 5.4 s

Ancak Nginx’in gücü önbellek sistemi

Önbellek ve Nginx olmadan Drupal önbellek sistemi etkin

Server Software:        nginx
Document Path:          /
Document Length:        24902 bytes

Concurrency Level:      30
Time taken for tests:   2.437 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      252670000 bytes
HTML transferred:       249020000 bytes
Requests per second:    4103.34 [#/sec] (mean)
Time per request:       7.311 [ms] (mean)
Time per request:       0.244 [ms] (mean, across all concurrent requests)
Transfer rate:          101248.99 [Kbytes/sec] received


httperf --client=0/1 --server=xxx --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=1000 --num-calls=30
Maximum connect burst length: 1

Total: connections 1000 requests 30000 replies 30000 test-duration 6.044 s

Connection rate: 165.5 conn/s (6.0 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 4.2 avg 6.0 max 11.7 median 4.5 stddev 2.6
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 30.000

Request rate: 4963.7 req/s (0.2 ms/req)
Request size [B]: 74.0

Reply rate [replies/s]: min 4970.1 avg 4970.1 max 4970.1 stddev 0.0 (1 samples)
Reply time [ms]: response 0.2 transfer 0.0
Reply size [B]: header 405.0 content 25002.0 footer 0.0 (total 25407.0)
Reply status: 1xx=0 2xx=30000 3xx=0 4xx=0 5xx=0

CPU time [s]: user 0.72 system 2.68 (user 12.0% system 44.3% total 56.3%)
Net I/O: 123516.8 KB/s (1011.8*10^6 bps)

Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0

Perusio'nun Drupal for Nginx yapılandırmasını kullanmalısınız.


Apache nasıl çalışıyordu, preform, FCGI, vb. Bu testleri yaptığınızda Apache yapılandırmanız mümkün olduğunca optimize edildi mi? Tam olarak aynı PHP ortamı çalışıyor mu?
mpdonadio

PHP (5.3) ortamı tamamen aynıydı. Apache mpm_prefork kullanıyordu ve apache config (maxclient, MaxSpareServers, MaxRequestsPerChild, vb.) PHP5-FPM ile tamamen aynıydı
flocondetoile

4
Bunlar iyi rakamlar, ama gerçek bir karşılaştırma olup olmadıklarından emin değilim. Apache + FastCGI - Apache + FCGI + PHPFPM - Nginx + PHPFPM arasındaki fark, Apache ile Nginx arasındaki farkları daha iyi gösterir.
mpdonadio

MPD'nin işaret ettiği gibi, bu gerçek bir karşılaştırma değil. Gerçek bir resim elde etmek için her ikisinde de php-fpm kullanmanız gerekir.

1
Nginx, RAM sınırlı VPS hesapları için iyi bir seçim olduğunu düşünüyorum. Apache'den daha küçük bir RAM ayak izi ile rahatça çalışabildiği için - özellikle gereksiz modülleri kaldırmaya devam ederseniz - opcode önbelleklerini çalıştırmak için kalan daha fazla RAM'iniz var (APC veya PHP 5.5'in yerleşik OpCache'si), MySQL / Postgres sunucusunu verin büyük bir tamponu kullanmak ve Letharion'un haklı olarak işaret ettiği diğer optimizasyonlar da önemlidir.
Garrett Albright

0

İşte on sunucu / değişken için bir performans testi (örn. Apache, Nginx, lighttpd, Lightspeed, Hiawatha, Cherokee). Testlerden üçü Drupal ile ilgilidir.

Bence Hiawatha en iyi genel seçim olabilir. Olması gerekiyordu tam Drupal uyumluluk , Nginx benzer bir güvenlik vurgu (DoS, XSS, CSRF, SQL enjeksiyon önleme) ve hızları ve ayak izi vardır.

Üç Drupal testinin ikisinde, hem Hiawatha hem de Nginx Apache'yi yaklaşık% 150, ancak Drupal statik testinde Apache, Nginx'i marjinal olarak geride bırakırken, Hiawatha paketi yaklaşık% 10 oranında en iyi şekilde kullanır.

Şapkamı bu testlerin hiçbirine asmıyorum, ancak farklı kullanım durumlarında performansa bir basketbol sahası görüntüsü veriyor. Bence performans tek başına düşünülmemeli. İstikrar ve güvenlik daha önemli faktörler olabilir.


0

Burada , aynı donanım üzerinde ancak farklı web sunucularında drupal çalışması için yük testi sonuçları verilmiştir. (nginx ve apache)

İşte bu testin sonucu:

Aynı donanım kaynaklarına sahip büyük bir trafik altında, nginx apache'den daha iyi performans gösterir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.