Menyetel IIS 10.0
Layanan Informasi Internet (IIS) 10.0 disertakan dengan Windows Server 2022. Ini menggunakan model proses yang mirip dengan IIS 8.5 dan IIS 7.0. Driver web mode kernel (http.sys) menerima dan merutekan permintaan HTTP, dan memenuhi permintaan dari cache responsnya. Proses pekerja mendaftar untuk subspace URL, dan http.sys merutekan permintaan ke proses yang sesuai (atau serangkaian proses untuk kumpulan aplikasi).
HTTP.sys bertanggung jawab atas manajemen koneksi dan penanganan permintaan. Permintaan dapat dilayani dari cache HTTP.sys atau diteruskan ke proses pekerja untuk penanganan lebih lanjut. Beberapa proses pekerja dapat dikonfigurasi, yang menyediakan isolasi dengan biaya yang berkurang. Untuk informasi selengkapnya tentang cara kerja penanganan permintaan, lihat gambar berikut:
HTTP.sys menyertakan cache respons. Ketika permintaan cocok dengan entri dalam cache respons, HTTP.sys mengirim respons cache langsung dari mode kernel. Beberapa platform aplikasi web, seperti ASP.NET, menyediakan mekanisme untuk memungkinkan konten dinamis apa pun di-cache dalam cache mode kernel. Handler file statis di IIS 10.0 secara otomatis menyimpan file yang sering diminta di http.sys.
Karena server web memiliki komponen mode kernel dan mode pengguna, kedua komponen harus disetel untuk performa optimal. Oleh karena itu, menyetel IIS 10.0 untuk beban kerja tertentu termasuk mengonfigurasi hal berikut:
HTTP.sys dan cache mode kernel terkait
Proses pekerja dan IIS mode pengguna, termasuk konfigurasi kumpulan aplikasi
Parameter penyetelan tertentu yang memengaruhi performa
Bagian berikut membahas cara mengonfigurasi aspek mode kernel dan mode pengguna IIS 10.0.
Pengaturan mode kernel
Pengaturan HTTP.sys terkait performa termasuk dalam dua kategori luas: manajemen cache dan manajemen koneksi dan permintaan. Semua pengaturan registri disimpan di bawah entri registri berikut:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters
Catatan Jika layanan HTTP sudah berjalan, Anda harus memulai ulang agar perubahan diterapkan.
Pengaturan manajemen cache
Salah satu manfaat yang HTTP.sys berikan adalah cache mode kernel. Jika respons berada dalam cache mode kernel, Anda dapat memenuhi permintaan HTTP sepenuhnya dari mode kernel, yang secara signifikan menurunkan biaya CPU untuk menangani permintaan. Namun, cache mode kernel IIS 10.0 didasarkan pada memori fisik, dan biaya entri adalah memori yang didudukinya.
Entri dalam cache hanya berguna ketika digunakan. Namun, entri selalu menggunakan memori fisik, apakah entri sedang digunakan atau tidak. Anda harus mengevaluasi kegunaan item dalam cache (penghematan dari dapat melayaninya dari cache) dan biayanya (memori fisik yang ditempati) selama masa pakai entri dengan mempertimbangkan sumber daya yang tersedia (CPU dan memori fisik) dan persyaratan beban kerja. HTTP.sys mencoba menyimpan item yang hanya berguna dan diakses secara aktif di cache, tetapi Anda dapat meningkatkan performa server web dengan menyetel cache HTTP.sys untuk beban kerja tertentu.
Berikut ini adalah beberapa pengaturan yang berguna untuk cache mode kernel HTTP.sys:
Nilai Default UriEnableCache : 1
Nilai bukan nol memungkinkan respons mode kernel dan penembolokan fragmen. Untuk sebagian besar beban kerja, cache harus tetap diaktifkan. Pertimbangkan untuk menonaktifkan cache jika Anda mengharapkan respons dan penembolokan fragmen yang sangat rendah.
Nilai Default UriMaxCacheMegabyteCount : 0
Nilai bukan nol yang menentukan memori maksimum yang tersedia untuk cache mode kernel. Nilai default, 0, memungkinkan sistem untuk secara otomatis menyesuaikan berapa banyak memori yang tersedia untuk cache.
Catatan Menentukan ukuran hanya mengatur maksimum, dan sistem mungkin tidak membiarkan cache tumbuh ke ukuran set maksimum.
Â
Nilai Default UriMaxUriBytes : 262144 byte (256 KB)
Ukuran maksimum entri dalam cache mode kernel. Respons atau fragmen yang lebih besar dari ini tidak di-cache. Jika Anda memiliki cukup memori, pertimbangkan untuk meningkatkan batas. Jika memori terbatas dan entri besar memadati yang lebih kecil, mungkin berguna untuk menurunkan batas.
Nilai Default UriScavengerPeriod : 120 detik
Cache HTTP.sys secara berkala dipindai oleh pemulung, dan entri yang tidak diakses antara pemindaian pemulung dihapus. Mengatur periode pemulung ke nilai tinggi mengurangi jumlah pemindaian pemulung. Namun, penggunaan memori cache mungkin meningkat karena entri yang lebih lama dan lebih jarang diakses dapat tetap berada di cache. Mengatur periode terlalu rendah menyebabkan pemindaian pemulung yang lebih sering, dan dapat mengakibatkan terlalu banyak flush dan churn cache.
Pengaturan manajemen permintaan dan koneksi
Di Windows Server 2022, HTTP.sys mengelola koneksi secara otomatis. Pengaturan registri berikut ini tidak lagi digunakan:
Maks Koneksi ions
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\MaxConnectionsIdle Koneksi ionsHighMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsHighMarkIdle Koneksi ionsLowMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsLowMarkIdleListTrimmerPeriod
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleListTrimmerPeriodRequestBufferLookasideDepth
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\RequestBufferLookasideDepthInternalRequestLookasideDepth
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\InternalRequestLookasideDepth
Pengaturan mode pengguna
Pengaturan di bagian ini memengaruhi perilaku proses pekerja IISÂ 10.0. Sebagian besar pengaturan ini dapat ditemukan dalam file konfigurasi XML berikut:
%SystemRoot%\system32\inetsrv\config\applicationHost.config
Gunakan Appcmd.exe, Konsol Manajemen IIS 10.0, Cmdlet PowerShell WebAdministration, atau IISAdministration untuk mengubahnya. Sebagian besar pengaturan terdeteksi secara otomatis, dan tidak memerlukan mulai ulang proses pekerja IIS 10.0 atau server aplikasi web. Untuk informasi selengkapnya tentang file applicationHost.config, lihat Pengantar ApplicationHost.config.
Pengaturan CPU yang ideal untuk perangkat keras NUMA
Mulai dari Windows Server 2016, IIS 10.0 mendukung penetapan CPU ideal otomatis untuk rangkaian kumpulan utasnya untuk meningkatkan performa dan skalabilitas pada perangkat keras NUMA. Fitur ini diaktifkan secara default dan dapat dikonfigurasi melalui kunci registri berikut:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\ThreadPoolUseIdealCpu
Dengan mengaktifkan fitur ini, manajer utas IIS melakukan upaya terbaik untuk mendistribusikan utas kumpulan utas IIS secara merata di semua CPU di semua simpul NUMA berdasarkan bebannya saat ini. Secara umum, disarankan untuk menjaga pengaturan default ini tidak berubah untuk perangkat keras NUMA.
Catatan Pengaturan CPU yang ideal berbeda dari pengaturan penetapan simpul NUMA proses pekerja (numaNodeAssignment dan numaNodeAffinityMode) yang diperkenalkan dalam Pengaturan CPU untuk Kumpulan Aplikasi. Pengaturan CPU yang ideal memengaruhi bagaimana IIS mendistribusikan utas kumpulan utasnya, sementara pengaturan penetapan simpul NUMA proses pekerja menentukan pada simpul NUMA mana proses pekerja dimulai.
Pengaturan perilaku cache mode pengguna
Bagian ini menjelaskan pengaturan yang memengaruhi perilaku penembolokan di IISÂ 10.0. Cache mode pengguna diimplementasikan sebagai modul yang mendengarkan peristiwa penembolokan global yang dinaikkan oleh alur terintegrasi. Untuk sepenuhnya menonaktifkan cache mode pengguna, hapus modul FileCacheModule (cachfile.dll) dari daftar modul yang diinstal di bagian konfigurasi system.webServer/globalModules di applicationHost.config.
system.webServer/caching
| Atribut | Deskripsi | Default |
|---|---|---|
| Diaktifkan | Menonaktifkan cache IIS mode pengguna saat diatur ke False. Ketika tingkat hit cache sangat kecil, Anda dapat menonaktifkan cache sepenuhnya untuk menghindari overhead yang terkait dengan jalur kode cache. Menonaktifkan cache mode pengguna tidak menonaktifkan cache mode kernel. | Benar |
| enableKernelCache | Menonaktifkan cache mode kernel saat diatur ke False. | Benar |
| maxCacheSize | Membatasi ukuran cache mode pengguna IIS ke ukuran yang ditentukan dalam Megabyte. IIS menyesuaikan default tergantung pada memori yang tersedia. Pilih nilai dengan hati-hati berdasarkan ukuran set file yang sering diakses versus jumlah RAM atau ruang alamat proses IIS. | 0 |
| maxResponseSize | Cache file hingga ukuran yang ditentukan. Nilai aktual tergantung pada jumlah dan ukuran file terbesar dalam himpunan data versus RAM yang tersedia. Penembolokan file besar yang sering diminta dapat mengurangi penggunaan CPU, akses disk, dan latensi terkait. | 262144 |
Pengaturan perilaku pemadatan
IIS mulai dari 7.0 memadatkan konten statis secara default. Selain itu, pemadatan konten dinamis diaktifkan secara default saat DynamicCompressionModule diinstal. Pemadatan mengurangi penggunaan bandwidth tetapi meningkatkan penggunaan CPU. Konten terkompresi di-cache dalam cache mode kernel jika memungkinkan. Mulai dari 8.5, IIS memungkinkan kompresi dikontrol secara independen untuk konten statis dan dinamis. Konten statis biasanya mengacu pada konten yang tidak berubah, seperti file GIF atau HTM. Konten dinamis biasanya dihasilkan oleh skrip atau kode di server, yaitu halaman ASP.NET. Anda dapat menyesuaikan klasifikasi ekstensi tertentu sebagai statis atau dinamis.
Untuk sepenuhnya menonaktifkan kompresi, hapus staticCompressionModule dan DynamicCompressionModule dari daftar modul di bagian system.webServer/globalModules di applicationHost.config.
system.webServer/httpCompression
| Atribut | Deskripsi | Default |
|---|---|---|
| staticCompression-EnableCpuUsage staticCompression-DisableCpuUsage dynamicCompression-EnableCpuUsage dynamicCompression-DisableCpuUsage |
Mengaktifkan atau menonaktifkan pemadatan jika persentase penggunaan CPU saat ini berada di atas atau di bawah batas yang ditentukan. Dimulai dengan IIS 7.0, kompresi secara otomatis dinonaktifkan jika CPU status stabil meningkat di atas ambang batas nonaktifkan. Pemadatan diaktifkan jika CPU turun di bawah ambang batas aktifkan. |
masing-masing 50, 100, 50, dan 90 |
| direktori | Menentukan direktori tempat versi terkompresi file statis disimpan sementara dan di-cache. Pertimbangkan untuk memindahkan direktori ini dari drive sistem jika sering diakses. | %SystemDrive%\inetpub\temp\IIS File Terkompresi Sementara |
| doDiskSpaceLimiting | Menentukan apakah batas ada untuk berapa banyak ruang disk yang dapat ditempuh semua file terkompresi. File terkompresi disimpan dalam direktori kompresi yang ditentukan oleh atribut direktori . | Benar |
| maxDiskSpaceUsage | Menentukan jumlah byte ruang disk yang dapat ditempat file terkompresi dalam direktori pemadatan. Pengaturan ini mungkin perlu ditingkatkan jika ukuran total semua konten terkompresi terlalu besar. |
100 MB |
system.webServer/urlCompression
| Atribut | Deskripsi | Default |
|---|---|---|
| doStaticCompression | Menentukan apakah konten statis dikompresi. | Benar |
| doDynamicCompression | Menentukan apakah konten dinamis dikompresi. | Benar |
Catatan
Untuk server yang menjalankan IIS 10.0 yang memiliki penggunaan CPU rata-rata rendah, pertimbangkan untuk mengaktifkan pemadatan untuk konten dinamis, terutama jika respons besar. Ini harus terlebih dahulu dilakukan di lingkungan pengujian untuk menilai efek pada penggunaan CPU dari garis besar.
Menyetel daftar dokumen default
Modul dokumen default menangani permintaan HTTP untuk akar direktori dan menerjemahkannya ke dalam permintaan untuk file tertentu, seperti Default.htm atau Index.htm. Rata-rata, sekitar 25 persen dari semua permintaan di Internet melalui jalur dokumen default. Ini bervariasi secara signifikan untuk masing-masing situs. Ketika permintaan HTTP tidak menentukan nama file, modul dokumen default mencari daftar dokumen default yang diizinkan untuk setiap nama dalam sistem file. Hal ini dapat berdampak buruk pada performa, terutama jika menjangkau konten mengharuskan melakukan perjalanan pulang pergi jaringan atau menyentuh disk.
Anda dapat menghindari overhead dengan menonaktifkan dokumen default secara selektif dan dengan mengurangi atau mengurutkan daftar dokumen. Untuk situs web yang menggunakan dokumen default, Anda harus mengurangi daftar menjadi hanya tipe dokumen default yang digunakan. Selain itu, urutkan daftar sehingga dimulai dengan nama file dokumen default yang paling sering diakses.
Anda dapat secara selektif mengatur perilaku dokumen default pada URL tertentu dengan menyesuaikan konfigurasi di dalam tag lokasi di applicationHost.config atau dengan menyisipkan file web.config langsung di direktori konten. Ini memungkinkan pendekatan hibrid, yang memungkinkan dokumen default hanya jika diperlukan dan mengatur daftar ke nama file yang benar untuk setiap URL.
Untuk menonaktifkan dokumen default sepenuhnya, hapus DefaultDocumentModule dari daftar modul di bagian system.webServer/globalModules di applicationHost.config.
system.webServer/defaultDocument
| Atribut | Deskripsi | Default |
|---|---|---|
| diaktifkan | Menentukan bahwa dokumen default diaktifkan. | Benar |
<files> elemen |
Menentukan nama file yang dikonfigurasi sebagai dokumen default. | Daftar defaultnya adalah Default.htm, Default.asp, Index.htm, Index.html, Iisstart.htm, dan Default.aspx. |
Pengelogan biner pusat
Ketika sesi server memiliki banyak grup URL di bawahnya, proses pembuatan ratusan file log yang diformat untuk grup URL individual dan menulis data log ke disk dapat dengan cepat menggunakan sumber daya CPU dan memori yang berharga, sehingga menciptakan masalah performa dan skalabilitas. Pengelogan biner terpusat meminimalkan jumlah sumber daya sistem yang digunakan untuk pengelogan, sementara pada saat yang sama memberikan data log terperinci untuk organisasi yang memerlukannya. Mengurai log format biner memerlukan alat pasca-pemrosesan.
Anda dapat mengaktifkan pengelogan biner pusat dengan mengatur atribut centralLogFileMode ke CentralBinary dan mengatur atribut yang diaktifkan ke True. Pertimbangkan untuk memindahkan lokasi file log pusat dari partisi sistem dan ke drive pengelogan khusus untuk menghindari ketidakcocokan antara aktivitas sistem dan aktivitas pengelogan.
system.applicationHost/log
| Atribut | Deskripsi | Default |
|---|---|---|
| centralLogFileMode | Menentukan mode pengelogan untuk server. Ubah nilai ini menjadi CentralBinary untuk mengaktifkan pengelogan biner pusat. | Site |
system.applicationHost/log/centralBinaryLogFile
| Atribut | Deskripsi | Default |
|---|---|---|
| diaktifkan | Menentukan apakah pengelogan biner pusat diaktifkan. | Salah |
| direktori | Menentukan direktori tempat entri log ditulis. | %SystemDrive%\inetpub\logs\LogFiles |
Penyetelan aplikasi dan situs
Pengaturan berikut berkaitan dengan kumpulan aplikasi dan penyetelan situs.
system.applicationHost/applicationPools/applicationPoolDefaults
| Atribut | Deskripsi | Default |
|---|---|---|
| queueLength | Menunjukkan untuk HTTP.sys berapa banyak permintaan yang diantrekan untuk kumpulan aplikasi sebelum permintaan di masa mendatang ditolak. Ketika nilai untuk properti ini terlampaui, IIS menolak permintaan berikutnya dengan kesalahan 503. Pertimbangkan untuk meningkatkan ini untuk aplikasi yang berkomunikasi dengan penyimpanan data back-end latensi tinggi jika 503 kesalahan diamati. |
1000 |
| enable32BitAppOnWin64 | Ketika True, memungkinkan aplikasi 32-bit berjalan di komputer yang memiliki prosesor 64-bit. Pertimbangkan untuk mengaktifkan mode 32-bit jika konsumsi memori menjadi perhatian. Karena ukuran pointer dan ukuran instruksi lebih kecil, aplikasi 32-bit menggunakan lebih sedikit memori daripada aplikasi 64-bit. Kelemahan untuk menjalankan aplikasi 32-bit pada komputer 64-bit adalah ruang alamat mode pengguna dibatasi hingga 4 GB. |
Salah |
system.applicationHost/sites/VirtualDirectoryDefault
| Atribut | Deskripsi | Default |
|---|---|---|
| allowSubDirConfig | Menentukan apakah IIS mencari file web.config di direktori konten yang lebih rendah dari tingkat saat ini (True) atau tidak mencari file web.config di direktori konten yang lebih rendah dari tingkat saat ini (False). Dengan memberlakukan batasan sederhana, yang memungkinkan konfigurasi hanya di direktori virtual, IISÂ 10.0 dapat mengetahui bahwa, kecuali /<name>.htm adalah direktori virtual, seharusnya tidak mencari file konfigurasi. Melompati operasi file tambahan dapat secara signifikan meningkatkan performa situs web yang memiliki serangkaian konten statis yang diakses secara acak yang sangat besar. | Benar |
Mengelola modul IIS 10.0
IIS 10.0 telah diperhitungkan dalam beberapa modul yang dapat diperluas pengguna untuk mendukung struktur modular. Faktorisasi ini memiliki biaya yang kecil. Untuk setiap modul, alur terintegrasi harus memanggil modul untuk setiap peristiwa yang relevan dengan modul. Ini terjadi terlepas dari apakah modul harus melakukan pekerjaan apa pun. Anda dapat menghemat siklus dan memori CPU dengan menghapus semua modul yang tidak relevan dengan situs web tertentu.
Server web yang disetel untuk file statis sederhana mungkin hanya menyertakan lima modul berikut: UriCacheModule, HttpCacheModule, StaticFileModule, AnonymousAuthenticationModule, dan HttpLoggingModule.
Untuk menghapus modul dari applicationHost.config, hapus semua referensi ke modul dari bagian system.webServer/handlers dan system.webServer/modules selain menghapus deklarasi modul di system.webServer/globalModules.
Pengaturan ASP klasik
Biaya utama pemrosesan permintaan ASP klasik termasuk menginisialisasi mesin skrip, mengkompilasi skrip ASP yang diminta ke dalam templat ASP, dan menjalankan templat pada mesin skrip. Meskipun biaya eksekusi templat tergantung pada kompleksitas skrip ASP yang diminta, modul ASP klasik IIS dapat menyimpan mesin skrip dalam memori dan templat cache di memori dan disk (hanya jika luapan cache templat dalam memori) untuk meningkatkan performa dalam skenario terikat CPU.
Pengaturan berikut digunakan untuk mengonfigurasi cache templat ASP klasik dan cache mesin skrip, dan tidak memengaruhi pengaturan ASP.NET.
system.webServer/asp/cache
| Atribut | Deskripsi | Default |
|---|---|---|
| diskTemplateCacheDirectory | Nama direktori yang digunakan ASP untuk menyimpan templat yang dikompilasi saat cache dalam memori meluap. Rekomendasi: Atur ke direktori yang tidak banyak digunakan, misalnya, drive yang tidak dibagikan dengan sistem operasi, log IIS, atau konten lain yang sering diakses. |
%SystemDrive%\inetpub\temp\ASP Compiled Templates |
| maxDiskTemplateCacheFiles | Menentukan jumlah maksimum templat ASP yang dikompilasi yang dapat di-cache pada disk. Rekomendasi: Atur ke nilai maksimum 0x7FFFFFFF. |
2000 |
| scriptFileCacheSize | Atribut ini menentukan jumlah maksimum templat ASP yang dikompilasi yang dapat di-cache dalam memori. Rekomendasi: Atur ke setidaknya sebanyak jumlah skrip ASP yang sering diminta yang dilayani oleh kumpulan aplikasi. Jika memungkinkan, atur ke templat ASP sebanyak yang diizinkan oleh batas memori. |
500 |
| scriptEngineCacheMax | Menentukan jumlah maksimum mesin skrip yang akan menyimpan cache dalam memori. Rekomendasi: Atur ke setidaknya sebanyak jumlah skrip ASP yang sering diminta yang dilayani oleh kumpulan aplikasi. Jika memungkinkan, atur ke mesin skrip sebanyak yang diizinkan oleh batas memori. |
250 |
system.webServer/asp/limits
| Atribut | Deskripsi | Default |
|---|---|---|
| processorThreadMax | Menentukan jumlah maksimum utas pekerja per prosesor yang dapat dibuat ASP. Tingkatkan jika pengaturan saat ini tidak cukup untuk menangani beban, yang dapat menyebabkan kesalahan saat melayani permintaan atau menyebabkan kurangnya penggunaan sumber daya CPU. | 25 |
system.webServer/asp/comPlus
| Atribut | Deskripsi | Default |
|---|---|---|
| executeInMta | Atur ke True jika kesalahan atau kegagalan terdeteksi saat IIS melayani konten ASP. Ini dapat terjadi, misalnya, ketika menghosting beberapa situs terisolasi di mana setiap situs berjalan di bawah proses pekerjanya sendiri. Kesalahan biasanya dilaporkan dari COM+ di Pemantau Peristiwa. Pengaturan ini memungkinkan model apartemen multi-utas di ASP. | Salah |
pengaturan konkurensi ASP.NET
ASP.NET 3,5
Secara default, ASP.NET membatasi konkurensi permintaan untuk mengurangi konsumsi memori status stabil di server. Aplikasi konkurensi tinggi mungkin perlu menyesuaikan beberapa pengaturan untuk meningkatkan performa keseluruhan. Anda dapat mengubah pengaturan ini dalam file aspnet.config:
<system.web>
<applicationPool maxConcurrentRequestsPerCPU="5000"/>
</system.web>
Pengaturan berikut berguna untuk sepenuhnya menggunakan sumber daya pada sistem:
nilai default maxConcurrentRequestPerCpu : 5000
Pengaturan ini membatasi jumlah maksimum eksekusi permintaan ASP.NET secara bersamaan pada sistem. Nilai defaultnya konservatif untuk mengurangi konsumsi memori aplikasi ASP.NET. Pertimbangkan untuk meningkatkan batas ini pada sistem yang menjalankan aplikasi yang melakukan operasi I/O yang panjang dan sinkron. Jika tidak, pengguna dapat mengalami latensi tinggi karena kegagalan antrean atau permintaan karena melebihi batas antrean di bawah beban tinggi saat pengaturan default digunakan.
ASP.NET 4.6
Selain pengaturan maxConcurrentRequestPerCpu, ASP.NET 4.7 juga menyediakan pengaturan untuk meningkatkan performa dalam aplikasi yang sangat bergantung pada operasi asinkron. Pengaturan dapat diubah dalam file aspnet.config.
<system.web>
<applicationPool percentCpuLimit="90" percentCpuLimitMinActiveRequestPerCpu="100"/>
</system.web>
- percentCpuLimit Nilai default: 90 Permintaan asinkron memiliki beberapa masalah skalabilitas ketika beban besar (di luar kemampuan perangkat keras) diletakkan pada skenario tersebut. Masalahnya adalah karena sifat alokasi pada skenario asinkron. Dalam kondisi ini, alokasi akan terjadi ketika operasi asinkron dimulai, dan akan dikonsumsi ketika selesai. Pada saat itu, sangat mungkin objek telah dipindahkan ke generasi 1 atau 2 oleh GC. Ketika ini terjadi, meningkatkan beban akan menunjukkan peningkatan pada permintaan per detik (rp) hingga satu titik. Setelah kita melewati titik itu, waktu yang dihabiskan di GC akan mulai menjadi masalah dan rp akan mulai menurun, memiliki efek penskalaan negatif. Untuk memperbaiki masalah, ketika penggunaan cpu melebihi pengaturancentCpuLimit, permintaan akan dikirim ke antrean asli ASP.NET.
- percentCpuLimitMinActiveRequestPerCpu Nilai default: 100 pembatasan CPU (pengaturan percentCpuLimit) tidak didasarkan pada jumlah permintaan tetapi pada seberapa mahal mereka. Akibatnya, mungkin hanya ada beberapa permintaan intensif CPU yang menyebabkan pencadangan dalam antrean asli tanpa cara untuk mengosongkannya selain dari permintaan masuk. Untuk mengatasi masalah ini, percentCpuLimitMinActiveRequestPerCpu dapat digunakan untuk memastikan jumlah minimum permintaan dilayani sebelum pembatasan dimulai.
Opsi proses dan daur ulang pekerja
Anda dapat mengonfigurasi opsi untuk mendaur ulang proses pekerja IIS dan memberikan solusi praktis untuk situasi atau peristiwa akut tanpa memerlukan intervensi atau mengatur ulang layanan atau komputer. Situasi dan peristiwa tersebut termasuk kebocoran memori, peningkatan beban memori, atau proses pekerja yang tidak responsif atau menganggur. Dalam kondisi biasa, opsi daur ulang mungkin tidak diperlukan dan daur ulang dapat dimatikan atau sistem dapat dikonfigurasi untuk mendaur ulang sangat jarang.
Anda dapat mengaktifkan daur ulang proses untuk aplikasi tertentu dengan menambahkan atribut ke elemen daur ulang/periodicRestart . Peristiwa daur ulang dapat dipicu oleh beberapa peristiwa termasuk penggunaan memori, jumlah permintaan tetap, dan periode waktu tetap. Ketika proses pekerja didaur ulang, permintaan antrean dan eksekusi dikosongkan, dan proses baru secara bersamaan mulai melayani permintaan baru. Elemen daur ulang/periodicRestart adalah per aplikasi, yang berarti bahwa setiap atribut dalam tabel berikut dipartisi berdasarkan per aplikasi.
system.applicationHost/applicationPools/ApplicationPoolDefaults/recycling/periodicRestart
| Atribut | Deskripsi | Default |
|---|---|---|
| memory | Aktifkan daur ulang proses jika konsumsi memori virtual melebihi batas yang ditentukan dalam kilobyte. Ini adalah pengaturan yang berguna untuk komputer 32-bit yang memiliki ruang alamat kecil 2 GB. Ini dapat membantu menghindari permintaan yang gagal karena kesalahan di luar memori. | 0 |
| privateMemory | Aktifkan daur ulang proses jika alokasi memori privat melebihi batas tertentu dalam kilobyte. | 0 |
| permintaan | Aktifkan daur ulang proses setelah sejumlah permintaan tertentu. | 0 |
| waktu | Aktifkan daur ulang proses setelah periode waktu tertentu. | 29:00:00 |
Penyetelan halaman proses pekerja dinamis
Mulai Windows Server 2012 R2, IIS menawarkan opsi untuk mengonfigurasi proses pekerja untuk ditangguhkan setelah diam untuk sementara waktu (selain opsi penghentian, yang ada sejak IIS 7).
Tujuan utama dari fitur penghentian proses pekerja diam dan penghentian proses pekerja menganggur adalah untuk menghemat pemanfaatan memori di server, karena situs dapat mengonsumsi banyak memori bahkan jika hanya duduk di sana, mendengarkan. Tergantung pada teknologi yang digunakan di situs (konten statis vs ASP.NET vs kerangka kerja lainnya), memori yang digunakan dapat berada di mana saja dari sekitar 10 MB hingga ratusan MB, dan ini berarti bahwa jika server Anda dikonfigurasi dengan banyak situs, mencari tahu pengaturan paling efektif untuk situs Anda dapat secara dramatis meningkatkan performa situs aktif dan ditangguhkan.
Sebelum kita masuk ke spesifik, kita harus ingat bahwa jika tidak ada batasan memori, maka mungkin yang terbaik adalah mengatur situs agar tidak pernah ditangguhkan atau dihentikan. Lagi pula, ada sedikit nilai dalam mengakhiri proses pekerja jika itu satu-satunya di komputer.
Catatan
Jika situs menjalankan kode yang tidak stabil, seperti kode dengan kebocoran memori, atau tidak stabil, mengatur situs untuk dihentikan di diam dapat menjadi alternatif yang cepat dan kotor untuk memperbaiki bug kode. Ini bukan sesuatu yang akan kami dorong, tetapi dalam kegentingan, mungkin lebih baik menggunakan fitur ini sebagai mekanisme pembersihan sementara solusi yang lebih permanen sedang dalam pekerjaan.]
Faktor lain yang perlu dipertimbangkan adalah bahwa jika situs memang menggunakan banyak memori, maka proses penangguhan itu sendiri mengambil tol, karena komputer harus menulis data yang digunakan oleh proses pekerja ke disk. Jika proses pekerja menggunakan potongan memori yang besar, maka menangguhkannya mungkin lebih mahal daripada biaya harus menunggunya untuk memulai kembali.
Untuk membuat yang terbaik dari fitur penangguhan proses pekerja, Anda perlu meninjau situs Anda di setiap kumpulan aplikasi, dan memutuskan mana yang harus ditangguhkan, yang harus dihentikan, dan mana yang harus aktif tanpa batas waktu. Untuk setiap tindakan dan setiap situs, Anda perlu mencari tahu periode waktu habis yang ideal.
Idealnya, situs yang akan Anda konfigurasi untuk penangguhan atau penghentian adalah situs yang memiliki pengunjung setiap hari, tetapi tidak cukup untuk menjamin tetap aktif sepanjang waktu. Ini biasanya situs dengan sekitar 20 pengunjung unik sehari atau kurang. Anda dapat menganalisis pola lalu lintas menggunakan file log situs dan menghitung lalu lintas harian rata-rata.
Perlu diingat bahwa setelah pengguna tertentu terhubung ke situs, mereka biasanya akan tetap berada di dalamnya setidaknya untuk sementara waktu, membuat permintaan tambahan, dan jadi hanya menghitung permintaan harian mungkin tidak secara akurat mencerminkan pola lalu lintas nyata. Untuk mendapatkan pembacaan yang lebih akurat, Anda juga bisa menggunakan alat, seperti Microsoft Excel, untuk menghitung waktu rata-rata antar permintaan. Misalnya:
| Angka | Minta URL | Waktu permintaan | Delta |
|---|---|---|---|
| 1 | /SourceSilverLight/Geosource.web/grosource.html | 10:01 | |
| 2 | /SourceSilverLight/Geosource.web/sliverlight.js | 10.10 | 0:09 |
| 3 | /SourceSilverLight/Geosource.web/clientbin/geo/1.aspx | 10:11 | 0:01 |
| 4 | /lClientAccessPolicy.xml | 10:12 | 0:01 |
| 5 | / SourceSilverLight/GeosourcewebService/Service.asmx | 10:23 | 0:11 |
| 6 | / SourceSilverLight/Geosource.web/GeoSearchServer...¦. | 11.50 | 1:27 |
| 7 | /rest/Services/CachedServices/Silverlight_load_la...¦ | 12:50 | 1.00 |
| 8 | /rest/Services/CachedServices/Silverlight_basemap...¦. | 12:51 | 0:01 |
| 9 | /rest/Services/DynamicService/ Silverlight_basemap...¦. | 12:59 | 0:08 |
| 10 | /rest/Services/CachedServices/Ortho_2004_cache.as... | 13:40 | 0:41 |
| 11 | /rest/Services/CachedServices/Ortho_2005_cache.js | 13:40 | 0.00 |
| 12 | /rest/Services/CachedServices/OrthoBaseEngine.aspx | 13:41 | 0:01 |
Namun, bagian yang sulit adalah mencari tahu pengaturan apa yang akan diterapkan agar masuk akal. Dalam kasus kami, situs mendapatkan banyak permintaan dari pengguna, dan tabel di atas menunjukkan bahwa total 4 sesi unik terjadi dalam jangka waktu 4 jam. Dengan pengaturan default untuk penangguhan proses pekerja dari kumpulan aplikasi, situs akan dihentikan setelah batas waktu default 20 menit, yang berarti masing-masing pengguna ini akan mengalami siklus spin-up situs. Ini menjadikannya kandidat yang ideal untuk penangguhan proses pekerja, karena untuk sebagian besar waktu, situs tidak aktif, dan sehingga menangguhkan itu akan menghemat sumber daya, dan memungkinkan pengguna untuk mencapai situs hampir seketika.
Catatan akhir dan sangat penting tentang ini adalah bahwa performa disk sangat penting untuk fitur ini. Karena proses penangguhan dan bangun melibatkan penulisan dan pembacaan data dalam jumlah besar ke hard drive, kami sangat menyarankan untuk menggunakan disk cepat untuk ini. Solid State Drives (SSD) sangat ideal dan sangat direkomendasikan untuk ini, dan Anda harus memastikan bahwa file halaman Windows disimpan di atasnya (jika sistem operasi itu sendiri tidak diinstal pada SSD, konfigurasikan sistem operasi untuk memindahkan file halaman ke dalamnya).
Baik Anda menggunakan SSD atau tidak, sebaiknya perbaiki ukuran file halaman untuk mengakomodasi penulisan data page-out ke dalamnya tanpa mengubah ukuran file. Pengubahan ukuran file halaman mungkin terjadi ketika sistem operasi perlu menyimpan data dalam file halaman, karena secara default, Windows dikonfigurasi untuk menyesuaikan ukurannya secara otomatis berdasarkan kebutuhan. Dengan mengatur ukuran ke ukuran tetap, Anda dapat mencegah mengubah ukuran dan meningkatkan performa banyak.
Untuk mengonfigurasi ukuran file halaman yang telah diperbaiki sebelumnya, Anda perlu menghitung ukuran idealnya, yang tergantung pada berapa banyak situs yang akan Anda tangguhkan, dan berapa banyak memori yang mereka konsumsi. Jika rata-rata adalah 200 MB untuk proses pekerja aktif dan Anda memiliki 500 situs di server yang akan ditangguhkan, maka file halaman harus setidaknya (200 * 500) MB di atas ukuran dasar file halaman (jadi basis + 100 GB dalam contoh kami).
Catatan
Ketika situs ditangguhkan, mereka akan mengonsumsi masing-masing sekitar 6 MB, jadi dalam kasus kami, penggunaan memori jika semua situs ditangguhkan akan sekitar 3 GB. Namun, pada kenyataannya, Anda mungkin tidak akan pernah menangguhkan mereka semua pada saat yang sama.
Parameter penyetelan Keamanan Lapisan Transportasi
Penggunaan Transport Layer Security (TLS) memberlakukan biaya CPU tambahan. Komponen TLS yang paling mahal adalah biaya untuk membangun pembentukan sesi karena melibatkan jabat tangan penuh. Koneksi ulang, enkripsi, dan dekripsi juga menambah biaya. Untuk performa TLS yang lebih baik, lakukan hal berikut:
Aktifkan HTTP keep-alives untuk sesi TLS. Ini menghilangkan biaya pembentukan sesi.
Gunakan kembali sesi jika sesuai, terutama dengan lalu lintas yang tidak tetap hidup.
Terapkan enkripsi secara selektif hanya ke halaman atau bagian situs yang membutuhkannya, bukan ke seluruh situs.
Catatan
- Kunci yang lebih besar memberikan lebih banyak keamanan, tetapi juga menggunakan lebih banyak waktu CPU.
- Semua komponen mungkin tidak perlu dienkripsi. Namun, mencampur HTTP dan HTTPS biasa dapat mengakibatkan peringatan pop-up bahwa tidak semua konten di halaman aman.
Antarmuka Pemrograman Aplikasi Server Internet (ISAPI)
Tidak ada parameter penyetelan khusus yang diperlukan untuk aplikasi ISAPI. Jika Anda menulis ekstensi ISAPI privat, pastikan ekstensi tersebut ditulis untuk performa dan penggunaan sumber daya.
Panduan penyetelan kode terkelola
Model alur terintegrasi di IIS 10.0 memungkinkan fleksibilitas dan ekstensibilitas tingkat tinggi. Modul kustom yang diimplementasikan dalam kode asli atau terkelola dapat dimasukkan ke dalam alur, atau modul tersebut dapat menggantikan modul yang ada. Meskipun model ekstensibilitas ini menawarkan kenyamanan dan kesederhanaan, Anda harus berhati-hati sebelum Anda memasukkan modul terkelola baru yang terhubung ke peristiwa global. Menambahkan modul terkelola global berarti bahwa semua permintaan, termasuk permintaan file statis, harus menyentuh kode terkelola. Modul kustom rentan terhadap peristiwa seperti pengumpulan sampah. Selain itu, modul kustom menambahkan biaya CPU yang signifikan karena data marshaling antara kode asli dan terkelola. Jika memungkinkan, Anda harus mengatur preCondition ke managedHandler untuk modul terkelola.
Untuk mendapatkan performa startup dingin yang lebih baik, pastikan Anda melakukan prakompilasi situs web ASP.NET atau memanfaatkan fitur Inisialisasi Aplikasi IIS untuk menghangatkan aplikasi.
Jika status sesi tidak diperlukan, pastikan Anda menonaktifkannya untuk setiap halaman.
Jika ada banyak operasi terikat I/O, coba gunakan versi asinkron API yang relevan yang akan memberi Anda skalabilitas yang jauh lebih baik.
Juga menggunakan Cache Output dengan benar juga akan meningkatkan performa situs web Anda.
Saat Anda menjalankan beberapa host yang berisi skrip ASP.NET dalam mode terisolasi (satu kumpulan aplikasi per situs), pantau penggunaan memori. Pastikan bahwa server memiliki CUKUP RAM untuk jumlah kumpulan aplikasi yang berjalan bersamaan yang diharapkan. Pertimbangkan untuk menggunakan beberapa domain aplikasi alih-alih beberapa proses terisolasi.
Masalah lain yang memengaruhi performa IIS
Masalah berikut dapat memengaruhi performa IIS:
Penginstalan filter yang tidak sadar cache
Penginstalan filter yang tidak sadar http-cache menyebabkan IIS sepenuhnya menonaktifkan penembolokan, yang mengakibatkan performa yang buruk. Filter ISAPI yang ditulis sebelum IISÂ 6.0 dapat menyebabkan perilaku ini.
Permintaan Common Gateway Interface (CGI)
Untuk alasan performa, penggunaan aplikasi CGI untuk melayani permintaan tidak disarankan dengan IIS. Sering membuat dan menghapus proses CGI melibatkan overhead yang signifikan. Alternatif yang lebih baik termasuk menggunakan FastCGI, skrip aplikasi ISAPI, dan skrip ASP atau ASP.NET. Isolasi tersedia untuk masing-masing opsi ini.