Nginx vs Apache - Apakah ada perbandingan dan statistik penggunaan aktual di luar sana?


45

Saya memiliki server baru untuk bermain, dan saya menatap kanvas kosong. Saya dapat meletakkan apa pun yang saya inginkan di atasnya. Sementara saya merasa nyaman dengan Apache, saya terus mendengar bagaimana nginx dapat menangani lebih banyak lalu lintas daripada Apache, dengan faktor 10, 100, bahkan lebih. Bukan hanya itu "jauh lebih cepat."

Ketika saya mencari artikel saya dapat menemukan banyak hal yang tidak terkait dengan Drupal. Atau, ketika saya menemukan artikel terkait Drupal, baik 1) file konfigurasi seseorang dengan upaya cepat untuk menjelaskan cara mengaturnya, atau 2) seseorang mengatakan "tidak, jangan gunakan nginx, gunakan Apache dengan PHP fcgid "tetapi tidak pernah ada penjelasan mengapa.

Jadi, ketika datang ke Drupal, apa realitasnya di sini?

Sebagai contoh, saya mencari sesuatu di sepanjang baris artikel 2bits.com ini. Di sini penulis telah melihat Apache mod_php vs Apache dengan fcgid, menimbang pro dan kontra dari masing-masing, dan memberikan studi kasus untuk menggambarkan dampak di dunia nyata. Ada cukup informasi dalam artikel ini bagi saya untuk membuat keputusan berpendidikan tentang pendekatan mana yang terbaik untuk situasi saya.

Sementara penulis membandingkan mod_php dengan fcgid, saya mencari jenis yang sama komprehensif, tampilan dunia nyata di Apache vs Nginx.

Adakah yang beralih ke Nginx dan "terpesona" oleh perbedaan yang dibuatnya dibandingkan dengan Apache? Bahkan untuk lingkungan yang sangat optimal yang sudah menggunakan APC, Memcache, dan caching agresif seperti Varnish, ketika satu-satunya variabel yang berubah adalah mengganti Apache dengan Nginx, tidak membuat cukup banyak perbedaan dalam dan dari dirinya sendiri untuk pantas berinvestasi dalam teknologi alternatif yang lebih baru ini. ?

Situs yang akan masuk ke server ini mendapatkan rata-rata 2 juta PV sebulan. LAMP stack menjalankan Cent OS 6. 4 core CPU dengan 8 GIG ram. Memcached dan APC akan menjadi bagian dari campuran. Tidak ada yang istimewa tentang pemasangan Drupal - pada dasarnya vanilla 7 dengan sekitar 50 modul.


2
Jika Anda ingin menyetel situs tertentu untuk kinerja, Anda lebih baik menjalankan tes Anda sendiri daripada mengandalkan pekerjaan orang lain. Campuran pengguna anonim versus pengguna yang masuk, misalnya, adalah faktor utama. Jika Anda melihat statistik kinerja untuk situs yang sebagian besar mendapatkan lalu lintas anonim, dan Anda tidak seperti itu, Anda mungkin juga tidak repot. Tetapi jika situs Anda memang memiliki sebagian besar lalu lintas anonim, maka dalam pengalaman saya menempatkan Varnish di depan server web Anda membuat perbedaan yang jauh lebih besar daripada server apa yang Anda jalankan di belakangnya.
Alfred Armstrong

Jawaban:


60

Sebenarnya, ini tidak menjawab pertanyaan yang Anda tanyakan. Saya berharap itu membantu juga.

Apache / Nginx / Lighttpd / server web lainnya. Apakah penting yang mana yang saya pilih? Singkatnya, ada .

Jawaban yang jauh lebih lama:

Jika , dan hanya jika, Anda memiliki persentase yang sangat besar dari pengguna yang masuk, jika Anda peduli tentang kinerja server web Anda. Jika pengguna Anda anonim, perbedaan apa pun yang secara teoritis dapat Anda peroleh dari pengoptimalan pada lapisan itu sangat berarti dibandingkan dengan membuat sumber daya Anda lebih baik untuk di-cache. Jika file css Anda memiliki header cache yang tepat, UA bahkan tidak akan meminta mereka untuk kedua kalinya. Itu penting. Jika Anda dapat men-cache halaman Anda di Varnish atau solusi perangkat lunak serupa, maka melayani halaman itu adalah masalah membuat hash-lookup, dan kemudian mengembalikan sejumlah besar data langsung dari RAM. Itu penting. Dalam kedua skenario ini, daemon HTTP bahkan tidak pernah terlibat, PHP tidak dipanggil. Drupal tidak bisa bootstrap. Tidak ada set modul besar yang harus dimuat ke dalam RAM, tidak ada query database memakan waktu dieksekusi.

Ketika Anda melakukan pemuatan halaman penuh, dari cache dingin, untuk pengguna yang login, pada halaman yang kompleks; banyak hal terjadi. Ya, server web terlibat dalam menangani permintaan yang masuk, mengatur beberapa tajuk dan meneruskan tanggapan. Tetapi waktu yang diperlukan, bahkan tidak relevan dalam konteks Drupal menjalankan bootstrap penuh dan mengeluarkan responsnya. Mungkin ada ratusan permintaan basis data yang dieksekusi. Logika yang sangat kompleks dalam PHP dievaluasi oleh parser. Banyak modul sedang dimuat ke dalam RAM. Meningkatkan kinerja hal-hal itu, jauh lebih mungkin untuk memberikan kontribusi serius terhadap kinerja.

Demi argumen: Katakanlah Anda telah menghabiskan banyak waktu untuk mengoptimalkan kinerja yang lainnya.

  1. Anda menjalankan APC (Atau Pengoptimal + ) dan versi terbaru dan tercepat dari PHP.
  2. Pertanyaan-DB hanya sedikit.
  3. Logika PHP telah berkurang.
  4. Anda menyimpan apa yang Anda bisa dalam Varnish.
  5. Anda telah menyusun ulang seluruh situs Anda sehingga Anda dapat men-cache banyak sisi klien, dan melakukan banyak pengangkatan dalam ECMAScript .

Jika Anda memiliki banyak pengguna yang masuk, dan Anda telah berurusan dengan semua hal di atas, maka Anda mungkin dapat membuat perbedaan tetapi penyempurnaan kinerja, atau mengganti server web Anda. Namun, coba tebak. Situs Anda sangat kompleks, dan pola penggunaan pengguna khusus Anda adalah unik . Tidak ada jawaban umum. Anda perlu mengatur semua server web yang berbeda di belakang load balancer, dan melihat bagaimana mereka berperilaku, dalam skenario Anda .

Di atas adalah upaya untuk secara logis mencapai kesimpulan bahwa kinerja waktu menghabiskan mengoptimalkan server web kemungkinan penggunaan waktu yang buruk. Saya ingin seseorang membuat lubang di atas, saya mungkin akan belajar sesuatu yang baru darinya. :)

Beberapa catatan lain:

  1. Selama keynote DrupalCon Copenhagen , pencipta PHP Rasmus Lerdorf , menggunakan Nginx sendiri, berbicara tentang topik kinerja Drupal, mengatakan "Orang selalu bertanya kepada saya tentang server web ... itu benar-benar tidak masalah, server web cukup banyak tidak relevan" . (Kira-kira pukul 26:30 dalam video)
  2. Facebook telah menghabiskan waktu berjam-jam untuk menulis Hiphop , sebuah basis kode yang jauh lebih besar daripada Drupal sendiri, untuk mempercepat kode PHP dengan "sangat" 100%. Saya memeriksa Hiphop dengan $ wc -l $(find . -type f | grep -v "^\.git" | grep -v "^\.hphp/third_party") | sort -nr | head -n1dan menemukan itu terdiri dari 1.512.481 baris kode. Itu adalah jumlah pekerjaan yang benar-benar gila untuk meningkatkan kecepatan PHP. Saya menduga itu karena kecepatan PHP sangat berarti bagi mereka.
  3. Apakah saya menyebutkan bahwa caching yang baik akan memiliki efek yang jauh lebih besar daripada mengatur server web?
  4. Dengan rilis Apache 2.4, Jim Jagielski pada dasarnya mengklaim bahwa Apache 2.4 lebih cepat dari server berbasis acara .
  5. Saya menikmati Kinerja Drupal dan Skalabilitas dengan The Dream Team , tempat pertanyaan ini muncul. Semua jawaban yang harus dipilih, tidak terkait dengan kinerja. Hal-hal seperti "Yang mana yang sudah Anda ketahui cara mengonfigurasi", dan "Yang mana yang memungkinkan Anda membangun tumpukan teknologi paling sederhana", adalah beberapa alasan yang disebutkan untuk memilih yang lain. Performa tidak masuk gambar.

4
Jangan lupa tentang CDN untuk mencegah sebagian besar permintaan CSS, JS, dan gambar dari memukul server web.
mpdonadio

Poin luar biasa! Saya pikir saya harus menulis ulang drupal.stackexchange.com/questions/24180/… di beberapa titik. Diskusi tentang Apache / Nginx sepertinya bukan tempat yang optimal untuk membangun daftar lengkap optimasi kinerja.
Letharion

1
Ini jawaban yang bagus. Hanya satu nitpick: Anda tidak boleh menggunakan "ECMAScript" dan "JavaScript" secara bergantian. Ada jauh lebih banyak hal untuk JavaScript daripada ECMAScript.

Anda mengatakan bahwa cache jauh lebih penting daripada kecepatan server web. Tebak apa? Jika server web menggunakan lebih sedikit memori daripada yang lain, Anda dapat menggunakan lebih banyak RAM untuk caching. Jadi kita bisa mengatakan bahwa itu adalah penting untuk tune server web Anda dengan benar sehingga tidak makan semua RAM Anda, kan?
pqnet

Menyetel server Anda untuk menggunakan lebih sedikit RAM sama sekali tidak apa-apa, tetapi jika Anda mencoba masuk ke wilayah berkinerja tinggi, Anda mungkin akan menjalankan pernis pada server khusus, sehingga server dan cache http Anda tidak akan bersaing untuk memori yang sama.
Letharion

32

OK, meskipun pertanyaan ini sudah dijawab, saya necromancing sekali lagi, terutama karena saya tidak suka implikasi dari jawaban ini yang tidak membuat perbedaan, dan karena sebagai pengembang web, saya benci caching dengan penuh semangat .

Perbedaan antara Apache dan nginx bukanlah "seberapa cepat mereka dapat melayani permintaan", tetapi berapa banyak permintaan yang dapat mereka layani pada jumlah perangkat keras yang sama (terutama dengan sumber daya terbatas), yang merupakan hal yang agak berbeda.

Apache adalah server berbasis proses. Artinya itu memroses proses untuk setiap permintaan. Nginx adalah server berbasis peristiwa, artinya menggunakan loop acara (asinkron) alih-alih proses atau utas.

Dan sementara server berbasis proses (seperti Apache) dapat melakukan kurang lebih setara dengan server berbasis peristiwa asinkron (seperti nginx) di bawah beban ringan, di bawah beban yang lebih berat seperti misalnya 10'0000 permintaan simultan, nginx hanya menggunakan beberapa RAM megabita, sedangkan Apache memerlukan beberapa ratus megabita untuk server web saja (tidak termasuk aplikasi web, yang membutuhkan lebih banyak sumber daya sendiri), jika bisa melakukannya sama sekali.

Jadi di bawah beban yang lebih berat, Anda akan melihat Apache mengonsumsi terlalu banyak RAM, yang secara mengejutkan menurunkan kinerja secara signifikan.

Lebih penting lagi, konsumsi RAM yang lebih tinggi berarti bahwa Apache dapat melayani lebih sedikit permintaan pada perangkat keras yang sama daripada nginx, yang berarti Apache membutuhkan lebih banyak perangkat keras untuk jumlah pengguna yang sama, yang berarti Anda memiliki TCO yang lebih tinggi (total biaya kepemilikan) dengan Apache daripada dengan nginx, yang mengurangi ROI Anda (laba atas investasi).

Total memori yang digunakan oleh koneksi bersamaan X (lebih sedikit lebih baik)

Penggunaan Memori

Permintaan yang dapat dilayani per detik pada koneksi bersamaan X pada 1 set perangkat keras (lebih banyak lebih baik)

Permintaan per detik

Sumber: ApacheBench, oleh dreamhost.com

Lihat juga tulisan laut digital ini .
Rupanya, itu tergantung pada Arsitektur Penanganan Koneksi yang Anda pilih untuk Apache.


6
Anda memukul kepala dengan "... bukan seberapa cepat mereka dapat melayani permintaan, tetapi berapa banyak permintaan mereka dapat melayani pada jumlah yang sama dari perangkat keras ..." Memang pada akhirnya saya ingin mendapatkan keuntungan terbesar untuk uang saya . Diberi mesin perangkat keras yang sama persis dan variabel lainnya, jika saya bisa melayani 1.000.000 pengguna sehari dengan nginx di mana apache hanya bisa melayani 200.000, maka tentu pilihan terbaik dari perspektif biaya adalah nginx. Dengan konfigurasi perangkat keras tertentu, pernahkah Anda melihat perbedaan besar antara apa yang bisa dilakukan nginx dibandingkan dengan apache?
blue928

2
Apache 2.4, rilis saat ini, memiliki model berbasis acara: httpd.apache.org/docs/current/mod/event.html
Greg

1
Juga, bagi mereka yang mengatakan bahwa itu tidak masalah karena "itu akan baik-baik saja selama Anda melakukan caching": Anda tahu apa yang perlu Anda lakukan caching? Anda membutuhkan RAM GRATIS.
pqnet

Saya sering melihat klaim umum "Nginx ini lebih hebat", namun, saya jarang (pernah?) Melihat siapa pun mendukung ini dengan bukti kuat. Itu selalu "instance nginx saya yang sangat terkonfigurasi mengalahkan server apache stock jadi sekarang saya telah membuktikan bahwa saya keren karena saya menggunakan nginx seperti anak-anak keren lainnya". Nginx mungkin jauh lebih baik daripada Apache untuk semua yang saya tahu, tetapi saya belum melihat ada orang yang benar-benar menunjukkan bahwa itulah masalahnya.
Letharion

@Letharion: Selesai (oleh dreamhost.com), dan ditambahkan sesuai permintaan Anda. Seperti yang dapat Anda lihat dalam hasil benchmark ini, nginx jelas lebih hemat memori. Mungkin juga: instance -nginx-instance saya mengalahkan stock-Apache-instance saya pada benchmark yang sama di komputer yang sama.
Quandary

16

Saya beralih dari Apache ke Nginx / PHP-FPM beberapa bulan yang lalu.

Saya membuat beberapa benchmarck dengan situs web drupal, dan menguji beberapa use case. Di server VPS dengan 1 CPU dan RAM 512 Mo

Drupal dengan hanya cache

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)

Apache

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

Drupal dengan cache dan boost

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

Apache

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

tolok ukur untuk pengguna terotentikasi (memuat halaman)

Nginx

Page load times : 2.85 s

Apache

Page load times : 5.4 s

Tetapi kekuatan Nginx adalah sistem cache

Drupal tanpa Boost dan Nginx dengan sistem cache diaktifkan

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

Anda harus menggunakan konfigurasi Nginx perusio untuk Drupal


Bagaimana cara Apache menjalankan, membentuk sebelumnya, FCGI, dll? Apakah konfigurasi Apache Anda dioptimalkan mungkin saat Anda menjalankan tes ini? Apakah lingkungan PHP yang sama persis berjalan?
mpdonadio

Lingkungan PHP (5.3) persis sama. Apache menjalankan mpm_prefork, dan konfigurasi apache (maxclient, MaxSpareServers, MaxRequestsPerChild, dll.) Persis sama dengan PHP5-FPM
flocondetoile

4
Ini angka yang bagus, tetapi saya tidak yakin apakah itu perbandingan yang benar. Apache + FastCGI vs Apache + FCGI + PHPFPM vs Nginx + PHPFPM akan menunjukkan perbedaan antara Apache dan Nginx lebih baik.
mpdonadio

Seperti yang ditunjukkan oleh GKG, ini bukan perbandingan yang benar. Anda harus menjalankan php-fpm di keduanya untuk mendapatkan gambar yang benar.

1
Nginx adalah pilihan yang baik untuk akun VPS RAM terbatas, saya pikir. Karena dapat beroperasi dengan nyaman dengan jejak RAM yang lebih kecil dari Apache - terutama jika Anda menghapus modul yang tidak perlu - Anda memiliki lebih banyak RAM yang tersisa untuk menjalankan cache opcode (APC atau PHP 5.5 built-in OpCache), berikan server MySQL / Postgres daemon buffer besar, dan optimisasi lainnya yang ditunjukkan oleh Letharion juga penting.
Garrett Albright

0

Berikut adalah tes kinerja untuk sepuluh webservers / varients (mis. Apache, Nginx, lighttpd, Lightspeed, Hiawatha, Cherokee). Tiga tes berhubungan dengan Drupal.

Saya pikir Hiawatha mungkin menjadi pilihan terbaik secara keseluruhan. Seharusnya memiliki kompatibilitas Drupal penuh , memiliki penekanan pada keamanan (DoS, XSS, CSRF, pencegahan injeksi SQL), dan kecepatan & jejak yang mirip dengan Nginx.

Dalam dua dari tiga tes Drupal, baik Hiawatha dan Nginx mengungguli Apache sekitar 150%, tetapi dalam tes statis Drupal, Apache sedikit mengungguli Nginx, sementara Hiawatha mengalahkan paket dengan sekitar 10%.

Saya tidak akan menggantungkan topi saya pada salah satu dari tes ini, tetapi itu memberikan satu pandangan kasar tentang kinerja dalam situasi penggunaan yang berbeda. Saya pikir kinerja saja seharusnya bukan satu-satunya pertimbangan. Stabilitas dan keamanan mungkin menjadi faktor yang lebih penting.


0

di sini adalah hasil pengujian beban untuk drupal berjalan pada perangkat keras yang sama tetapi dengan server web yang berbeda. (nginx dan apache)

inilah kesimpulan dari tes ini:

di bawah lalu lintas besar dengan sumber daya perangkat keras yang sama, nginx berkinerja lebih baik daripada apache.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.