Varnish -> Nginx -> Apache ide yang bagus?

10

Saya sedang berpikir tentang arsitektur untuk server Web baru. Apakah memiliki Varnish sebagai cache di depan Nginx sebagai proxy terbalik dan menyajikan file statis di depan apache untuk semua pekerjaan berat adalah ide yang bagus?

Saya akan menjalankan aplikasi php dan ruby pada rails.

Apakah akan ada terlalu banyak permintaan lewat permintaan php untuk di-apache melalui dua proses lainnya?

Terima kasih banyak!

— Zoran Zaric
sumber

8

Ya itu sah. Pendekatan pribadi saya adalah menggunakan Varnish di depan dan menggunakan VCL untuk membagi lalu lintas antara permintaan NGINX statis dan angkat berat Anda (apakah itu Apache atau Penumpang atau ... tidak masalah). Ini terutama benar jika berada di mesin yang sama karena Anda tidak perlu overhead tambahan. Itu tidak selalu membelikanmu apa pun.

— McJeff
sumber

ya ini adalah ide yang cukup bagus, karena pernis harus cukup cepat untuk ini

— Zoran Zaric

6

Varnish tidak (belum) mendukung kompresi gzip, jadi mungkin ide untuk menukar itu dengan nginx di depan untuk mengompresi apa yang dikirim pernis kembali. Karena varnish dan nginx tidak berjuang untuk sumber daya yang sama (nginx menggunakan CPU untuk kompresi gzip, sementara pernis menggunakan memori) mereka harus berjalan dengan lancar di mesin yang sama.

Varnish sekarang mendukung kompresi gzip , jadi kecuali Anda memerlukan penghentian SSL (seperti yang disarankan dalam komentar), saya akan menyarankan menempatkan pernis langsung di kontak dengan Internet.

Untuk http:

(internet) -> (pernis, gzip, caching, esi) -> (aplikasi)

Untuk https:

(internet) -> (nginx, ssl) -> (pernis, gzip, caching, esi) -> (aplikasi)

Jika Anda ingin apache di sana juga (untuk dukungan mod_foobar di mana-mana), saya akan meletakkannya di antara pernis dan aplikasi

Pembaruan: Diperbarui untuk menyertakan dukungan gzip di pernis 3.0. Menambahkan ssl / esi seperti yang disarankan dalam komentar

— mogsie
sumber

Jika apa pun yang menyajikan konten ke pernis menyandikannya di gzip, maka pernis akan meneruskannya di gzipped tanpa mengeluh: varnish-cache.org/wiki/FAQ/Compression Satu-satunya hal yang tidak dilakukan pernis adalah mengambil konten yang tidak terkompresi dari yang tidak di-cache. aplikasi dan cadangan itu dikompresi. Apakah ini pengertian Anda juga?

— ewalk

Satu-satunya saat Anda menjalankan nginx di depan varnish adalah ketika Anda menggunakan ESI. Karena Anda tidak dapat melakukan perakitan ESI dari halaman yang dikompresi, dan Varnish tidak akan mengkompres halaman yang sudah dirakit, Nginx ditempatkan di depan Varnish untuk memberikan kompresi itu. Jika asal menyajikan konten yang dikompresi, Varnish akan meneruskan data itu ke klien dalam bentuk terkompresi.

— user6738237482

Ya, ESI adalah salah satu alasan mengapa saya akan merekomendasikan konfigurasi ini, tapi saya kira jika backend Anda dikompres dan Anda tidak menggunakan ESI, Anda bisa membuang nginx, karena saya percaya pernis dapat menangani cukup banyak lalu lintas tanpa berkeringat.

— mogsie

@ user6738237482, nginx suport terminasi SSL, Varnish tidak. Bahkan, berada di depan sesuatu seperti pernis atau Apache adalah apa yang awalnya dirancang untuk nginx, sebagai server proxy yang cepat dan ringan.

— rmalayter

4

Jumlah overhead seharusnya tidak signifikan. Saya berasumsi bagian dari alasan Anda ingin memiliki dua tingkatan ini adalah untuk skalabilitas; dalam hal ini kemungkinan besar Anda akan melihat, relatif terhadap apache, bahwa pernis dan nginx tidak bekerja sangat keras.

Jika Anda ketiga tier pada satu mesin, seharusnya ada sedikit dampak kinerja sebelum Anda mencapai kapasitas server itu sendiri.

Sebagai alternatif, mengapa tidak pernis + nginx dengan penumpang? Saya pernah menggunakan pengaturan ini di masa lalu dan nginx menggunakan penumpang relatif ringan, dan berjalan cukup baik. Mungkin patut dipikirkan jika Anda belum menikah dengan apache yang menjalankan stack rails Anda.

— Tony
sumber

ya saya mungkin beralih dari apache ke nginx untuk rails, tetapi memberi pelanggan kemampuan untuk menggunakan file .htaccess adalah + untuk apache, setidaknya untuk php.

— Zoran Zaric

2

Saya adalah admin sistem untuk platform e-niaga pemula. Kami menggunakan varnish + nginx di depan tumpukan PHP / apache kami dan ini berhasil dengan sangat baik.

Kami memiliki aplikasi penggunaan memori tinggi dan aplikasi itu menggunakan sekitar 15-20gigs RAM per webnode dan setelah kami menempatkan pernis di depan sekarang sekitar 8gig RAM per node. Mereka tidak pernah berduri.

Jadi saya sangat merekomendasikannya.

— Mike
sumber

3

Anda tahu pernis tidak berbicara ssl kan?

— Mike

1

Saya menjalankan Drupal, dengan modul boost di server Apache + PHP + MySQL, tetapi di depannya saya menggunakan Nginx dengan fitur gzip-static aktif, dan menggunakan hasil boost untuk melayani pengguna.

Dan di atas semua itu saya menggunakan pernis, semua pada PC yang sama, saya memiliki hasil yang baik.

Saya juga menggunakan Nginx untuk mengubah header yang Drupal tidak lakukan dengan sangat baik untuk cache.

— Go2linux
sumber

0

Itu bukan ide yang baik kecuali jika Anda membutuhkan sesuatu seperti ESI. Nginx memiliki sistem caching sendiri yang berkinerja lebih baik .

— VBart
sumber

Saya tahu ini adalah jawaban lama, tetapi sayangnya tautan itu tidak lagi tersedia, jadi saya tidak dapat memverifikasi klaim Anda. Dalam pengalaman saya, Varnish sulit dikalahkan dalam kecepatan dan fleksibilitasnya sebagai proxy terbalik.

— Martijn Heemels

@MartijnHeemels web.archive.org/web/20130501222206/http://todsul.com/… dan ada patokan lain: nbonvin.wordpress.com/2011/03/24/…

— VBart

-1

Apache dapat digunakan untuk mengakhiri SSL (mendekripsi), periksa http://noosfero.org/Development/Varnish#SSL

— brauliobo
sumber

1

Harap hindari memposting tautan sebagai jawaban, karena jawaban Anda kemungkinan akan kehilangan semua makna ketika dipengaruhi oleh tautan . Silakan pertimbangkan untuk mengedit jawaban Anda dan termasuk bagian-bagian yang relevan dari tautan yang Anda berikan dalam jawaban Anda. Dengan segala cara biarkan tautan tetap di tempatnya sebagai referensi.

— Bryan