IIS 7.x Application Pool Praktik Terbaik


24

Kami akan menyebarkan banyak situs ke beberapa server baru. Saya memiliki pertanyaan berikut tentang kumpulan aplikasi:

  1. Tampaknya disarankan untuk memiliki satu kumpulan aplikasi per situs web. Apakah ada peringatan untuk pendekatan ini? Akankah satu aplikasi mengumpulkan semua CPU, Memori, Dll ...?

  2. Kapan Anda harus mengizinkan beberapa proses pekerja dalam kumpulan aplikasi? Kapan sebaiknya tidak?

  3. Dapatkah batas memori pribadi digunakan untuk mencegah satu kumpulan aplikasi mengganggu yang lain? Apakah pengaturannya terlalu rendah menyebabkan permintaan yang valid untuk mendaur ulang kumpulan aplikasi tanpa mendapatkan respons yang valid?

  4. Apa perbedaan antara batas memori pribadi dan virtual?

  5. Apakah ada alasan kuat untuk TIDAK menjalankan satu kumpulan aplikasi per situs?


Pertanyaan pertama yang kembali kepada Anda: Apakah situs web ini (yaitu: .htm / .js), atau aplikasi web (mis. .Aspx / .php)?
Coding Gorilla

Sebagian besar aplikasi .Net 3.5. Salah satunya adalah aplikasi PHP pihak ketiga.
Eric Burcham

1
Ini adalah jenis topik yang luas - Subjek (dan jawaban @ CodingGorilla) menarik, tetapi mungkin bukan yang paling cocok untuk gaya Q-and-A
SF

Jawaban:


20

1) Tampaknya disarankan untuk memiliki kumpulan aplikasi per situs web. Apakah ada peringatan untuk pendekatan ini? Bisakah satu kumpulan aplikasi, misalnya, menyimpan semua CPU, Memori, Dll ...?

Ini adalah pendekatan yang cukup bagus; tidak ada alasan bagus yang bisa saya pikirkan untuk memiliki "situs" yang berbeda (aplikasi) berbagi kumpulan yang sama. Kecuali mereka perlu berbagi satu sumber daya atau sejenisnya. Satu aplikasi secara teoritis dapat memakan banyak CPU atau memori, tetapi mengubah cara aplikasi dikumpulkan tidak akan terlalu mempengaruhi ini.

2) Kapan Anda harus mengizinkan beberapa proses pekerja dalam kumpulan aplikasi. Kapan sebaiknya tidak?

Ini sebaiknya dibiarkan sendiri, menggunakan pengaturan default. Kecuali Anda benar-benar tahu apa yang Anda lakukan ini sebenarnya dapat berdampak negatif pada situs web / aplikasi Anda.

3) Dapatkah batas memori pribadi digunakan untuk mencegah satu kumpulan aplikasi mengganggu yang lain? Apakah pengaturannya terlalu rendah menyebabkan permintaan yang valid untuk mendaur ulang kumpulan aplikasi tanpa mendapatkan respons yang valid?

a) Secara teoritis

b) Ya pengaturannya untuk menurunkan dapat memiliki efek negatif. Sekali lagi, kecuali Anda memiliki kebutuhan khusus, dan tahu apa yang Anda lakukan, biarkan saja ini.

4) Apa perbedaan antara batas memori pribadi dan virtual?

Itu sangat rumit, inilah posting cepat yang saya temukan yang mungkin membantu: http://cybernetnews.com/cybernotes-windows-memory-usage-explained/

5) Apakah ada alasan kuat untuk TIDAK menjalankan satu kumpulan aplikasi per situs?

Sekali lagi, satu-satunya alasan yang bisa saya pikirkan adalah jika ada semacam "sumber daya bersama" yang dibutuhkan beberapa aplikasi, maka Anda ingin menjalankannya dalam proses yang sama.

Untuk aplikasi tujuan umum dan situs web, IIS sudah diatur dengan baik dengan nilai-nilai standarnya.

****MEMPERBARUI****

Sehubungan dengan permintaan Anda untuk informasi tambahan tentang # 2, Anda tidak boleh melakukan ini kecuali Anda memiliki kebutuhan khusus untuk melakukannya. Bahkan dengan tindakan server yang membutuhkan waktu lama, permintaan dilayani menggunakan banyak utas, dan Anda ingin menggunakan "Permintaan Async" untuk menangani tugas yang berjalan lama (yang membebaskan utas kumpulan utas untuk menangani permintaan lainnya). Secara realistis, saya tidak bisa memikirkan alasan bagus untuk memungkinkan banyak proses untuk satu kumpulan.

Setelah Anda mulai berbicara beberapa proses, maka Anda berpotensi mengalami hal-hal seperti: kehilangan status sesi karena sesi masih hidup dalam proses 1, tetapi permintaan sedang ditangani oleh proses 2. Atau bahkan lebih buruk, Anda harus mencari cara untuk melakukan beberapa komunikasi antar proses, yang merupakan rasa sakit yang nyata.

Tidak peduli apa yang Anda lakukan sehubungan dengan alasan untuk beberapa proses, saya akan berani bertaruh ada cara yang lebih baik untuk menghadapinya (daripada memulai proses lain).


Saya menghargai jawaban yang bijaksana, dan telah menerimanya. Jika Anda memiliki informasi lebih spesifik ke # 2, saya menghargainya. "Sebaiknya dibiarkan sendiri" tentu saja merupakan nasihat bijak, tetapi kapan menggunakan berbagai proses pekerja akan baik untuk diketahui juga. Saya menganggap ini lebih relevan ketika Anda memiliki beberapa tindakan server yang membutuhkan waktu lama untuk mengembalikan respons, seperti laporan besar, layanan web yang menerima posting besar, dan sejenisnya. Saya juga menganggap semua hal konkurensi thread normal berlaku?
Eric Burcham

Hanya untuk menambahkan: jika Anda mengharapkan aplikasi Anda bermain bersama secara buruk, dialog instalasi untuk IIS mencatat bahwa Windows System Resource Manager dapat diinstal dan digunakan untuk membatasi penggunaan CPU dan memori oleh kumpulan aplikasi.
TristanK

@ KristanK, terima kasih atas tipnya. Itu sangat membantu.
Eric Burcham

@Coding Gorilla - Terima kasih lagi untuk wawasannya. Saya memutuskan untuk melakukan penggalian yang serius ke "mengapa menggunakan kebun web" dan muncul beberapa tanggapan. Semua peringatan yang Anda sebutkan berlaku, khususnya berurusan dengan akses tidak sinkron ke sumber daya bersama seperti berbagai cache dan sesi pengguna. Fitur taman web pada dasarnya hanya memungkinkan Anda memuat permintaan keseimbangan pada satu server dengan lebih dari pada inti. Jadi, Anda harus berurusan dengan semua peringatan yang biasanya Anda hadapi dalam skenario beban seimbang, kecuali untuk merutekan permintaan.
Eric Burcham

@Kodean Gorilla - Lanjutan ... "Alasan" terbaik yang saya temukan untuk menggunakan fitur proses beberapa pekerja adalah untuk meningkatkan kinerja. Lihat tautan ini: iis-aid.com/articles/performance_testing/… . Tentu saja, Anda sebaiknya tahu apa yang Anda lakukan dengan semua aspek pemrograman yang tidak sinkron yang sering kita abaikan dengan mempertimbangkan situs web, karena sebagian besar (setidaknya untuk memulai) menjalankan satu thread pekerja tunggal. Jadi jawaban singkat untuk pertanyaan saya adalah: Cobalah jika Anda mengalami masalah kinerja.
Eric Burcham

4

Saya selalu mengonfigurasi kumpulan aplikasi khusus untuk situs web. Skenario hosting situs web berbiaya rendah adalah di mana memiliki sejumlah besar situs per kumpulan aplikasi masuk akal.

Batas memori sebenarnya hanyalah ambang batas keamanan primitif untuk mencegah situs menghabiskan semua sumber daya sistem. Perhatikan bahwa ini lebih merupakan masalah potensial pada Windows 2008 R2 x64 daripada pada IIS 6.0 x86, karena aplikasi x86 memiliki plafon memori 2 GB alami. Jauh lebih mudah pada IIS 7.5 untuk aplikasi dengan kebocoran memori untuk mengkonsumsi banyak memori.

Saya juga bukan penggemar kolam aplikasi daur ulang. Jika saya memiliki kumpulan aplikasi dan saya satu-satunya aplikasi yang berjalan, jika tidak ada yang salah dengan kode kami, mungkin tidak perlu mendaur ulang kumpulan aplikasi. Dan jika ada cacat dalam aplikasi, tindakan yang paling tepat adalah memperbaiki kode.


Terima kasih telah menunjukkan batas 32bit pada memori. Saya tidak tahu bagaimana saya melupakan hal-hal ini. Saya juga berpikir pendekatan yang benar jika Anda memiliki aplikasi yang cukup rusak untuk menabrak kumpulan aplikasi adalah memperbaikinya, dengan asumsi Anda memiliki akses ke kode. Saya menghargai sarannya!
Eric Burcham

Kami melakukan beberapa pengujian sendiri. Menjalankan kumpulan aplikasi tampaknya memiliki overhead sekitar 64K per kumpulan aplikasi di atas menjalankan semua aplikasi dalam kumpulan aplikasi yang sama. Itu lebih dari periode sampel 12 jam menggunakan monitor kinerja untuk memantau konsumsi memori. Ini ada di server 64-bit. Saya pikir jika tes sederhana ini ternyata benar, maka biaya sumber daya dari satu kumpulan aplikasi per aplikasi pada dasarnya dapat diabaikan pada perangkat keras modern.
Eric Burcham
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.