10 Cara Teratas untuk Meningkatkan Kinerja Aplikasi ASP.Net
Penulis：Eve Cole
Waktu Pembaruan：2009-06-30 15:49:49
Artikel ini membahas:
Mitos umum tentang meningkatkan kinerja aplikasi asp.net Tips berguna untuk meningkatkan kinerja aplikasi asp.net
Rekomendasi pengoperasian database dengan aplikasi Asp.net
Caching dan pemrosesan latar belakang di Asp.net
Saat ini, menulis aplikasi web ASP.NET menjadi sangat sederhana, dan banyak programmer tidak mau menghabiskan waktu untuk membangun aplikasi dengan kinerja yang baik. Artikel ini akan membahas sepuluh cara terbaik untuk meningkatkan kinerja aplikasi web. Saya tidak akan membatasi diskusi saya hanya pada aplikasi ASP.NET karena mereka hanya merupakan bagian dari aplikasi web. Artikel ini juga tidak dapat memberikan panduan lengkap untuk meningkatkan kinerja aplikasi web, karena hal itu memerlukan panjang buku. Artikel ini hanya memberikan titik awal yang baik untuk meningkatkan kinerja aplikasi web. (Satu-satunya yang tersisa adalah belajar sendiri secara perlahan).
Di luar pekerjaan, saya sering melakukan panjat tebing. Sebelum setiap panjat tebing, saya akan meninjau peta jalur panjat tebing dan membaca nasehat para pemanjat tebing sukses sebelumnya. Karena kita membutuhkan pengalaman sukses mereka. Demikian pula, ketika Anda perlu memodifikasi program dengan masalah kinerja atau mengembangkan situs web berkinerja tinggi, Anda juga perlu mempelajari cara menulis aplikasi web berkinerja tinggi.
Pengalaman pribadi saya terutama berasal dari bekerja sebagai manajer program di grup asp.net Microsoft, menjalankan dan mengelola situs web www.asp.net , dan membantu pengembangan Server Komunitas (yang merupakan versi Forum asp.net yang terintegrasi dan ditingkatkan , .Teks, dan perangkat lunak nGallery). Saya rasa pengalaman ini dapat membantu saya.
Anda mungkin berpikir untuk membagi aplikasi Anda menjadi beberapa lapisan logis. Anda mungkin juga pernah mendengar tentang arsitektur fisik tiga tingkat atau arsitektur N-tier, yang merupakan model arsitektur yang paling umum digunakan. Arsitektur ini secara fisik menetapkan fungsi program yang berbeda ke berbagai perangkat keras untuk dieksekusi. Dengan cara ini, jika kita ingin meningkatkan kinerja aplikasi, menambahkan beberapa perangkat keras dapat mencapai tujuan tersebut. Masuk akal jika metode ini dapat meningkatkan kinerja aplikasi, namun sebaiknya kita menghindari penggunaan metode ini. Oleh karena itu, bila memungkinkan, kita harus memasukkan halaman ASP.NET dan komponen yang digunakannya ke dalam sebuah aplikasi.
Karena penerapan terdistribusi dan penggunaan layanan web atau jarak jauh, kinerja aplikasi akan berkurang sebesar 20% atau lebih.
Lapisan datanya sedikit berbeda. Lebih baik menerapkannya secara mandiri dan menggunakan perangkat keras terpisah untuk menjalankannya. Meskipun demikian, database masih menjadi penghambat kinerja aplikasi. Oleh karena itu, ketika Anda ingin mengoptimalkan program Anda, hal pertama yang terlintas dalam pikiran adalah mengoptimalkan lapisan data.
Sebelum Anda memodifikasi area aplikasi Anda yang menyebabkan masalah kinerja, Anda harus memastikan bahwa program yang menyebabkan masalah tersebut terlihat ketat. Profiler kinerja sangat berguna untuk mengetahui di bagian mana aplikasi Anda memerlukan waktu berapa lama. Ini adalah tempat-tempat yang tidak dapat kita rasakan secara intuitif.
Artikel ini membahas dua jenis optimasi kinerja: satu adalah optimasi kinerja besar (optimasi besar), seperti menggunakan Cache asp.net; yang lainnya adalah optimasi kinerja kecil (optimasi kecil). Pengoptimalan kinerja kecil terkadang bisa sangat berguna. Anda membuat perubahan kecil pada kode Anda dan memanggilnya seribu atau sepuluh ribu kali dalam satu waktu. Lakukan pengoptimalan kinerja secara besar-besaran dan Anda akan melihat peningkatan besar dalam kecepatan aplikasi Anda. Pengoptimalan kinerja kecil mungkin hanya meningkatkan satu mikrodetik per permintaan, namun jika jumlah permintaan per hari besar, aplikasi akan mengalami peningkatan kinerja yang signifikan.
Performa lapisan data
Saat Anda ingin mengoptimalkan kinerja suatu aplikasi, Anda dapat bekerja dengan urutan berikut: Apakah kode Anda memerlukan akses database? Jika ya, seberapa sering database harus diakses? Begitu pula dengan metode pengujian ini juga dapat digunakan pada kode program yang menggunakan web service atau remoting. Artikel ini tidak akan membahas masalah optimasi program menggunakan layanan Web dan Remoting.
Jika ada permintaan dalam kode Anda yang harus mengakses database, dan Anda melihat kode yang mengimplementasikan fungsi yang sama di tempat lain, maka Anda perlu mengoptimalkannya terlebih dahulu. Ubah dan tingkatkan serta lanjutkan pengujian. Kecuali Anda memiliki masalah kinerja yang sangat besar, waktu Anda lebih baik dihabiskan untuk mengoptimalkan kueri, menghubungkan ke database, mengembalikan ukuran kumpulan data, dan waktu yang diperlukan untuk mengembalikan kueri.
Berdasarkan ringkasan pengalaman, mari kita lihat sepuluh pengalaman yang dapat membantu Anda meningkatkan kinerja aplikasi Anda. Saya akan menjelaskannya secara berurutan dari yang terbesar hingga yang terkecil dalam hal seberapa besar pengalaman tersebut meningkatkan efisiensi.
1. Kembalikan beberapa kumpulan data
Periksa kode akses database Anda untuk melihat apakah ada permintaan yang dikembalikan beberapa kali. Setiap perjalanan pulang pergi mengurangi jumlah permintaan per detik yang dapat ditanggapi oleh aplikasi Anda. Dengan mengembalikan beberapa kumpulan hasil dalam satu permintaan database, Anda mengurangi waktu yang diperlukan untuk berkomunikasi dengan database, membuat sistem Anda dapat diskalakan, dan mengurangi beban kerja di server database untuk merespons permintaan.
Jika Anda menggunakan pernyataan SQL dinamis untuk mengembalikan beberapa kumpulan data, saya sarankan Anda menggunakan prosedur tersimpan daripada pernyataan SQL dinamis. Apakah akan menulis logika bisnis ke dalam prosedur tersimpan masih agak kontroversial. Namun menurut saya, menulis logika bisnis ke dalam prosedur tersimpan dapat membatasi ukuran kumpulan hasil yang dikembalikan, mengurangi lalu lintas data jaringan, dan menghilangkan kebutuhan untuk memfilter data pada lapisan logika. Ini adalah hal yang baik.
Gunakan metode ExecuteReader dari objek SqlCommand untuk mengembalikan objek bisnis yang diketik dengan kuat, lalu panggil metode NextResult untuk memindahkan penunjuk kumpulan data untuk menemukan kumpulan data. Contoh 1 mendemonstrasikan contoh mengembalikan beberapa objek ArrayList yang diketik dengan kuat. Mengembalikan hanya data yang Anda perlukan dari database dapat sangat mengurangi konsumsi memori server Anda.
2. Menyimpan data
ASP. DataGrid .NET memiliki fitur yang sangat berguna: paging. Jika DataGrid mengizinkan paging, ia hanya akan mengunduh data dari halaman tertentu pada waktu tertentu. Selain itu, ia memiliki bilah navigasi untuk paging data, yang memungkinkan Anda memilih untuk menelusuri halaman tertentu, dan hanya mengunduh satu halaman. data pada suatu waktu.
Namun memiliki kelemahan kecil yaitu harus mengikat semua data ke DataGrid. Dengan kata lain, lapisan data Anda harus mengembalikan semua data, lalu DataGrid memfilter data yang diperlukan oleh halaman saat ini dan menampilkannya. Jika ada kumpulan hasil 10.000 record yang perlu diberi nomor halaman menggunakan DataGrid, dengan asumsi DataGrid hanya menampilkan 25 data per halaman, berarti 9975 data akan dibuang di setiap permintaan. Setiap permintaan harus mengembalikan kumpulan data yang begitu besar, yang berdampak besar pada kinerja aplikasi.
Solusi yang baik adalah dengan menulis prosedur paging tersimpan. Contoh 2 adalah prosedur paging tersimpan untuk tabel pesanan database Northwind. Anda hanya perlu memasukkan nomor halaman saat ini dan jumlah item yang ditampilkan pada setiap halaman, dan prosedur tersimpan akan mengembalikan hasil yang sesuai.
Di sisi server, saya secara khusus menulis kontrol paging untuk menangani paging data. Di sini, saya menggunakan metode pertama dan mengembalikan dua kumpulan hasil dalam prosedur tersimpan: jumlah total catatan data dan kumpulan hasil yang diperlukan.
Jumlah total rekaman yang dikembalikan bergantung pada kueri yang dijalankan; misalnya, kondisi di mana dapat membatasi ukuran kumpulan hasil yang dikembalikan. Karena jumlah total halaman harus dihitung berdasarkan ukuran rekaman kumpulan data di antarmuka paging, jumlah rekaman di kumpulan hasil harus dikembalikan. Misalnya, jika ada total 1.000.000 catatan, jika Anda menggunakan kondisi di mana, Anda dapat memfilter untuk hanya mengembalikan 1.000 catatan. Logika paging dari prosedur tersimpan harus mengetahui untuk mengembalikan data yang perlu ditampilkan.
3. Kumpulan koneksi
Menggunakan TCP untuk menyambungkan aplikasi Anda ke database itu mahal (dan memakan waktu). Pengembang Microsoft dapat menggunakan kumpulan koneksi untuk menggunakan kembali koneksi database. Daripada menggunakan TCP untuk menyambung ke database untuk setiap permintaan, kumpulan koneksi hanya membuat koneksi TCP baru ketika tidak ada koneksi yang valid. Ketika koneksi ditutup, koneksi tersebut akan ditempatkan di pool dan koneksi ke database akan tetap dipertahankan, sehingga mengurangi jumlah koneksi TCP ke database.
Tentu saja, Anda harus memperhatikan koneksi yang lupa Anda tutup. Anda harus segera menutupnya setelah digunakan. Yang ingin saya tekankan adalah: Tidak peduli apa kata orang, GC (pengumpul sampah) dalam kerangka .net akan selalu memanggil metode Tutup atau Buang objek koneksi untuk menutup koneksi Anda secara eksplisit setelah Anda selesai menggunakan objek koneksi. Jangan berharap CLR akan menutup koneksi dalam waktu yang Anda bayangkan. Meskipun CLR pada akhirnya akan menghancurkan objek dan menutup koneksi, kami tidak yakin kapan CLR akan melakukan hal ini.
Untuk menggunakan optimasi kumpulan koneksi, ada dua aturan. Pertama, buka koneksi, proses data, lalu tutup koneksi. Jika Anda harus membuka atau menutup koneksi beberapa kali per permintaan, itu lebih baik daripada membuka koneksi sampingan sepanjang waktu dan meneruskannya ke setiap metode. Kedua, gunakan string koneksi yang sama (atau ID pengguna yang sama, bila Anda menggunakan otentikasi terintegrasi). Jika Anda tidak menggunakan string koneksi yang sama, misalnya jika Anda menggunakan string koneksi berdasarkan pengguna yang masuk, ini tidak akan memanfaatkan fitur pengoptimalan kumpulan koneksi. Jika Anda menggunakan argumen terintegrasi, Anda tidak dapat memanfaatkan sepenuhnya fungsi pengoptimalan kumpulan koneksi karena terdapat banyak pengguna. .NET CLR menyediakan penghitung kinerja data, yang sangat berguna ketika kita perlu melacak karakteristik kinerja program, termasuk pelacakan kumpulan koneksi.
Setiap kali aplikasi Anda terhubung ke sumber daya di komputer lain, seperti database, Anda harus fokus pada mengoptimalkan waktu yang diperlukan untuk terhubung ke sumber daya, waktu yang diperlukan untuk menerima dan mengirim data, dan berapa kali Anda kembali . Mengoptimalkan setiap proses hop dalam aplikasi Anda adalah titik awal untuk meningkatkan kinerja aplikasi Anda.
Lapisan aplikasi berisi logika untuk terhubung ke lapisan data, mentransfer data ke instance kelas yang sesuai, dan pemrosesan bisnis. Misalnya, di Server Komunitas, Anda perlu merakit koleksi Forum atau Thread, lalu menerapkan logika bisnis, seperti otorisasi. Yang lebih penting, Anda perlu menyelesaikan logika caching di sini.
4.ASP. API cache BERSIH
Sebelum menulis aplikasi, hal pertama yang perlu Anda lakukan adalah membuat aplikasi memaksimalkan penggunaan kemampuan caching ASP.NET.
Jika komponen Anda akan dijalankan dalam aplikasi Asp.net, Anda hanya perlu mereferensikan System.Web.dll ke dalam proyek Anda. Kemudian gunakan properti HttpRuntime.Cache untuk mengakses Cache (dapat juga diakses melalui Page.Cache atau HttpContext.Cache).
Ada beberapa aturan untuk menyimpan data dalam cache. Pertama, data mungkin sering digunakan dan data ini dapat di-cache. Kedua, frekuensi akses data sangat tinggi, atau frekuensi akses suatu data tidak tinggi, namun siklus hidupnya sangat panjang. Yang ketiga adalah masalah yang sering diabaikan. Terkadang kita melakukan cache data terlalu banyak. Biasanya pada mesin X86, jika data yang ingin di-cache melebihi 800M maka akan terjadi error memory overflow. Jadi cache-nya terbatas. Dengan kata lain, Anda harus memperkirakan ukuran kumpulan cache dan membatasi ukuran kumpulan cache menjadi kurang dari 10, jika tidak maka dapat menimbulkan masalah. Di Asp.net, jika cache terlalu besar, kesalahan kelebihan memori akan dilaporkan, terutama jika objek DataSet yang besar di-cache.
Berikut adalah beberapa mekanisme caching penting yang harus Anda pahami. Pertama, cache menerapkan prinsip "paling baru digunakan" (algoritma yang paling jarang digunakan). Ketika cache hanya sedikit, maka secara otomatis akan menghapus cache yang tidak berguna. Kedua, prinsip "ketergantungan bersyarat" penghapusan paksa (kedaluwarsa ketergantungan), kondisi dapat berupa waktu, kata kunci dan file. Waktu sebagai suatu kondisi adalah yang paling umum digunakan. Kondisi yang lebih kuat ditambahkan di asp.net2.0, yaitu kondisi database. Ketika data dalam database berubah, cache terpaksa dibersihkan. Untuk melihat lebih mendalam ketergantungan kondisional basis data, lihat kolom Canggih Dino Esposito di Majalah MSDN edisi Juli 2004. Arsitektur cache Asp.net ditunjukkan pada gambar di bawah ini:
5. Cache pra-permintaan
Sebelumnya, saya telah menyebutkan bahwa meskipun kami hanya melakukan sedikit peningkatan kinerja di beberapa tempat, kami bisa mendapatkan peningkatan kinerja yang besar. Saya sangat suka menggunakan cache pra-permintaan untuk meningkatkan kinerja program.
Meskipun Cache API dirancang untuk menyimpan data selama jangka waktu tertentu, cache pra-permintaan hanya menyimpan konten permintaan tertentu untuk jangka waktu tertentu. Jika frekuensi akses permintaan tertentu tinggi, dan permintaan ini hanya perlu mengekstrak, menerapkan, mengubah, atau memperbarui data satu kali. Kemudian permintaan tersebut dapat di-cache sebelumnya. Mari kita beri contoh untuk mengilustrasikannya.
Dalam aplikasi forum CS, kontrol server setiap halaman memerlukan data yang disesuaikan untuk menentukan skinnya, untuk menentukan style sheet mana yang akan digunakan dan hal-hal pribadi lainnya. Beberapa data di sini mungkin perlu disimpan untuk waktu yang lama, namun terkadang tidak. Misalnya, data skin suatu kontrol hanya perlu diterapkan satu kali dan dapat digunakan sepanjang waktu.
Untuk mengimplementasikan cache pra-permintaan, gunakan kelas HttpContext Asp.net. Sebuah instance dari kelas HttpContext dibuat pada setiap permintaan dan dapat diakses melalui properti HttpContext.Current di mana saja selama permintaan. Kelas HttpContext memiliki properti koleksi Item, dan semua objek serta data ditambahkan ke koleksi ini dan disimpan dalam cache selama permintaan. Sama seperti Anda menggunakan Cache untuk menyimpan cache data yang sering diakses, Anda dapat menggunakan HttpContext.Items untuk menyimpan cache data dasar yang digunakan dalam setiap permintaan. Logika di baliknya sederhana: kita menambahkan data ke HttpContext.Items, lalu membaca data darinya.
6. Pemrosesan latar belakang
Dengan cara di atas seharusnya aplikasi Anda berjalan sangat cepat bukan? Namun pada titik tertentu, tugas yang sangat memakan waktu mungkin dilakukan berdasarkan permintaan dalam program. Seperti mengirim email atau mengecek kebenaran data yang dikirimkan, dll.
Saat kami mengintegrasikan asp.net Forums 1.0 ke CS, kami menemukan bahwa pengiriman postingan baru akan sangat lambat. Setiap kali ada postingan baru yang ditambahkan, aplikasi harus memeriksa terlebih dahulu apakah postingan tersebut duplikat, kemudian memfilternya menggunakan filter "badword", memeriksa kode lampiran gambar, mengindeks postingan, dan menambahkannya ke antrian yang sesuai, validasi lampirannya, dan terakhir, kirim email ke kotak surat pelanggannya. Jelas sekali, ini adalah pekerjaan yang banyak.
Hasilnya adalah menghabiskan banyak waktu untuk mengindeks dan mengirim email. Mengindeks postingan adalah operasi yang memakan waktu, dan mengirim email ke pelanggan memerlukan koneksi ke layanan SMTP dan kemudian mengirim email ke setiap pelanggan, seiring bertambahnya jumlah pelanggan, waktu yang dibutuhkan untuk mengirim email akan semakin lama.
Pengindeksan dan pengiriman email tidak perlu dipicu pada setiap permintaan. Idealnya, kami ingin memproses operasi ini secara batch, hanya mengirim 25 email sekaligus atau semua email baru dikirim setiap 5 menit. Kami memutuskan untuk menggunakan kode yang sama dengan cache prototipe database, tetapi gagal, jadi kami harus kembali ke VS.NET 2005.
Kami menemukan kelas Timer di bawah namespace System.Threading Kelas ini sangat berguna, tetapi hanya sedikit orang yang mengetahuinya, dan bahkan lebih sedikit pengembang web yang mengetahuinya. Setelah dia membuat instance kelas ini, kelas Timer akan memanggil fungsi panggilan balik yang ditentukan dari thread di kumpulan thread setiap waktu yang ditentukan. Artinya aplikasi ASP.NET Anda dapat berjalan meskipun tidak ada permintaan. Ini adalah solusi yang harus ditangani nanti. Anda dapat menjalankan pekerjaan pengindeksan dan pengiriman email di latar belakang daripada harus menjalankannya pada setiap permintaan.
Ada dua masalah dengan teknologi yang berjalan di latar belakang. Yang pertama adalah ketika domain aplikasi Anda dihapus, instance kelas Timer akan berhenti berjalan. Artinya, metode panggilan balik tidak akan dipanggil. Selain itu, karena ada banyak thread yang berjalan di setiap proses CLR, akan sulit bagi Anda untuk mendapatkan thread agar Timer dapat mengeksekusinya, atau akan dapat mengeksekusinya, tetapi akan tertunda. Lapisan Asp.net harus menggunakan teknik ini sesedikit mungkin untuk mengurangi jumlah thread dalam proses, atau hanya mengizinkan permintaan untuk menggunakan sebagian kecil thread. Tentu saja, Anda hanya dapat menggunakannya jika Anda memiliki banyak pekerjaan asinkron.
Tidak ada cukup ruang untuk memposting kode di sini. Anda dapat mengunduh contoh program dari http://www.rob-howard.net/ . Silakan unduh contoh program Blackbelt TechEd 2004.
7. Layanan caching dan proxy keluaran halaman
Asp.net adalah lapisan antarmuka Anda (atau seharusnya), berisi halaman, kontrol pengguna, kontrol server (HttpHandlers dan HttpModules) dan konten yang dihasilkannya. Jika Anda memiliki halaman Asp.net yang menampilkan html, xml, imgae, atau data lainnya, dan Anda menggunakan kode untuk menghasilkan konten keluaran yang sama untuk setiap permintaan, Anda perlu mempertimbangkan untuk menggunakan cache keluaran halaman.
Anda dapat melakukan ini hanya dengan menyalin baris kode berikut ke halaman Anda:
<%@ PageOutputCache VaryByParams=”tidak ada” Durasi=”60” %>
Anda dapat secara efektif menggunakan halaman yang dihasilkan dalam permintaan pertama untuk mengeluarkan konten cache, dan membuat ulang konten halaman setelah 60 detik. Teknologi ini sebenarnya diimplementasikan menggunakan beberapa Cache API tingkat rendah. Ada beberapa parameter yang dapat dikonfigurasi untuk cache keluaran halaman, seperti parameter VaryByParams yang disebutkan di atas. Parameter ini menunjukkan kapan harus memicu kondisi keluaran ulang. Anda juga dapat menentukan keluaran cache dalam mode permintaan Http Get atau Http Post. Misalnya, saat kita menyetel parameter ini ke VaryByParams="Report", output yang diminta oleh default.aspx?Report=1 atau default.aspx?Report=2 akan di-cache. Nilai suatu parameter dapat berupa beberapa parameter yang dipisahkan dengan titik koma.
Banyak orang tidak menyadari bahwa saat menggunakan caching keluaran halaman, ASP.NET juga akan menghasilkan kumpulan header HTTP (HTTP Header) dan menyimpannya di server cache hilir kecepatan server. Ketika header cache HTTP direset, konten yang diminta akan di-cache di sumber daya jaringan. Ketika klien meminta konten lagi, klien tidak akan lagi mendapatkan konten dari server asal, tetapi langsung mendapatkan konten dari cache.
Meskipun menggunakan cache keluaran halaman tidak meningkatkan kinerja aplikasi Anda, hal ini mengurangi berapa kali konten halaman cache dimuat dari server. Tentu saja, ini terbatas pada halaman cache yang dapat diakses oleh pengguna anonim. Karena setelah halaman di-cache, operasi otorisasi tidak dapat lagi dilakukan.
8. Gunakan Kernel Caching IIS6.0
Jika aplikasi Anda tidak berjalan di IIS 6.0 (Windows Server 2003), maka Anda kehilangan beberapa cara hebat untuk meningkatkan kinerja aplikasi. Pada metode ketujuh, saya berbicara tentang cara menggunakan cache keluaran halaman untuk meningkatkan kinerja aplikasi. Di IIS5.0, ketika permintaan datang ke IIS, IIS akan mentransfernya ke asp.net Ketika cache keluaran halaman diterapkan, HttpHandler di ASP.NET akan menerima permintaan tersebut, dan HttpHandler akan mentransfer konten dari cache. . Keluarkan dan kembalikan.
Jika Anda menggunakan IIS6.0, ia memiliki fitur yang sangat bagus yang disebut Kernel Caching, dan Anda tidak perlu mengubah kode apa pun di program asp.net. Ketika asp.net menerima permintaan cache, Kernel Cache IIS akan mendapatkan salinannya dari cache. Ketika permintaan datang dari jaringan, lapisan Kernel akan menerima permintaan tersebut. Jika permintaan tersebut di-cache, maka akan langsung mengembalikan data yang di-cache, dan selesai. Ini berarti bahwa ketika Anda menggunakan IIS Kernel Caching untuk menyimpan cache keluaran halaman, Anda akan mendapatkan peningkatan kinerja yang luar biasa. Ketika mengembangkan asp.net untuk VS.NET 2005, saya adalah seorang manajer program yang secara khusus bertanggung jawab atas kinerja asp.net. Pemrogram saya menggunakan metode ini. Saya melihat semua data laporan harian dan menemukan hasil menggunakan cache model kernel tercepat. Ciri umumnya adalah permintaan dan respons jaringan besar, namun IIS hanya memakan 5% sumber daya CPU. Ini luar biasa. Ada banyak alasan bagi Anda untuk menggunakan IIS 6.0, tapi kernel cashing adalah yang terbaik.
9. Kompres data dengan Gzip
Kecuali jika penggunaan CPU Anda terlalu tinggi, Anda perlu menggunakan teknik untuk meningkatkan kinerja server. Menggunakan gzip untuk mengompresi data dapat mengurangi jumlah data yang Anda kirim ke server, meningkatkan kecepatan berjalan halaman, dan juga mengurangi lalu lintas jaringan. Cara mengompres data dengan lebih baik bergantung pada data yang ingin Anda kirim, dan apakah browser klien mendukungnya (IIS mengirimkan data terkompresi gzip ke klien, dan klien harus mendukung gzip untuk menguraikannya, IE6.0 dan Firefox). Dengan cara ini, server Anda dapat merespons lebih banyak permintaan per detik. Demikian pula, Anda juga mengurangi jumlah data yang dikirim sebagai respons, dan Anda dapat mengirim lebih banyak permintaan.
Kabar baiknya, kompresi gzip telah terintegrasi di IIS6.0, lebih baik daripada gzip di IIS5.0. Sayangnya, untuk mengaktifkan kompresi gzip di IIS 6.0, Anda tidak dapat mengaturnya di dialog properti IIS 6.0. Tim pengembangan IIS mengembangkan fungsi kompresi gzip, namun mereka lupa memudahkan administrator untuk mengaktifkannya di jendela administrator. Untuk mengaktifkan kompresi gzip, Anda hanya dapat mengubah konfigurasinya di file konfigurasi xml IIS6.0.
Selain membaca artikel ini, saya harus membaca artikel <<IIS6 Compression>> yang ditulis oleh Brad Wilson ( http://www.dotnetdevs.com/articles/IIS6compression.aspx ); kompresi aspx. Aktifkan Kompresi ASPX di IIS. Namun perlu diketahui bahwa kompresi dinamis dan pencairan kernel bersifat eksklusif di IIS6.
10. ViewState kontrol server
ViewState adalah fitur di asp.net yang digunakan untuk menyimpan nilai status yang digunakan untuk menghasilkan halaman di kolom tersembunyi. Ketika halaman diposkan kembali ke server, server mem-parsing, memverifikasi, dan menerapkan data dalam ViewState untuk memulihkan pohon kontrol halaman. ViewState adalah fitur yang sangat berguna yang dapat mempertahankan status klien tanpa menggunakan cookie atau memori server. Sebagian besar kontrol server menggunakan ViewState untuk mempertahankan nilai status elemen yang berinteraksi dengan pengguna di halaman. Misalnya, untuk menyimpan nomor halaman dari halaman saat ini untuk paging.
Menggunakan ViewState akan membawa beberapa efek negatif. Pertama, ini meningkatkan waktu respons dan permintaan server. Kedua, setiap postback menambah waktu untuk membuat serialisasi dan deserialisasi data. Terakhir, ini juga menghabiskan lebih banyak memori di server.
Banyak kontrol server yang cenderung menggunakan ViewState, seperti DataGrid yang terkenal, dan terkadang tidak perlu menggunakannya. ViewState diaktifkan secara default. Jika Anda tidak ingin menggunakan ViewState, Anda dapat menonaktifkannya di tingkat kontrol atau halaman. Di kontrol, Anda hanya perlu menyetel properti EnableViewState ke False; Anda juga dapat menyetelnya di halaman untuk memperluas cakupannya ke seluruh halaman:
<%@ Halaman EnableViewState=”salah” %>
Jika halaman tidak memerlukan postback atau halaman hanya dirender dengan kontrol setiap kali diminta. Anda harus mematikan ViewState di tingkat halaman.
Meringkaskan
Saya hanya memberikan beberapa tips yang menurut saya akan membantu meningkatkan penulisan aplikasi ASP.NET berkinerja tinggi. Tips untuk meningkatkan kinerja ASP.NET yang disebutkan dalam artikel ini hanyalah titik awal. Buku "Pertunjukan" NET. Hanya melalui latihan Anda sendiri Anda dapat menemukan teknik yang paling berguna untuk proyek Anda. Namun, tips ini dapat menjadi panduan dalam perjalanan pengembangan Anda. Dalam pengembangan perangkat lunak, tidak ada satupun yang benar-benar berguna karena setiap proyek berbeda.
