Sungguh menakjubkan betapa mudahnya menulis aplikasi Web menggunakan ASP.NET. Karena kesederhanaan ini, banyak pengembang tidak meluangkan waktu untuk menyusun aplikasi mereka agar kinerjanya lebih baik. Pada artikel ini, saya akan membahas 10 tips untuk menulis aplikasi Web berkinerja tinggi. Tapi saya tidak akan membatasi saran ini untuk aplikasi ASP.NET, karena aplikasi ini hanya bagian dari aplikasi Web. Artikel ini tidak dimaksudkan sebagai panduan pasti untuk menyempurnakan kinerja aplikasi web—seluruh buku tidak dapat dengan mudah membahas subjek ini. Anggap artikel ini sebagai titik awal yang bagus.
Sebelum saya menjadi workaholic, saya suka panjat tebing. Sebelum melakukan pendakian besar, saya memulai dengan melihat dengan cermat rute di buku panduan dan membaca rekomendasi dari pengunjung sebelumnya. Namun betapapun bagusnya panduan ini, Anda memerlukan pengalaman panjat tebing yang sesungguhnya sebelum mencoba pendakian yang sangat 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 Manajer Program Infrastruktur di divisi ASP.NET di Microsoft, di mana saya menjalankan dan mengelola www.ASP.NET dan membantu merancang server komunitas, salah satu dari beberapa server komunitas yang terkenal.
Aplikasi ASP.NET (ASP.NET Forums, .Text dan nGallery digabungkan menjadi satu platform). Saya yakin beberapa tips yang membantu saya akan membantu Anda juga.
Anda harus mempertimbangkan untuk membagi aplikasi Anda menjadi beberapa lapisan logis. Anda mungkin pernah mendengar istilah arsitektur fisik 3-tier (atau n-tier). Ini biasanya merupakan pendekatan arsitektur yang ditentukan secara fisik memisahkan fungsionalitas antara proses dan/atau perangkat keras. Ketika sistem perlu diperluas, lebih banyak perangkat keras dapat ditambahkan dengan mudah. Namun, ada penurunan kinerja yang terkait dengan lompatan proses dan mesin, dan harus dihindari. Jadi, jika memungkinkan, coba jalankan halaman ASP.NET dan komponen terkaitnya secara bersamaan dalam aplikasi yang sama.
Karena pemisahan kode dan batasan antar lapisan, penggunaan layanan Web atau jarak jauh akan menurunkan 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 lapisan data adalah masalah pertama yang harus Anda pertimbangkan saat mengoptimalkan kode.
Sebelum mendalami perbaikan kinerja aplikasi Anda, pertama-tama pastikan Anda membuat profil aplikasi Anda untuk mengidentifikasi masalah spesifiknya. Penghitung kinerja utama, seperti yang mewakili persentase waktu yang diperlukan untuk melakukan pengumpulan sampah, juga berguna untuk mengetahui di mana aplikasi menghabiskan waktu utamanya. Namun di mana waktu yang dihabiskan sering kali sangat tidak intuitif.
Artikel ini menjelaskan dua jenis peningkatan kinerja: pengoptimalan besar (seperti menggunakan cache ASP.NET), dan pengoptimalan kecil yang berulang. Pengoptimalan kecil ini terkadang sangat menarik. Anda membuat sedikit perubahan pada kode Anda dan Anda mendapatkan banyak waktu. Dengan pengoptimalan yang besar, Anda mungkin melihat lompatan besar dalam performa keseluruhan. Dengan pengoptimalan kecil, Anda mungkin hanya menghemat beberapa milidetik untuk permintaan tertentu, namun jika ditambahkan ke semua permintaan setiap hari, ini bisa menjadi peningkatan yang besar.
Performa Lapisan Data
Dalam hal penyetelan performa aplikasi, ada tes dipstick yang dapat Anda gunakan untuk memprioritaskan pekerjaan Anda: Apakah kode mengakses database? Jika ya, pada frekuensi berapa? Perhatikan bahwa pengujian yang sama juga dapat diterapkan pada kode yang menggunakan layanan Web atau jarak jauh, namun artikel ini tidak membahasnya.
Jika permintaan database diperlukan dalam jalur kode tertentu dan Anda merasa perlu mengoptimalkan area lain terlebih dahulu (seperti manipulasi string), hentikan lalu lakukan pengujian dipstick ini. Jika masalah kinerja Anda tidak parah, ada baiknya meluangkan waktu untuk mengoptimalkan waktu yang dihabiskan relatif terhadap database, jumlah data yang dikembalikan, dan frekuensi perjalanan bolak-balik ke dan dari database.
Dengan mengingat informasi umum ini, mari kita lihat sepuluh tips yang dapat membantu meningkatkan kinerja aplikasi. Pertama, saya akan membahas tentang perubahan yang mungkin dapat membuat perbedaan terbesar.
Tip 1 — Mengembalikan Beberapa Kumpulan Hasil
Perhatikan baik-baik kode database Anda untuk melihat apakah ada beberapa jalur permintaan ke dalam database. Setiap perjalanan bolak-balik mengurangi jumlah permintaan per detik yang dapat dilayani oleh aplikasi. Dengan mengembalikan beberapa kumpulan hasil dalam satu permintaan database, Anda dapat menghemat keseluruhan waktu yang diperlukan untuk berkomunikasi dengan database. Pada saat yang sama, hal ini juga membuat sistem lebih terukur dengan mengurangi pekerjaan server database dalam mengelola permintaan.
Meskipun dimungkinkan untuk menggunakan SQL dinamis untuk mengembalikan beberapa rangkaian hasil, metode pilihan saya adalah menggunakan prosedur tersimpan. Ada beberapa perdebatan mengenai apakah logika bisnis harus berada dalam prosedur tersimpan, tapi menurut saya akan lebih baik jika logika dalam prosedur tersimpan dapat membatasi data yang dikembalikan (mengurangi ukuran kumpulan data, mengurangi waktu yang dihabiskan untuk jaringan, tidak harus menyaring data lapisan logika), ini harus diutamakan.
Saat mengisi kelas bisnis yang sangat diketik menggunakan instance SqlCommand dan metode ExecuteReader, Anda dapat memindahkan penunjuk rangkaian hasil ke depan dengan memanggil NextResult. Gambar 1 menunjukkan contoh sesi menggunakan kelas tipe untuk mengisi beberapa ArrayList. Mengembalikan hanya data yang Anda perlukan dari database akan semakin mengurangi alokasi memori di server.
Gambar 1 Mengekstrak Beberapa Hasil dari DataReader
// membaca hasil pertama
reader = command.ExecuteReader();
// membaca data dari hasil tersebut
while (pembaca.Baca()) {
pemasok.Tambahkan(PopulateSupplierFromIDataReader(pembaca));
}
// membaca hasil berikutnya
reader.NextResult();
// membaca data dari hasil kedua tersebut
while (pembaca.Baca()) {
produk.Tambahkan(PopulateProductFromIDataReader( pembaca ));
}
Tip 2 - Akses Data Paginasi
ASP.NET DataGrid memiliki fitur bagus: dukungan penomoran halaman data. Saat paging diaktifkan di DataGrid, sejumlah rekaman tetap ditampilkan pada satu waktu. Selain itu, UI paging ditampilkan di bagian bawah DataGrid untuk memfasilitasi navigasi antar catatan. UI paging memungkinkan Anda menavigasi maju dan mundur melalui data yang ditampilkan dan menampilkan sejumlah rekaman tetap pada satu waktu.
Ada juga perubahan kecil. Paginasi menggunakan DataGrid mengharuskan semua data terikat ke grid. Misalnya, jika lapisan data Anda perlu mengembalikan semua data, DataGrid akan memfilter semua rekaman yang ditampilkan berdasarkan halaman saat ini. Jika 100.000 catatan dikembalikan saat paging melalui DataGrid, 99.975 catatan dibuang untuk setiap permintaan (dengan asumsi ukuran halaman 25 catatan). Ketika jumlah record bertambah, kinerja aplikasi menurun karena semakin banyak data yang harus dikirim pada setiap permintaan.
Cara terbaik untuk menulis kode penomoran halaman yang berkinerja lebih baik adalah dengan menggunakan prosedur tersimpan. Gambar 2 menunjukkan contoh prosedur tersimpan untuk membuat halaman tabel Pesanan di database Northwind. Singkatnya, yang harus Anda lakukan saat ini adalah meneruskan indeks halaman dan ukuran halaman. Kumpulan hasil yang sesuai kemudian dihitung dan dikembalikan.
Gambar 2 Paging Melalui Tabel Pesanan
BUAT PROSEDUR northwind_OrdersPaged
(
@PageIndex ke dalam,
@PageSize ke dalam
)
SEBAGAI
MULAI
DEKLARASIKAN @PageLowerBound int
DEKLARASIKAN @PageUpperBound int
DECLARE @RowsToReturn int
-- Pertama atur jumlah baris
SET @RowsToReturn = @PageSize * (@PageIndex + 1)
SET ROWCOUNT @RowsToReturn
-- Tetapkan batas halaman
SET @PageLowerBound = @PageSize * @PageIndex
SET @PageUpperBound = @PageLowerBound + @PageSize + 1
-- Buat tabel sementara untuk menyimpan hasil pemilihan
BUAT TABEL #PageIndex
(
IndexId int IDENTITAS (1, 1) BUKAN NULL,
ID Pesanan ke dalam
)
-- Masukkan ke dalam tabel temp
MASUKKAN KE #PageIndex (ID Pesanan)
MEMILIH
ID Pesanan
DARI
Pesanan
PESAN OLEH
OrderID DESC
-- Jumlah total pengembalian
SELECT COUNT(OrderID) FROM Orders
-- Menampilkan hasil halaman
MEMILIH
HAI.*
DARI
Pesanan HAI,
#Indeks HalamanIndeks Halaman
DI MANA
O.OrderID = PageIndex.OrderID DAN
PageIndex.IndexID > @PageLowerBound DAN
PageIndex.IndexID < @PageUpperBound
PESAN OLEH
PageIndex.IndexID
END
Di server komunitas, kami menulis kontrol server paging untuk menyelesaikan semua paging data. Seperti yang akan Anda lihat, saya menggunakan konsep 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 mungkin berbeda-beda bergantung pada kueri yang dijalankan. Misalnya, klausa WHERE dapat digunakan untuk membatasi data yang dikembalikan. Untuk menghitung jumlah total halaman yang ditampilkan di UI yang diberi nomor halaman, Anda harus mengetahui jumlah total data yang akan dikembalikan. Misalnya, jika ada total 1.000.000 data, dan Anda ingin menggunakan klausa WHERE untuk memfilternya menjadi 1.000 data, logika paging perlu mengetahui jumlah total data agar dapat merender UI paging dengan benar.
Tip 3 — Pengumpulan Koneksi
Menyiapkan koneksi TCP antara aplikasi Web dan SQL Server bisa menjadi operasi yang sangat intensif sumber daya. Pengembang di Microsoft telah dapat menggunakan pengumpulan koneksi selama beberapa waktu sekarang, yang memungkinkan mereka menggunakan kembali koneksi database. Daripada menyiapkan koneksi TCP baru untuk setiap permintaan, mereka hanya menyiapkan koneksi baru ketika tidak ada koneksi di kumpulan koneksi. Ketika koneksi ditutup, ia kembali ke kumpulan koneksi tempat ia memelihara koneksi ke database daripada menghancurkan koneksi TCP seluruhnya.
Tentu saja, Anda perlu berhati-hati jika terjadi kebocoran sambungan. Ketika Anda selesai menggunakan koneksi Anda, pastikan untuk menutupnya. Untuk mengulangi: Apa pun yang dikatakan orang tentang pengumpulan sampah di Microsoft® .NET Framework, pastikan untuk secara eksplisit memanggil Tutup atau Buang pada koneksi setelah Anda selesai menggunakannya. Jangan percaya runtime bahasa umum (CLR) untuk menghapus dan menutup koneksi untuk Anda pada waktu yang telah ditentukan. Meskipun CLR pada akhirnya akan menghancurkan kelas dan memaksa koneksi ditutup, tidak ada jaminan kapan pengumpulan sampah pada objek benar-benar terjadi.
Untuk menggunakan pengumpulan koneksi secara optimal, ada beberapa aturan yang perlu diikuti. Pertama buka koneksi, lakukan operasi, lalu tutup koneksi. Jika harus, buka dan tutup koneksi beberapa kali per permintaan (sebaiknya terapkan tip 1), namun jangan biarkan koneksi tetap terbuka sepanjang waktu dan sebarkan masuk dan keluar menggunakan berbagai metode berbeda. Kedua, gunakan string koneksi yang sama (dan ID thread yang sama jika menggunakan otentikasi terintegrasi). Jika Anda tidak menggunakan string koneksi yang sama, misalnya menyesuaikan string koneksi berdasarkan pengguna yang masuk, maka Anda tidak akan mendapatkan nilai pengoptimalan yang sama dengan yang disediakan oleh kumpulan koneksi. Jika Anda menggunakan autentikasi terintegrasi dan juga meniru sejumlah besar pengguna, efisiensi kumpulan koneksi juga akan menurun secara signifikan. 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 yang berjalan di proses lain, Anda harus mengoptimalkan dengan berfokus pada waktu yang diperlukan untuk terhubung ke sumber daya tersebut, waktu yang diperlukan untuk mengirim atau mengambil data, dan jumlah perjalanan bolak-balik. Mengoptimalkan segala jenis proses hopping dalam aplikasi Anda adalah poin pertama untuk mendapatkan kinerja yang lebih baik.
Lapisan aplikasi berisi logika untuk terhubung ke lapisan data dan mengubah data menjadi instance kelas dan proses bisnis yang bermakna. Misalnya, server komunitas, tempat Anda ingin mengisi koleksi Forum atau Thread, menerapkan aturan bisnis (seperti izin), dan yang paling penting, melakukan logika cache di sana.
Tip 4 — API Caching ASP.NET
Sebelum menulis baris kode aplikasi, salah satu hal pertama yang harus dilakukan adalah menyusun lapisan aplikasi untuk memanfaatkan kemampuan caching ASP.NET secara maksimal.
Jika komponen Anda ingin dijalankan dalam aplikasi ASP.NET, Anda hanya perlu menyertakan referensi ke System.Web.dll dalam proyek aplikasi. Saat Anda perlu mengakses cache, gunakan properti HttpRuntime.Cache (objek ini juga dapat diakses melalui Page.Cache dan HttpContext.Cache).
Ada beberapa aturan untuk menyimpan data dalam cache. Pertama, jika data kemungkinan akan digunakan berkali-kali, ini merupakan alternatif yang baik dibandingkan menggunakan caching. Kedua, jika data bersifat umum dan tidak spesifik untuk permintaan atau pengguna tertentu, ini juga merupakan kandidat yang baik untuk melakukan cache. Jika data spesifik untuk pengguna atau permintaan, namun memiliki masa pakai yang lama, data tersebut masih dapat disimpan dalam cache, namun hal ini mungkin tidak terlalu sering digunakan. Ketiga, aturan yang sering diabaikan adalah terkadang Anda dapat melakukan cache terlalu banyak. Biasanya pada komputer x86, untuk mengurangi kemungkinan kesalahan kehabisan memori, Anda sebaiknya menjalankan proses dengan byte pribadi tidak lebih dari 800 MB. Oleh karena itu cache harus memiliki batas. Dengan kata lain, Anda mungkin dapat menggunakan kembali hasil penghitungan, namun jika penghitungan tersebut memerlukan 10 parameter, Anda mungkin mencoba menyimpan 10 permutasi dalam cache, yang mungkin akan menimbulkan masalah bagi Anda. Salah satu permintaan paling umum untuk dukungan ASP.NET adalah kesalahan kehabisan memori yang disebabkan oleh cache yang berlebihan, terutama untuk 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 pembersihan 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 Juli 2004. Untuk memahami arsitektur cache, lihat diagram di bawah ini.
 |
Tip 6 — Pemrosesan Latar Belakang
Jalur menuju kode harus secepat mungkin, bukan? Mungkin ada saatnya Anda merasa bahwa tugas yang dilakukan pada setiap permintaan atau sekali setiap n permintaan memerlukan banyak sumber daya. 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 penambahan jalur kode postingan baru sangat lambat. Setiap kali postingan baru ditambahkan, pertama-tama aplikasi harus memastikan bahwa tidak ada postingan duplikat, kemudian harus menganalisis postingan tersebut menggunakan filter "kata-kata buruk", menganalisis emotikon karakter yang diposting, menandai dan mengindeks postingan tersebut, dan menambahkan posting bila diminta Buka antrian yang sesuai, validasi lampiran, dan setelah posting terakhir, segera kirim pemberitahuan email ke semua pelanggan. 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 ditemukan bahwa fungsionalitas System.Web.Mail bawaan terhubung ke server SMYP 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 melakukan operasi ini secara batch, mengindeks 25 postingan sekaligus atau mengirim semua email setiap lima menit. Kami memutuskan untuk menggunakan kode yang sebelumnya kami gunakan untuk membuat prototipe pembatalan cache data yang digunakan untuk apa yang berakhir di 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 kejadiannya. Selain itu, karena CLR memiliki standar yang ketat untuk jumlah thread per proses, mungkin ada situasi di mana server memiliki beban berat sehingga pengatur waktu mungkin tidak memiliki thread untuk diselesaikan, sampai batas tertentu akan 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 dapat dibaca 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.
Tambahkan baris konten ini ke bagian atas halaman <%@ Page OutputCache VaryByParams="none" Duration="60" %>
Anda dapat secara efisien 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 terprogram tingkat rendah. 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 mengetahui bahwa ketika caching keluaran digunakan, halaman ASP.NET juga menghasilkan beberapa header HTTP yang terletak di bagian hilir server caching, seperti yang digunakan oleh Microsoft Internet Security and Acceleration Server atau Akamai. Setelah mengatur header 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 dapat mengurangi beban pada server karena teknologi cache hilir menyimpan dokumen dalam cache. Tentu saja, ini mungkin hanya 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 (gunakan saja untuk caching 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 program 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, berapa banyak data yang dapat dikompresi, dan apakah browser klien mendukungnya (IIS hanya akan mengirimkan konten yang dikompresi 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 diposkan 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 keseluruhan muatan pada halaman setiap kali disajikan atau diminta. Overhead tambahan juga terjadi ketika membuat serialisasi atau deserialisasi data status tampilan yang diposting 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 terkenal 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 AktifkanViewState="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.
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.