Penulis: Rob Howard Terjemahan: Ikan tropis
Artikel ini membahas:
· Rahasia umum kinerja ASP.NET
· Tip dan trik berguna untuk meningkatkan kinerja ASP.NET
· Rekomendasi untuk menggunakan database di ASP.NET
· Caching dan pemrosesan latar belakang di ASP.NET
Menulis aplikasi web menggunakan ASP.NET sangatlah sederhana. Hal ini sangat sederhana sehingga banyak pengembang tidak meluangkan waktu untuk membangun aplikasi mereka agar bekerja dengan baik. Pada artikel ini, saya merekomendasikan 10 tips untuk menulis aplikasi web berkinerja tinggi. Saya tidak akan membatasi pembahasan saya pada aplikasi ASP.NET, karena aplikasi ASP.NET hanyalah subset dari aplikasi Web. Artikel ini tidak dimaksudkan sebagai panduan pasti untuk mengoptimalkan kinerja aplikasi web - buku lengkap dapat dengan mudah melakukan hal itu. Sebaliknya, kita harus menganggap artikel ini sebagai titik awal yang baik.
Sebelum saya menjadi gila kerja, saya sering melakukan panjat tebing. Sebelum melakukan pendakian apa pun, saya lebih suka melihat rute di panduan perjalanan dan membaca rekomendasi dari orang-orang yang pernah ke puncak. Namun betapapun bagusnya buku panduan yang ditulis, Anda memerlukan pengalaman pendakian yang sebenarnya sebelum mencoba tujuan yang menantang. Demikian pula, Anda hanya dapat mempelajari cara menulis aplikasi Web berkinerja tinggi ketika Anda dihadapkan pada perbaikan masalah kinerja atau menjalankan situs dengan throughput tinggi.
Pengalaman pribadi saya berasal dari bekerja sebagai Foundation Program Manager di tim ASP.NET di Microsoft, memelihara dan mengelola www.asp.net , dan membantu arsitek Community Server, salah satu dari beberapa aplikasi ASP.NET yang terkenal (ASP.NET Forums , .Text, dan nGallery terhubung ke satu platform). Saya yakin beberapa tips yang telah membantu saya ini akan bermanfaat bagi Anda juga.
Anda harus mempertimbangkan untuk memisahkan aplikasi Anda menjadi beberapa lapisan logis. Anda mungkin pernah mendengar tentang arsitektur 3-tier (atau n-tier). Ini biasanya merupakan pola struktural yang secara fisik membagi bisnis dan/atau perangkat keras menjadi divisi fungsional. Jika sistem memerlukan skala yang lebih besar, lebih banyak perangkat keras dapat ditambahkan dengan mudah. Namun, hal ini akan mengakibatkan penurunan kinerja yang terkait dengan lompatan bisnis dan mesin, jadi kita harus menghindarinya. Jadi bila memungkinkan, coba jalankan halaman ASP.NET dan komponen terkait halaman tersebut dalam aplikasi yang sama.
Karena pemisahan kode dan batasan antar lapisan, penggunaan layanan Web atau jarak jauh dapat mengurangi kinerja sebesar 20% atau lebih.
Lapisan datanya sedikit berbeda karena biasanya lebih baik memiliki perangkat keras yang didedikasikan untuk database. Namun, biaya proses melompat ke database masih tinggi, sehingga kinerja pada lapisan data harus menjadi pertimbangan pertama Anda saat mengoptimalkan kode Anda.
Sebelum berinvestasi dalam memperbaiki masalah kinerja aplikasi Anda, pastikan Anda menganalisis aplikasi Anda untuk menemukan akar penyebab masalahnya. Penghitung kinerja utama (seperti yang menunjukkan persentase waktu yang dihabiskan untuk melakukan pengumpulan sampah) juga sangat berguna dalam mengetahui di mana aplikasi menghabiskan sebagian besar waktunya. Meskipun tempat-tempat di mana waktu dihabiskan seringkali kurang intuitif.
Pada artikel ini saya membahas dua cara untuk meningkatkan kinerja: optimasi skala besar, seperti menggunakan caching ASP.NET, dan optimasi skala kecil, yang sering diulang. Pengoptimalan kecil ini terkadang merupakan hal yang paling menarik. Perubahan kecil yang Anda buat pada kode Anda akan dipanggil ribuan kali. Optimalkan sebagian besar dan Anda mungkin akan menemukan lompatan besar dalam kinerja keseluruhan. Dengan mengoptimalkan dalam porsi kecil, Anda mungkin mengurangi beberapa mikrodetik dari permintaan tertentu, namun secara kumulatif di semua permintaan per hari, Anda akan mendapatkan peningkatan kinerja yang tidak terduga.
Performa di lapisan data
Saat Anda mulai mengoptimalkan kinerja aplikasi, ada satu pengujian penting yang dapat Anda prioritaskan: Apakah kode tersebut memerlukan akses database? Jika ya, seberapa sering Anda berkunjung? Perhatikan bahwa pengujian ini juga dapat diterapkan pada kode yang menggunakan layanan web atau kendali jarak jauh, namun saya tidak akan membahasnya di artikel ini.
Jika permintaan basis data diperlukan dalam jalur kode tertentu dalam kode Anda, dan Anda menemukan tempat lain di mana Anda ingin memprioritaskan pengoptimalan, seperti manipulasi string, hentikan dan lakukan pengujian penting terlebih dahulu. Kecuali jika Anda memiliki masalah kinerja yang sangat buruk untuk ditangani, waktu Anda akan lebih baik dihabiskan untuk mengoptimalkan waktu yang diperlukan untuk terhubung ke database, jumlah data yang dikembalikan, dan operasi yang Anda lakukan ke dan dari database.
Sekarang saya telah membahas informasi secara umum, mari kita lihat 10 tips untuk membantu aplikasi Anda bekerja lebih baik. Saya akan mulai dengan hal-hal yang memiliki dampak paling nyata terhadap peningkatan kinerja.
Tip 1 - Kembalikan beberapa kumpulan hasil
Lihat kode database Anda untuk melihat apakah Anda memiliki jalur permintaan yang mengakses database lebih dari sekali. Setiap perjalanan bolak-balik mengurangi jumlah permintaan yang dapat dilayani aplikasi Anda per detik. Dengan mengembalikan beberapa kumpulan hasil dalam satu permintaan database, Anda dapat mengurangi keseluruhan waktu yang digunakan oleh komunikasi database. Setelah Anda mengurangi jumlah permintaan yang harus dikelola oleh server database Anda, Anda juga membuat sistem Anda lebih skalabel.
Umumnya Anda dapat menggunakan pernyataan SQL dinamis untuk mengembalikan beberapa rangkaian hasil, saya lebih suka menggunakan prosedur tersimpan. Masih diperdebatkan apakah Anda harus memasukkan logika bisnis ke dalam prosedur tersimpan, tapi menurut saya jika logika dalam prosedur tersimpan dapat membatasi data yang dikembalikan (mengurangi ukuran kumpulan data, waktu yang dihabiskan untuk koneksi jaringan, dan menghilangkan kebutuhan untuk memfilter data lapisan logika), maka itu adalah hal yang baik.
Dengan menggunakan instance SqlCommand dan metode ExecuteReader untuk menghasilkan kelas bisnis yang diketik dengan kuat, Anda dapat memindahkan penunjuk kumpulan hasil ke depan dengan memanggil NextResult. Gambar 1 menunjukkan contoh sesi yang menggunakan kelas yang ditentukan untuk menghasilkan beberapa ArrayList. Mengembalikan hanya data yang Anda butuhkan dari database akan mengurangi permintaan memori di server Anda secara signifikan.
1// baca kumpulan hasil pertama
2pembaca = perintah.ExecuteReader();
3
4// membaca data dari hasil tersebut
5sementara (pembaca.Baca()) {
6 pemasok.Tambahkan(PopulateSupplierFromIDataReader(pembaca));
7}
8
9// baca kumpulan hasil selanjutnya
10pembaca.Hasil Berikutnya();
11
12// membaca data dari hasil kedua itu
13sementara (pembaca.Baca()) {
14 produk.Tambahkan(PopulateProductFromIDataReader(pembaca));
15}
16
17
Tip 2 - Akses data yang diberi nomor halaman
DataGrid ASP.NET memberikan kemampuan luar biasa: dukungan untuk paging data. Saat penomoran halaman diatur di DataGrid, sejumlah hasil tertentu akan ditampilkan pada satu waktu. Selain itu, UI halaman untuk menavigasi antar hasil ditampilkan di bagian bawah DataGrid. UI yang diberi nomor halaman memungkinkan Anda menavigasi maju atau mundur melalui data yang ditampilkan, menampilkan sejumlah hasil tertentu per halaman.
Tapi ada masalah kecil. Saat menggunakan DataGrid untuk paging, semua data harus diikat ke tabel. Misalnya, lapisan data Anda perlu mengembalikan semua data, lalu DataGrid perlu mengisi semua catatan untuk ditampilkan berdasarkan halaman saat ini. Jika 100.000 catatan dikembalikan saat Anda menggunakan penomoran halaman DataGrid, 99.975 catatan akan dibuang per permintaan (dengan asumsi kapasitas setiap halaman adalah 25 catatan). Ketika jumlah rekaman bertambah, kinerja aplikasi sangat terpengaruh karena semakin banyak data yang harus dikembalikan pada setiap permintaan.
Salah satu cara untuk menulis kode penomoran halaman yang lebih baik adalah dengan menggunakan prosedur tersimpan. Gambar 2 menunjukkan contoh prosedur tersimpan yang menampilkan tabel data Pesanan di database Nothwind. Pada dasarnya, yang perlu Anda lakukan di sini hanyalah memasukkan indeks halaman dan kapasitas halaman. Basis data menghitung kumpulan hasil yang sesuai dan mengembalikannya.
1BUAT PROSEDUR northwind_OrdersPaged
2(
3 @PageIndex ke dalam,
4 @Ukuran Halaman ke dalam
5)
6AS
7MULAI
8NYATAKAN @PageLowerBound int
9MENYATAKAN @PageUpperBound int
10NYATAKAN @RowsToReturn int
11
12-- Pertama atur jumlah baris
13SET @RowsToReturn = @PageSize * (@PageIndex + 1)
14SET ROWCOUNT @RowsToReturn
15
16--Tetapkan batas halaman
17SET @PageLowerBound = @PageSize * @PageIndex
18SET @PageUpperBound = @PageLowerBound + @PageSize + 1
19
20-- Buat tabel sementara untuk menyimpan hasil pemilihan
21BUAT TABEL #PageIndex
dua puluh dua(
23 IndexId int IDENTITAS (1, 1) BUKAN NULL,
24 ID Pesanan ke dalam
25)
26
27--Masukkan ke tabel temp
28MASUKKAN KE #PageIndex (ID Pesanan)
29PILIH
30 ID Pesanan
31DARI
32 Pesanan
33PESAN OLEH
34 ID Pesanan DESK
35
36--Jumlah total pengembalian
37PILIH JUMLAH(ID Pesanan) DARI Pesanan
38
39-- Mengembalikan hasil halaman
40PILIH
41 HAI.*
42DARI
43 Perintah HAI,
44 #Indeks HalamanIndeks Halaman
45DIMANA
46 O.OrderID = PageIndex.OrderID DAN
47 PageIndex.IndexID > @PageLowerBound DAN
48 PageIndex.IndexID < @PageUpperBound
49PESAN OLEH
50 HalamanIndeks.IndeksID
51
52 AKHIR
53
54
Selama periode pengabdian masyarakat, kami menulis kontrol server paging untuk melakukan paging data ini. Anda akan melihat bahwa saya menggunakan ide yang dibahas di Tip 1 untuk mengembalikan dua kumpulan hasil dari prosedur tersimpan: jumlah total catatan dan data yang diminta.
Jumlah total rekaman yang dikembalikan dapat bervariasi bergantung pada permintaan yang dilakukan. Misalnya, klausa WHERE dapat digunakan untuk membatasi data yang dikembalikan. Kita harus mengetahui jumlah total rekaman yang akan dikembalikan untuk menghitung jumlah total halaman yang akan ditampilkan di UI yang diberi nomor halaman. Misalnya, jika ada total 1.000.000 rekaman, dan klausa WHERE digunakan untuk memfilter rekaman tersebut menjadi 1.000 rekaman, logika paging perlu mengetahui jumlah total rekaman untuk mengirimkan UI paging dengan tepat.
Tip 3 - Penggabungan koneksi
Membuat koneksi TCP antara aplikasi web Anda dan SQL Server bisa menjadi operasi yang mahal. Pengembang di Microsoft telah memanfaatkan pengumpulan koneksi selama beberapa waktu, memungkinkan mereka menggunakan kembali koneksi ke database. Daripada membuat koneksi TCP baru untuk setiap permintaan, koneksi baru dibuat hanya ketika tidak ada koneksi yang tersedia di kumpulan koneksi. Ketika koneksi ditutup, koneksi dikembalikan ke kumpulan koneksi - koneksi ke database masih dipertahankan, daripada menghancurkan koneksi TCP sepenuhnya.
Tentu saja Anda perlu berhati-hati terhadap koneksi yang bocor. Selalu tutup koneksi Anda setelah Anda selesai menggunakannya. Saya ulangi: tidak peduli apa yang orang katakan tentang mekanisme pengumpulan sampah Microsoft .NET Framework, Anda harus selalu secara eksplisit memanggil metode Tutup atau Buang pada koneksi Anda setelah Anda selesai melakukannya. Jangan percaya Common Language Runtime (CLR) untuk membersihkan dan menutup koneksi Anda pada waktu yang telah ditentukan. CLR pada akhirnya akan menghancurkan kelas dan memaksa koneksi untuk ditutup, tetapi Anda tidak memiliki jaminan kapan mekanisme pengumpulan sampah pada objek tersebut benar-benar akan dijalankan.
Untuk mencapai hasil terbaik menggunakan pengumpulan koneksi, Anda perlu mengikuti beberapa aturan. Pertama, buka koneksi, lakukan pekerjaannya, lalu tutup koneksi. Tidak apa-apa jika Anda harus (sebaiknya menerapkan tip 1) membuka dan menutup koneksi beberapa kali per permintaan, itu jauh lebih baik daripada membiarkan koneksi terbuka dan meneruskannya ke beberapa metode berbeda. Kedua, gunakan string koneksi yang sama (dan tentu saja ID thread yang sama jika Anda menggunakan otentikasi terintegrasi). Jika Anda tidak menggunakan string koneksi yang sama, misalnya string koneksi kustom yang berbeda berdasarkan pengguna yang masuk, Anda tidak akan mendapatkan nilai optimal yang sama dengan yang disediakan oleh kumpulan koneksi. Dan jika Anda menggunakan autentikasi terintegrasi saat meniru identitas pengguna dalam jumlah besar, kumpulan koneksi Anda juga akan menjadi kurang efisien. Penghitung kinerja data .NET CLR dapat berguna ketika mencoba melacak masalah kinerja apa pun yang terkait dengan pengumpulan koneksi.
Setiap kali aplikasi Anda terhubung ke sumber daya, seperti database, atau berjalan di proses lain, Anda harus melakukannya dengan berfokus pada waktu yang diperlukan untuk terhubung ke sumber daya, waktu yang diperlukan untuk mengirim dan menerima data, dan waktu yang diperlukan untuk terhubung ke sumber daya. diperlukan untuk mengirim dan menerima data. Ada sejumlah perjalanan bolak-balik ke database untuk dioptimalkan. Mengoptimalkan segala jenis proses hop dalam aplikasi Anda adalah langkah pertama untuk mulai mencapai kinerja yang lebih baik.
Lapisan aplikasi berisi logika yang terhubung ke lapisan data Anda dan mengubah data menjadi instance kelas dan proses logis yang bermakna. Misalnya, di server komunitas, di sinilah Anda membuat kumpulan forum atau thread dan menerapkan aturan bisnis seperti izin, yang lebih penting, di sinilah logika caching dilakukan.
Tip 4 - API Penyangga ASP.NET
Hal pertama yang perlu dipertimbangkan sebelum Anda mulai menulis baris kode pertama dalam aplikasi Anda adalah merancang lapisan aplikasi untuk memaksimalkan dan memanfaatkan fitur caching ASP.NET.
Jika komponen Anda berjalan dalam aplikasi ASP.NET, Anda cukup mereferensikan System.Web.dll di proyek aplikasi Anda. Saat Anda perlu mengakses cache, gunakan properti HttpRuntime.Cache (objek ini juga dapat diakses melalui Page.Cache dan HttpContext.Cache).
Ada beberapa pedoman untuk menggunakan data cache. Pertama, jika data dapat digunakan berkali-kali, maka cache adalah pilihan yang baik. Kedua, jika data bersifat umum dan tidak spesifik untuk permintaan atau pengguna tertentu, maka menyimpannya dalam cache adalah pilihan yang bagus. Jika data khusus untuk pengguna atau permintaan tetapi memiliki masa pakai yang lama, data tersebut dapat di-cache tetapi mungkin tidak sering digunakan. Ketiga, prinsip yang sering diabaikan adalah terkadang Anda dapat melakukan cache terlalu banyak. Biasanya pada mesin x86, untuk mengurangi kemungkinan kesalahan kehabisan memori, Anda sebaiknya menjalankan proses yang menggunakan byte pribadi tidak lebih dari 800 MB. Oleh karena itu, caching harus dibatasi. Dengan kata lain, Anda mungkin perlu menggunakan kembali hasil satu penghitungan, namun jika penghitungan tersebut memerlukan sepuluh parameter, Anda mungkin perlu mencoba menyimpan 10 permutasi dalam cache, dan hal itu mungkin akan membuat Anda mendapat masalah. Kesalahan kehabisan memori karena overcaching adalah yang paling umum terjadi di ASP.NET, terutama dengan kumpulan data yang besar.
Caching memiliki beberapa fitur hebat yang perlu Anda ketahui. Pertama, cache mengimplementasikan algoritma yang paling baru digunakan, memungkinkan ASP.NET untuk memaksa pengosongan cache—secara otomatis menghapus item yang tidak terpakai dari cache—ketika memori berjalan kurang efisien. Kedua, cache mendukung dependensi kadaluarsa yang bisa dipaksa kedaluwarsa. Ketergantungan ini mencakup waktu, kunci, dan file. Waktu sering digunakan, tetapi dengan ASP.NET 2.0, jenis pembatalan yang baru dan lebih kuat diperkenalkan: pembatalan cache database. Ini mengacu pada penghapusan item dalam cache secara otomatis ketika data dalam database berubah. Untuk informasi lebih lanjut tentang pembatalan cache database, lihat kolom Dino Esposito Cutting Edge di Majalah MSDN edisi Juli 2004. Untuk memahami arsitektur cache, lihat Gambar 3.
Tip 5 — Caching per permintaan
Sebelumnya di artikel ini, saya menyebutkan bahwa perbaikan kecil pada jalur kode yang sering dilalui dapat menghasilkan peningkatan kinerja yang besar secara keseluruhan. Dari perbaikan kecil ini, salah satu yang pasti menjadi favorit saya dan saya menyebutnya caching per permintaan.
API cache dirancang untuk menyimpan data dalam cache dalam jangka waktu yang lebih lama, atau hingga kondisi tertentu terpenuhi, namun cache per permintaan berarti menyimpan data dalam cache hanya selama durasi permintaan tersebut. Untuk setiap permintaan, jalur kode tertentu sering diakses, namun data diekstraksi, diterapkan, dimodifikasi, atau diperbarui hanya sekali. Ini kedengarannya agak teoretis, jadi mari kita berikan contoh konkrit.
Dalam aplikasi forum server komunitas, setiap kontrol server yang digunakan pada halaman memerlukan data personalisasi untuk menentukan tampilan apa yang akan digunakan, tabel gaya apa yang akan digunakan, dan data personalisasi lainnya. Beberapa dari data ini dapat di-cache dalam jangka panjang, namun beberapa data hanya diambil satu kali per permintaan dan kemudian digunakan kembali beberapa kali selama permintaan tersebut, misalnya untuk tampilan kontrol.
Untuk mencapai cache per permintaan, gunakan ASP.NET HttpContext. Untuk setiap permintaan, instance HttpContext dibuat dan dapat diakses dari mana saja dalam properti HttpContext.Current selama permintaan. Kelas HttpContext memiliki properti koleksi Item khusus dan data yang ditambahkan ke koleksi Item ini hanya di-cache selama permintaan. Sama seperti Anda dapat menggunakan caching untuk menyimpan data yang sering diakses, Anda juga dapat menggunakan HttpContext.Items untuk menyimpan data yang hanya digunakan berdasarkan permintaan. Logika di baliknya sangat sederhana: data ditambahkan ke koleksi HttpContext.Items ketika tidak ada, dan dalam pencarian berikutnya, hanya data di HttpContext.Items yang dikembalikan.
Tip 6 — Pemrosesan Latar Belakang
Jalur menuju kode harus secepat mungkin, bukan? Mungkin ada saat ketika Anda menemukan bahwa Anda melakukan tugas yang sangat intensif sumber daya yang dilakukan pada setiap permintaan atau setiap n permintaan. Mengirim email atau menganalisis dan memvalidasi data yang masuk adalah beberapa contohnya.
Saat membedah ASP.NET Forums 1.0 dan merancang ulang konten yang membentuk server komunitas, kami menemukan bahwa jalur kode untuk menerbitkan postingan baru sangat lambat. Setiap kali postingan baru dipublikasikan, aplikasi terlebih dahulu perlu memastikan tidak ada postingan duplikat, kemudian harus menganalisis postingan menggunakan filter "kata-kata buruk", menganalisis emotikon karakter postingan, menandai dan mengindeks postingan, dan menambahkan posting ke permintaan saat diminta. Tambahkan ke antrean yang sesuai, validasi lampiran, dan terakhir kirim pemberitahuan email ke semua pelanggan segera setelah posting dipublikasikan. Jelas, ada banyak hal yang terlibat.
Setelah penelitian, ditemukan bahwa sebagian besar waktu dihabiskan untuk mengindeks logika dan mengirim email. Mengindeks postingan adalah operasi yang sangat memakan waktu dan diketahui bahwa fungsionalitas System.Web.Mail bawaan terhubung ke server SMTP dan kemudian mengirim email secara terus menerus. Ketika jumlah pelanggan untuk postingan atau area topik tertentu meningkat, fungsi AddPost membutuhkan waktu lebih lama untuk dijalankan.
Pengindeksan email tidak diperlukan untuk setiap permintaan. Idealnya, kami ingin mengelompokkan operasi ini, mengindeks 25 postingan sekaligus atau mengirim semua email setiap lima menit. Kami memutuskan untuk menggunakan kode yang saya gunakan untuk membuat prototipe pembatalan cache data yang akhirnya disertakan dalam Visual Studio 2005.
Kelas Timer di namespace System.Threading sangat berguna, tetapi tidak terlalu terkenal di .NET Framework, setidaknya di kalangan pengembang Web. Setelah dibuat, kelas Timer ini akan memanggil callback yang ditentukan pada interval yang dapat dikonfigurasi untuk thread di ThreadPool. Ini berarti Anda dapat mengatur kode Anda untuk dieksekusi tanpa permintaan masuk ke aplikasi ASP.NET, yang ideal untuk pemrosesan latar belakang. Anda juga dapat melakukan operasi seperti mengindeks atau mengirim email dalam proses latar belakang ini.
Namun, ada beberapa masalah dengan teknologi ini. Jika domain aplikasi dicopot pemasangannya, instance pengatur waktu ini akan berhenti mengaktifkan peristiwa. Selain itu, karena CLR mempunyai standar yang ketat untuk jumlah thread per proses, mungkin ada situasi di server dengan beban berat di mana pengatur waktu mungkin tidak menjamin bahwa thread terus menyelesaikan operasi, dan sampai batas tertentu dapat menyebabkan penundaan. . ASP.NET berupaya meminimalkan kemungkinan terjadinya hal ini dengan menjaga sejumlah thread tersedia dalam proses dan hanya menggunakan sebagian dari total thread untuk pemrosesan permintaan. Namun, ini bisa menjadi masalah jika Anda memiliki banyak operasi asinkron.
Tidak ada cukup ruang di sini untuk kode ini, tetapi Anda dapat mengunduh contoh yang mudah dipahami di www.rob-howard.net . Lihatlah slide dan demo dari presentasi Blackbelt TechEd 2004.
Tip 7 — Caching Output Halaman dan Server Proxy
ASP.NET adalah lapisan presentasi Anda (atau seharusnya menjadi lapisan presentasi Anda); terdiri dari halaman, kontrol pengguna, kontrol server (HttpHandlers dan HttpModules), dan konten yang dihasilkannya. Jika Anda memiliki halaman ASP.NET yang menghasilkan keluaran (HTML, XML, gambar, atau data lainnya), dan saat Anda menjalankan kode ini pada setiap permintaan, kode tersebut menghasilkan keluaran yang sama, maka Anda memiliki alat yang dapat digunakan untuk A alternatif yang bagus untuk cache keluaran halaman.
Dengan menambahkan baris berikut ke bagian atas halaman:
<%@ Halaman OutputCache VaryByParams="tidak ada" Durasi="60" %>
Anda dapat secara efektif menghasilkan output untuk halaman ini satu kali dan kemudian menggunakannya kembali beberapa kali hingga 60 detik, pada saat itu halaman akan dieksekusi ulang dan output akan ditambahkan ke cache ASP.NET lagi. Perilaku ini juga dapat dicapai dengan menggunakan beberapa API tingkat rendah yang dapat diprogram. Ada beberapa pengaturan yang dapat dikonfigurasi untuk caching keluaran, seperti properti VaryByParams yang baru saja disebutkan. VaryByParams hanya diminta, tetapi juga memungkinkan Anda menentukan parameter HTTP GET atau HTTP POST untuk mengubah entri cache. Misalnya, cukup atur VaryByParam="Report" ke cache output untuk default.aspx?Report=1 atau default.aspx?Report=2. Parameter tambahan dapat ditentukan dengan menentukan daftar yang dipisahkan titik koma.
Banyak orang tidak menyadari bahwa ketika caching keluaran digunakan, halaman ASP.NET juga menghasilkan header HTTP yang mengalir ke server caching, seperti yang digunakan oleh Microsoft Internet Security and Acceleration Server atau Akamai. Setelah mengatur header tabel cache HTTP, dokumen dapat di-cache pada sumber daya jaringan ini dan permintaan klien dapat dipenuhi tanpa kembali ke server asal.
Oleh karena itu, menggunakan cache keluaran halaman tidak akan membuat aplikasi Anda lebih efisien, namun mungkin mengurangi beban pada server karena teknologi cache hilir menyimpan dokumen dalam cache. Tentu saja, ini hanya dapat berupa konten anonim; setelah diturunkan, Anda tidak akan pernah melihat permintaan tersebut lagi, dan Anda tidak lagi dapat melakukan autentikasi untuk mencegah akses ke konten tersebut.
Tip 8 — Jalankan IIS 6.0 (bahkan hanya untuk menggunakan cache kernel)
Jika Anda tidak menjalankan IIS 6.0 (Windows Server 2003), Anda kehilangan beberapa peningkatan kinerja hebat di server Web Microsoft. Di Tip 7, saya membahas caching keluaran. Di IIS 5.0, permintaan melewati IIS dan kemudian ke ASP.NET. Ketika berbicara tentang caching, HttpModule di ASP.NET menerima permintaan dan mengembalikan konten cache.
Jika Anda menggunakan IIS 6.0, Anda akan menemukan fitur kecil yang menyenangkan yang disebut cache kernel yang tidak memerlukan perubahan kode apa pun pada ASP.NET. Ketika permintaan dibuat untuk cache keluaran oleh ASP.NET, cache kernel IIS menerima salinan data cache. Ketika permintaan datang dari driver jaringan, driver tingkat kernel (tanpa peralihan konteks ke mode pengguna) menerima permintaan tersebut, menghapus data cache ke respons jika di-cache, dan kemudian menyelesaikan eksekusi. Ini berarti ketika Anda menggunakan caching mode kernel dengan caching keluaran IIS dan ASP.NET, Anda akan melihat hasil kinerja yang luar biasa. Selama pengembangan ASP.NET di Visual Studio 2005, saya adalah manajer pengembangan yang bertanggung jawab atas kinerja ASP.NET. Pengembang melakukan pekerjaan spesifik, tetapi saya dapat melihat semua pelaporan yang terjadi setiap hari. Hasil cache mode kernel selalu yang paling menarik. Karakteristik yang paling umum adalah jaringan dibanjiri permintaan/tanggapan, sementara IIS hanya berjalan dengan penggunaan CPU sekitar 5%. Ini mengejutkan! Tentu saja ada alasan lain untuk menggunakan IIS 6.0, tetapi caching mode kernel adalah alasan yang paling jelas.
Tip 9 — Gunakan Kompresi Gzip
Meskipun penggunaan gzip belum tentu merupakan trik kinerja server (karena Anda mungkin melihat peningkatan penggunaan CPU), penggunaan kompresi gzip dapat mengurangi jumlah byte yang dikirim oleh server. Hal ini menghasilkan peningkatan kecepatan halaman dan pengurangan penggunaan bandwidth. Bergantung pada data yang dikirim, seberapa kompresibelnya, dan apakah browser klien mendukungnya (IIS hanya akan mengirimkan konten terkompresi gzip ke klien yang mendukung kompresi gzip, seperti Internet Explorer 6.0 dan Firefox), server Anda dapat melayani Lebih Banyak permintaan. Faktanya, hampir setiap kali Anda mengurangi jumlah data yang dikembalikan, Anda meningkatkan jumlah permintaan per detik.
Kompresi gzip dibangun di IIS 6.0, dan kinerjanya jauh lebih baik daripada kompresi gzip yang digunakan di IIS 5.0, dan ini merupakan kabar baik. Sayangnya, ketika mencoba mengaktifkan kompresi gzip di IIS 6.0, Anda mungkin tidak dapat menemukan pengaturan di dialog Properties IIS. Tim IIS membangun fungsionalitas gzip yang luar biasa ke dalam server, namun lupa menyertakan UI administratif untuk mengaktifkannya. Untuk mengaktifkan kompresi gzip, Anda harus menggali lebih dalam pengaturan konfigurasi XML IIS 6.0 (agar Anda tidak lemah hati). Secara kebetulan, penghargaan diberikan kepada Scott Forsyth dari OrcsWeb karena membantu saya mengangkat masalah ini dengan server www.asp.net yang dihosting di OrcsWeb.
Artikel ini tidak akan menjelaskan langkah-langkahnya. Silakan baca artikel Brad Wilson di Kompresi IIS6. Ada juga artikel basis pengetahuan tentang mengaktifkan kompresi untuk ASPX di Aktifkan Kompresi ASPX di IIS. Namun, Anda harus mencatat bahwa karena beberapa detail implementasi, kompresi dinamis dan caching kernel tidak dapat ada secara bersamaan di IIS 6.0.
Tip 10 — Status Tampilan Kontrol Server
Status tampilan adalah nama menarik untuk ASP.NET yang menyimpan beberapa data status di kolom keluaran tersembunyi pada halaman yang dihasilkan. Ketika halaman dikirim kembali ke server, server dapat mengurai, memvalidasi, dan menerapkan data status tampilan ini kembali ke pohon kontrol halaman. Status tampilan adalah fitur yang sangat canggih karena memungkinkan status dipertahankan pada klien, dan tidak memerlukan cookie atau memori server untuk menyimpan status ini. Banyak kontrol server ASP.NET menggunakan status tampilan untuk mempertahankan pengaturan yang dibuat selama interaksi dengan elemen halaman, seperti menyimpan halaman saat ini yang ditampilkan saat membuat paginasi data.
Namun, penggunaan status tampilan juga memiliki beberapa kelemahan. Pertama, ini meningkatkan beban keseluruhan pada halaman saat disajikan atau diminta. Overhead tambahan juga terjadi ketika membuat serialisasi atau deserialisasi data status tampilan yang dikirim kembali ke server. Terakhir, status tampilan meningkatkan alokasi memori di server.
Beberapa kontrol server memiliki kecenderungan untuk menggunakan status tampilan secara berlebihan meskipun tidak diperlukan, yang paling menonjol adalah DataGrid. Perilaku default properti ViewState aktif, namun Anda dapat menonaktifkannya di tingkat kontrol atau halaman jika Anda tidak memerlukannya. Di dalam kontrol, cukup setel properti EnableViewState ke false, atau setel secara global pada halaman menggunakan pengaturan berikut:
<%@ Halaman EnableViewState="false" %>
Jika Anda tidak memposting kembali halaman tersebut, atau selalu membuat ulang kontrol pada halaman pada setiap permintaan, Anda harus menonaktifkan status tampilan di tingkat halaman.
ringkasan
Saya telah memberi Anda beberapa tip yang menurut saya berguna saat menulis aplikasi ASP.NET berkinerja tinggi. Seperti yang saya sebutkan sebelumnya di artikel ini, ini adalah panduan awal dan bukan kesimpulan akhir tentang kinerja ASP.NET. (Untuk informasi tentang meningkatkan kinerja aplikasi ASP.NET, lihat Meningkatkan Kinerja ASP.NET.) Cara terbaik untuk memecahkan masalah kinerja tertentu hanya dapat ditemukan melalui pengalaman Anda sendiri. Namun, tip berikut akan memberi Anda panduan yang baik dalam perjalanan Anda. Dalam pengembangan perangkat lunak, ada beberapa hal yang mutlak; setiap aplikasi itu unik.
Lihat sidebar "Mitos Kinerja Umum".
Rob Howard adalah pendiri Telligent Systems, yang berspesialisasi dalam aplikasi Web berkinerja tinggi, manajemen basis pengetahuan, dan sistem kolaborasi. Rob sebelumnya bekerja di Microsoft, di mana dia membantu merancang infrastruktur untuk ASP.NET 1.0, 1.1, dan 2.0. Untuk menghubungi Rob, silakan kunjungi [email protected] .
Tautan asli: http://msdn.microsoft.com/msdnmag/issues/05/01/ASPNETPerformance/default.aspx