Pengembang ASP terus berupaya untuk mencapai kinerja dan skalabilitas yang lebih baik dalam proyek desain mereka. Untungnya, ada banyak buku dan situs yang menawarkan nasihat bagus di bidang ini. Namun, saran ini didasarkan pada kesimpulan yang diambil dari struktur kerja platform ASP, dan tidak ada pengukuran kuantitatif terhadap peningkatan kinerja aktual. Karena rekomendasi ini memerlukan pengkodean yang lebih kompleks dan membuat kode kurang mudah dibaca, pengembang harus mempertimbangkan apakah meningkatkan kinerja aplikasi ASP mereka sepadan dengan biayanya tanpa melihat hasil sebenarnya.
Artikel ini dibagi menjadi dua bagian. Saya akan menyajikan beberapa hasil uji kinerja untuk membantu pengembang menentukan apakah inisiatif tertentu bermanfaat tidak hanya untuk proyek masa depan, tetapi juga untuk memperbarui proyek asli. Pada bagian pertama saya akan mengulas beberapa isu dasar pengembangan ASP. Pada bagian kedua, Anda akan membahas pengoptimalan beberapa fungsi ADO dan membandingkan hasilnya dengan halaman ASP yang memanggil objek VB COM untuk menjalankan fungsi ADO yang sama. Hasilnya membuka mata dan terkadang mengejutkan.
Pada artikel ini, kami akan menjawab pertanyaan-pertanyaan berikut:
* Apa cara paling efisien untuk menulis konten yang dihasilkan ASP ke dalam aliran respons?
* Haruskah buffering diaktifkan?
* Haruskah Anda mempertimbangkan untuk menambahkan komentar ke kode ASP Anda?
* Haruskah bahasa default disetel secara eksplisit untuk halaman tersebut?
* Apakah status Sesi harus ditutup jika tidak diperlukan?
* Haruskah logika skrip ditempatkan di subrutin dan area fungsi?
* Apa implikasi penggunaan file penyertaan?
* Beban apa yang dikenakan saat melakukan penanganan kesalahan?
* Apakah menyiapkan pengendali konteks berdampak pada kinerja?
Semua pengujian dilakukan menggunakan Alat Fokus Aplikasi Web Microsoft (WAST), alat gratis yang dapat ditemukan di sini. Saya membuat skrip pengujian sederhana menggunakan WAST yang berulang kali memanggil pengujian halaman ASP yang dijelaskan di bawah (masing-masing lebih dari 70.000 kali). Waktu respons didasarkan pada rata-rata total waktu byte terakhir (TTLB), yaitu waktu sejak permintaan awal hingga saat alat menerima bit data terakhir dari server. Server pengujian kami adalah Pentium 166 dengan RAM 196MB dan kliennya adalah Pentium 450 dengan RAM 256MB. Anda mungkin berpikir bahwa kinerja mesin ini tidak terlalu canggih, tapi jangan lupa, kami tidak menguji kapasitas server, kami hanya menguji waktu yang dibutuhkan server untuk memproses satu halaman dalam satu waktu. Mesin tidak melakukan pekerjaan lain selama pengujian. Skrip pengujian WAST, laporan pengujian, dan semua halaman pengujian ASP disertakan dalam file ZIP untuk Anda tinjau dan uji sendiri.
Apa cara paling efisien untuk menulis konten yang dihasilkan ASP ke dalam aliran respons?
Salah satu alasan terbesar untuk menggunakan ASP adalah untuk menghasilkan konten dinamis di server. Jadi titik awal yang jelas untuk pengujian kami adalah menentukan cara paling tepat untuk mengirimkan konten dinamis ke aliran respons. Di antara banyak pilihan, dua adalah yang paling mendasar: satu adalah dengan menggunakan tag ASP inline, dan yang lainnya adalah dengan menggunakan pernyataan Response.Write.
Untuk menguji opsi ini, kami membuat halaman ASP sederhana di mana kami mendefinisikan beberapa variabel dan kemudian memasukkan nilainya ke dalam tabel. Meskipun halaman ini sederhana dan tidak terlalu praktis, halaman ini memungkinkan kita untuk mengisolasi dan menguji beberapa masalah individual.
Menggunakan tag sebaris ASP
Pengujian pertama melibatkan penggunaan tag ASP sebaris < %= x % >, di mana x adalah variabel yang ditetapkan. Sejauh ini, metode ini adalah yang paling mudah untuk dilakukan, dan menjaga bagian HTML halaman dalam format yang mudah dibaca dan dipelihara.
＜% OPSI EKSPLISIT
Redupkan Nama Depan
RedupNama Belakang
Redupkan Inisial Tengah
Alamat Redup
Kota redup
Keadaan redup
DimPhoneNumber
Redupkan Nomor Faks
Redupkan Email
DimTanggal Lahir
Nama Depan = John
Inisial Tengah = Q
Nama Belakang = Publik
Alamat = 100 Jalan Utama
Kota=New York
Negara Bagian = NY
Nomor Telepon = 1-212-555-1234
Nomor Faks = 1-212-555-1234
Email = [email protected]
Tanggal Lahir = 1/1/1950
%>
＜HTML＞
＜KEPALA＞
＜ JUDUL ＞Tes Respon ＜ / JUDUL ＞
＜ /KEPALA ＞
＜ TUBUH ＞
＜ H1 ＞Uji Respon ＜ /H1 ＞
＜ TABEL ＞
＜ tr ＞＜ td ＞＜ b ＞Nama Depan:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Nama Depan % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Inisial Tengah:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Inisial Tengah % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Nama Belakang:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Nama Belakang % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Alamat:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Alamat % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Kota:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Kota % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Negara Bagian:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Negara Bagian % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Nomor Telepon:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Nomor Telepon % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Nomor Faks:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Nomor Faks % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞EMail:＜ /b ＞＜ /td ＞＜ td ＞＜ %= EMail % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞Tanggal Lahir:＜ /b ＞＜ /td ＞＜ td ＞＜ %= Tanggal Lahir % ＞＜ /td ＞＜ /tr ＞
＜ /TABEL ＞
＜ / TUBUH ＞
＜ /HTML ＞
Kode lengkap /app1/response1.asp
Terbaik sebelumnya (kecepatan respons) = 8,28 mdetik/halaman
Gunakan pernyataan Response.Write pada setiap baris HTML
Banyak dokumen pembelajaran yang lebih baik menyarankan untuk menghindari metode sebelumnya. Alasan utamanya adalah, dalam proses mengeluarkan halaman dan memproses halaman untuk menerapkan latensi, jika server web harus mengkonversi antara pengiriman HTML biasa dan skrip pemrosesan, terjadi masalah yang disebut peralihan konteks. Ketika sebagian besar programmer mendengar ini, reaksi pertama mereka adalah membungkus setiap baris HTML mentah dalam fungsi Response.Write.
…
Respon.Tulis(＜html＞)
Respon.Tulis(＜kepala＞)
Response.Write(＜title＞Tes Respon＜/title＞)
Respon.Tulis(＜/head＞)
Respon.Tulis(＜body＞)
Response.Write(＜h1＞Tes Respon＜/h1＞)
Response.Write(＜tabel＞)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Nama Depan:＜ /b ＞＜ /td ＞＜ td ＞ & Nama Depan & ＜ /td ＞＜ /tr ＞)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Inisial Tengah:＜ /b ＞＜ /td ＞＜ td ＞ & Inisial Tengah & ＜ /td ＞＜ /tr ＞)
… <
Fragmen dari /app1/response2.asp
Terbaik sebelumnya (kecepatan respons) = 8,28 mdetik/halaman
Waktu respons = 8,08 mdetik/halaman
Selisih = -0,20 mdetik (pengurangan 2,4%)
Kita dapat melihat bahwa peningkatan kinerja dari penggunaan pendekatan ini sangat kecil dibandingkan dengan menggunakan markup inline, mungkin karena halaman memuat server dengan sekumpulan pemanggilan fungsi kecil. Kerugian terbesar dari pendekatan ini adalah karena HTML sekarang tertanam dalam skrip, kode skrip menjadi lebih bertele-tele dan sulit dibaca dan dipelihara.
Gunakan fungsi pembungkus
Mungkin penemuan yang paling mengecewakan ketika mencoba menggunakan pendekatan pernyataan Response.Write adalah bahwa fungsi Response.Write tidak dapat menempatkan CRLF di akhir setiap baris. Jadi ketika Anda membaca source code dari browser, HTML yang tadinya ditata dengan sempurna kini menjadi satu baris tanpa akhir. Saya pikir penemuan Anda berikutnya mungkin lebih mengerikan: tidak ada fungsi saudara Writeln di objek Response. Jadi, reaksi yang jelas adalah membuat fungsi pembungkus untuk fungsi Response.Write untuk menambahkan CRLF ke setiap baris.
…
writeCR(＜ tr ＞＜ td ＞＜ b ＞Nama Depan:＜ /b ＞＜ /td ＞＜ td ＞ & Nama Depan & ＜ /td ＞＜ /tr ＞)
…
SUB tulisCR(str)
Respon.Tulis(str & vbCRLF)
SUB AKHIR
Fragmen dari /app1/response4.asp
Terbaik sebelumnya (kecepatan respons) = 8,08 mdetik/halaman
Waktu respons = 10,11 mdetik/halaman
Selisih = +2,03 mdetik (peningkatan 25,1%)
Tentu saja, karena pendekatan ini secara efektif melipatgandakan jumlah pemanggilan fungsi, dampaknya terhadap kinerja menjadi signifikan dan harus dihindari dengan cara apa pun. Ironisnya CRLF juga menambahkan 2 byte per baris ke aliran reaktif, yang tidak perlu dirender oleh browser ke halaman. Semua yang dilakukan HTML yang diformat dengan baik adalah memudahkan pesaing Anda membaca kode sumber HTML dan memahami desain Anda.
Gabungkan Respons berturut-turut. Tulis menjadi satu pernyataan
Terlepas dari pengujian kami sebelumnya dengan fungsi wrapper, langkah logis berikutnya adalah mengekstrak semua string dari pernyataan Response.Write yang terpisah dan menggabungkannya menjadi satu pernyataan, sehingga mengurangi jumlah pemanggilan fungsi, sehingga sangat meningkatkan kinerja halaman.
…
Respon.Tulis(＜html＞&_
＜ kepala ＞ & _
＜judul＞Tes Respon＜/judul＞ & _
＜ /kepala ＞ & _
＜tubuh＞ & _
＜ h1 ＞Uji Respon＜ /h1 ＞ & _
＜ tabel ＞ & _
＜ tr ＞＜ td ＞＜ b ＞Nama Depan:＜ /b ＞＜ /td ＞＜ td ＞ & Nama Depan & ＜ /td ＞＜ /tr ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞Tanggal Lahir:＜ /b ＞＜ /td ＞＜ td ＞ & Tanggal Lahir & ＜ /td ＞＜ /tr ＞ & _
＜ /tabel ＞ & _
＜ /badan ＞ & _
＜ /html ＞)
Fragmen dari /app1/response3.asp
Terbaik sebelumnya (kecepatan respons) = 8,08 mdetik/halaman
Waktu respons = 7,05 mdetik/halaman
Selisih = -1,03 mdetik (pengurangan 12,7%)
Saat ini, ini adalah konfigurasi yang paling optimal.
Gabungkan Response yang berurutan. Tulis menjadi satu pernyataan, tambahkan CRLF di akhir setiap baris
Sebagai pertimbangan bagi mereka yang membutuhkan kode sumbernya agar terlihat asli dari browser, saya menggunakan konstanta vbCRLF untuk memasukkan beberapa carriage return di akhir setiap baris pada pengujian sebelumnya dan memutarnya kembali.
…
Respon.Tulis(＜html＞&vbCRLF&_
＜ kepala ＞ & vbCRLF & _
＜ title ＞Tes Respon＜ /title ＞ & vbCRLF & _
＜ /kepala ＞ & vbCRLF & _
…
Fragmen /app1/response5.asp
Terbaik sebelumnya (kecepatan respons) = 7,05 mdetik/halaman
Waktu respons = 7,63 mdetik/halaman
Selisih = +0,58 mdetik (peningkatan 8,5%)
Hasilnya adalah sedikit penurunan performa, mungkin karena penggabungan ekstra dan peningkatan jumlah karakter.
Review dan Observasi
Beberapa aturan dapat diambil dari pengujian sebelumnya pada keluaran ASP:
* Hindari penggunaan ASP inline yang berlebihan.
* Selalu gabungkan pernyataan Response.Write berturut-turut menjadi satu pernyataan.
* Jangan pernah menggunakan fungsi pembungkus di sekitar Response.Write untuk menambahkan CRLF.
* Jika output HTML harus diformat, tambahkan CRLF langsung dalam pernyataan Response.Write.
Haruskah buffering diaktifkan?
Mulai buffer melalui skrip
Dengan menyertakan Response.Buffer=True di bagian atas skrip ASP, IIS akan menyimpan konten halaman dalam cache.
＜% OPSI EKSPLISIT
Respon.Buffer = benar
Redupkan Nama Depan
…
Fragmen /app1/buffer__1.asp
Terbaik sebelumnya (waktu respons) = 7,05 mdetik/halaman
Waktu respons = 6,08 mdetik/halaman
Selisih = -0,97 mdetik (pengurangan 13,7%)
Kinerja telah meningkat pesat. Tapi tunggu, ada sesuatu yang lebih baik.
Mulai buffer melalui konfigurasi server
Meskipun buffer diaktifkan secara default di IIS 5.0, buffer harus diaktifkan secara manual di IIS 4.0. Sekarang temukan kotak dialog Properti situs dan pilih tombol Konfigurasi dari tab Direktori Beranda. Kemudian pilih aktifkan buffering di bawah Opsi aplikasi. Untuk pengujian ini, pernyataan Response.Buffer dipindahkan dari skrip.
Terbaik sebelumnya = 7,05 mdetik/halaman
Waktu respons = 5,57 mdetik/halaman
Selisih = -1,48 mdetik (pengurangan 21,0%)
Saat ini, ini adalah respons tercepat yang pernah kami dapatkan, 21% lebih rendah dibandingkan waktu respons terbaik kami sebelumnya. Mulai sekarang, pengujian kami selanjutnya akan menggunakan waktu reaksi ini sebagai nilai dasar.
Review dan Observasi
Buffer adalah cara terbaik untuk meningkatkan kinerja, jadi pengaturan buffer ke nilai default server diperlukan. Jika karena alasan tertentu halaman tidak dapat menjalankan buffer dengan benar, gunakan saja perintah Response.Buffer=False. Salah satu kelemahan buffer adalah pengguna tidak melihat apa pun dari server hingga seluruh halaman telah diproses. Oleh karena itu, selama pemrosesan halaman yang kompleks, sebaiknya sesekali memanggil Response.Flush untuk memperbarui pengguna.
Sekarang kami memiliki satu aturan lagi yang ditambahkan: selalu aktifkan buffering melalui pengaturan server.
Haruskah Anda mempertimbangkan untuk menambahkan komentar ke kode ASP Anda?
Sebagian besar pengembang HTML tahu bahwa menyertakan komentar HTML adalah ide yang buruk, pertama, hal itu akan meningkatkan ukuran data yang ditransfer, dan kedua, mereka hanya memberikan informasi kepada pengembang lain tentang organisasi halaman Anda. Tapi bagaimana dengan komentar di halaman ASP? Mereka tidak pernah meninggalkan server, tapi mereka meningkatkan ukuran halaman, sehingga mereka harus dipecah menggunakan ASP.
Dalam pengujian ini, kami menambahkan 20 komentar, masing-masing berisi 80 karakter, sehingga totalnya menjadi 1.600 karakter.
＜% OPSI EKSPLISIT
'------------------------------------------------ - ---------------------------------
…20 baris…
'------------------------------------------------ - ---------------------------------
Redupkan Nama Depan
…
/app2/comment_1.asp fragmen
Garis dasar = 5,57 mdetik/halaman
Waktu respons = 5,58 mdetik/halaman
Selisih = +0,01 mdetik (peningkatan 0,1%)
Hasil tesnya sungguh mencengangkan. Meskipun panjang komentar hampir dua kali lipat dari file itu sendiri, kehadirannya tidak berdampak besar pada waktu respons. Jadi kita bisa mengikuti aturan berikut:
Selama digunakan secara moderat, anotasi ASP memiliki dampak kecil atau tidak sama sekali terhadap kinerja.
Haruskah bahasa default disetel secara eksplisit untuk halaman tersebut?
IIS menangani VBScript secara default, tapi saya melihat bahwa dalam kebanyakan kasus bahasa secara eksplisit diatur ke VBScript menggunakan pernyataan <%@LANGUAGE=VBSCRIPT%>. Pengujian kami berikutnya akan menguji dampak kehadiran deklarasi ini terhadap kinerja.
＜ %@ BAHASA=VBSCRIPT % ＞
＜% OPSI EKSPLISIT
Redupkan Nama Depan
…
/app2/bahasa1.asp fragmen.
Garis dasar = 5,57 mdetik/halaman
Waktu respons = 5,64 mdetik/halaman
Selisih = +0,07 mdetik (peningkatan 1,2%)
Seperti yang Anda lihat, menyertakan deklarasi bahasa memiliki sedikit dampak pada performa. Karena itu:
* Atur konfigurasi bahasa default server agar sesuai dengan bahasa yang digunakan di situs.
* Jangan menyetel deklarasi bahasa kecuali Anda menggunakan bahasa non-default.
Haruskah status Sesi dimatikan jika tidak diperlukan?
Ada banyak alasan untuk menghindari penggunaan konteks Sesi IIS, dan itu bisa menjadi artikel mereka sendiri. Pertanyaan yang kami coba jawab sekarang adalah apakah menutup konteks Sesi ketika tidak diperlukan oleh halaman akan membantu meningkatkan kinerja. Secara teoritis, seharusnya ya, karena tidak perlu menggunakan halaman tersebut untuk membuat contoh konteks Sesi.
Seperti buffer, ada dua cara untuk mengonfigurasi status sesi: melalui skrip dan melalui pengaturan server.
Tutup konteks Sesi melalui skrip
Untuk pengujian ini, untuk menutup konteks Sesi di halaman, saya menambahkan deklarasi status Sesi.
＜ %@ ENABLESESSIONSTATE = SALAH % ＞
＜% OPSI EKSPLISIT
Redupkan Nama Depan
…
/app2/session_1.asp fragmen.
Garis dasar = 5,57 mdetik/halaman
Waktu respons = 5,46 mdetik/halaman
Selisih = -0,11 mdetik (penurunan 2,0%)
Kemajuan yang baik telah dicapai melalui upaya kecil ini. Sekarang lihat bagian kedua.
Tutup konteks Sesi melalui konfigurasi server
Untuk menutup konteks Sesi di server, buka kotak dialog Properti situs. Pilih tombol Konfigurasi pada tab Direktori Beranda. Kemudian hapus centang aktifkan status sesi di bawah Opsi aplikasi. Kami menjalankan pengujian tanpa pernyataan ENABLESESSIONSTATE.
Garis dasar = 5,57 mdetik/halaman
Waktu respons = 5,14 mdetik/halaman
Selisih = -0,43 mdetik (pengurangan 7,7%)
Ini merupakan peningkatan kinerja yang signifikan. Oleh karena itu, aturan kita harusnya: selalu tutup status Sesi di tingkat halaman atau aplikasi bila tidak diperlukan.
Apakah penggunaan Option Explicit akan mengubah kinerja secara substansial?
Setel Opsi Eksplisit di bagian atas halaman ASP untuk mengharuskan semua variabel dideklarasikan pada halaman sebelum digunakan. Ada dua alasan untuk ini. Pertama, aplikasi dapat memproses akses variabel lebih cepat. Kedua, ini mencegah kita menggunakan nama variabel secara tidak sengaja. Dalam pengujian ini kami menghapus referensi Option Explicit dan deklarasi variabel Dim.
Garis dasar = 5,57 mdetik/halaman
Waktu respons = 6,12 mdetik/halaman
Selisih = +0,55 mdetik (peningkatan 9,8%),
Meskipun beberapa baris kode telah dihapus dari halaman, waktu respons masih meningkat. Jadi meskipun penggunaan Option eksplisit terkadang memakan waktu, hal ini memiliki pengaruh yang signifikan terhadap kinerja. Jadi kita bisa menambahkan aturan lain: selalu gunakan Option eksplisit di VBScript.
Haruskah logika skrip ditempatkan di subrutin dan area fungsi?
Menggunakan fungsi dan subrutin adalah cara yang baik untuk mengatur dan mengelola kode, terutama ketika area kode digunakan beberapa kali pada halaman. Kerugiannya adalah ia menambahkan pemanggilan fungsi tambahan ke sistem yang melakukan pekerjaan yang sama. Masalah lain dengan subrutin dan fungsi adalah cakupan variabel. Secara teori, lebih efisien untuk menentukan variabel dalam suatu area fungsi. Sekarang mari kita lihat bagaimana kedua aspek ini berperan.
Pindahkan pernyataan Response.Write ke dalam subrutin
Tes ini hanya memindahkan pernyataan Response.Write ke area subrutin.
…
PANGGILAN tulisTabel()
SUB tulisTabel()
Respon.Tulis(＜html＞&_
＜ kepala ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞EMail:＜ /b ＞＜ /td ＞＜ td ＞ & EMail & ＜ /td ＞＜ /tr ＞ & _
＜ tr ＞＜ td ＞＜ b ＞Tanggal Lahir:＜ /b ＞＜ /td ＞＜ td ＞ & Tanggal Lahir & ＜ /td ＞＜ /tr ＞ & _
＜ /tabel ＞ & _
＜ /badan ＞ & _
＜ /html ＞)
SUB AKHIR
/app2/function1.asp fragmen
Garis dasar = 5,57 mdetik/halaman
Waktu respons = 6,02 mdetik/halaman
Selisih = +0,45 mdetik (peningkatan 8,1%)
Seperti yang diharapkan, panggilan subrutin menempatkan overhead tambahan pada halaman.
Pindahkan semua skrip ke dalam subrutin
Dalam pengujian ini, pernyataan Response.write dan deklarasi variabel dipindahkan ke area subrutin.
＜% OPSI EKSPLISIT
PANGGILAN tulisTabel()
SUB tulisTabel()
Redupkan Nama Depan
…
DimTanggal Lahir
Nama Depan = John
…
Tanggal Lahir = 1/1/1950
Respon.Tulis(＜html＞&_
＜ kepala ＞ & _
＜judul＞Tes Respon＜/judul＞ & _
＜ /kepala ＞ & _
＜tubuh＞ & _
＜ h1 ＞Uji Respon＜ /h1 ＞ & _
＜ tabel ＞ & _
＜ tr ＞＜ td ＞＜ b ＞Nama Depan:＜ /b ＞＜ /td ＞＜ td ＞ & Nama Depan & ＜ /td ＞＜ /tr ＞ & _
…
＜ tr ＞＜ td ＞＜ b ＞Tanggal Lahir:＜ /b ＞＜ /td ＞＜ td ＞ & Tanggal Lahir & ＜ /td ＞＜ /tr ＞ & _
＜ /tabel ＞ & _
＜ /badan ＞ & _
＜ /html ＞)
SUB AKHIR
/app2/function2.asp fragmen
Garis dasar = 5,57 mdetik/halaman
Waktu respons = 5,22 mdetik/halaman
Selisih = -0,35 mdetik (pengurangan 6,3%)
Sangat menarik! Meskipun memindahkan variabel ke dalam cakupan fungsi menambahkan pemanggilan fungsi tambahan, hal ini sebenarnya meningkatkan kinerja. Kita dapat menambahkan aturan berikut:
* Pada suatu halaman, jika kode akan digunakan lebih dari sekali, sertakan kode tersebut dalam area fungsi.
* Bila perlu, pindahkan deklarasi variabel ke dalam lingkup fungsi.
Apa implikasi penggunaan file penyertaan?
Fitur penting dari pemrograman ASP adalah penyertaan kode dari halaman lain. Dengan fitur ini, pemrogram dapat berbagi fungsi di beberapa halaman, sehingga membuat kode lebih mudah dikelola. Kerugiannya adalah server harus merakit halaman dari berbagai sumber. Di bawah ini adalah dua pengujian menggunakan Sertakan file.
Sertakan file menggunakan kode sebaris
Dalam pengujian ini, sebagian kecil kode telah dipindahkan ke dalam file Sertakan:
＜% OPSI EKSPLISIT
Redupkan Nama Depan
…
DimTanggal Lahir
Nama Depan = John
…
Tanggal Lahir = 1/1/1950
%>
＜ !-- #sertakan file=inc1.asp -- ＞
/app2/include_1.asp fragmen
Garis dasar = 5,57 mdetik/halaman
Waktu respons = 5,93 mdetik/halaman
Selisih = +0,36 mdetik (peningkatan 6,5%)
Hal ini tidak mengherankan. Payload dibentuk menggunakan Sertakan file.
Gunakan Sertakan file di area fungsi
Di sini, kode dibungkus dalam subrutin dalam file Sertakan. Referensi Sertakan dibuat di bagian atas halaman dan memanggil subrutin di lokasi yang sesuai dalam skrip ASP.
＜% OPSI EKSPLISIT
Redupkan Nama Depan
…
DimTanggal Lahir
Nama Depan = John
…
Tanggal Lahir = 1/1/1950
PANGGILAN tulisTabel()
%>
＜ !-- #sertakan file=inc2.asp -- ＞
/app2/include_2.asp fragmen
Garis dasar = 5,57 mdetik/halaman
Waktu respons = 6,08 mdetik/halaman
Selisih=+0,51 mdetik (peningkatan 9,2%)
Hal ini memiliki dampak yang lebih besar terhadap kinerja dibandingkan pemanggilan fungsi. Jadi: Gunakan Sertakan file hanya ketika kode dibagikan antar halaman.
Berapa banyak beban yang tercipta saat melakukan penanganan kesalahan?
Penanganan kesalahan diperlukan untuk semua aplikasi nyata. Dalam pengujian ini, pengendali kesalahan dipanggil dengan memanggil fungsi On Error Resume Next.
＜% OPSI EKSPLISIT
Pada Kesalahan Lanjutkan Berikutnya
Redupkan Nama Depan
…
/app2/error_1.asp fragmen
Garis dasar = 5,57 mdetik/halaman
Waktu respons = 5,67 mdetik/halaman
Selisih = 0,10 mdetik (peningkatan 1,8%)
Seperti yang Anda lihat, penanganan kesalahan ada harganya. Kami dapat menyarankan hal berikut: Gunakan penanganan kesalahan hanya ketika sesuatu terjadi di luar kemampuan Anda untuk menguji atau mengendalikan. Contoh dasarnya adalah menggunakan objek COM untuk mengakses sumber daya lain, seperti objek ADO atau FileSystem.
Apakah menyiapkan pengendali konteks mempunyai dampak terhadap kinerja?
Ketika kesalahan terjadi, pengaturan pengendali konteks pada halaman memungkinkan skrip untuk membalikkan tindakan tersebut. Ini diatur menggunakan pernyataan pemrosesan di halaman.
＜ %@ TRANSAKSI = WAJIB % ＞
＜% OPSI EKSPLISIT
Redupkan Nama Depan
…
/app2/transact1.asp fragmen
Garis dasar = 5,57 mdetik/halaman
Waktu respons = 13,39 mdetik/halaman
Selisih = +7,82 mdetik (peningkatan 140,4%)
Ah! Ini benar-benar hasil yang paling dramatis. Jadi harap perhatikan aturan berikut: Gunakan konteks pemrosesan hanya ketika dua atau lebih operasi dilakukan sebagai satu unit.
sebagai kesimpulan
Yang penting dari bagian pertama artikel ini adalah akumulasi dari banyak hal kecil. Untuk menyoroti masalah ini, saya menyiapkan pengujian terakhir di mana saya melakukan semua hal yang telah kami uji sebelumnya yang tampaknya tidak berbahaya namun sebenarnya berdampak buruk. Saya menyertakan sekumpulan pernyataan Response.Write, mematikan buffer, mengatur bahasa default, menghapus referensi Option Explicit, dan menginisialisasi penangan kesalahan.
＜ %@ BAHASA=VBSCRIPT % ＞
< %
Pada Kesalahan Lanjutkan Berikutnya
Nama Depan = John
…
Tanggal Lahir = 1/1/1950
Respon.Tulis(＜html＞)
Respon.Tulis(＜kepala＞)
Response.Write(＜title＞Tes Respon＜/title＞)
Respon.Tulis(＜/head＞)
Respon.Tulis(＜body＞)
Response.Write(＜h1＞Tes Respon＜/h1＞)
Response.Write(＜tabel＞)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Nama Depan:＜ /b ＞＜ /td ＞＜ td ＞ &_
Nama Depan & ＜ /td ＞＜ /tr ＞)
…
Response.Write(＜ tr ＞＜ td ＞＜ b ＞Tanggal Lahir:＜ /b ＞＜ /td ＞＜ td ＞ &_
Tanggal Lahir & ＜ /td ＞＜ /tr ＞)
Respon.Tulis(＜/tabel＞)
Respon.Tulis(＜/body＞)
Respon.Tulis(＜/html＞)
%>
/app2/final_1.asp fragmen
Garis dasar = 5,57 mdetik/halaman
Waktu respons = 8,85 mdetik/halaman
Selisih = +3,28 mdetik (peningkatan 58,9%)
Ini mungkin terdengar jelas, namun yang lebih penting adalah memahami bahwa kode yang kita tempatkan pada halaman berdampak pada kinerja. Perubahan kecil pada halaman terkadang dapat meningkatkan waktu respons secara signifikan.
Ringkasan aturan
* Hindari penggunaan ASP inline yang berlebihan.
* Selalu gabungkan pernyataan Response.Write berturut-turut menjadi satu pernyataan.
* Jangan pernah menggunakan fungsi pembungkus di sekitar Response.Write untuk menambahkan CRLF.
* Jika output HTML harus diformat, tambahkan CRLF langsung dalam pernyataan Response.Write.
* Selalu aktifkan buffering melalui pengaturan server.
* Selama digunakan secara moderat, anotasi ASP memiliki dampak kecil atau tidak sama sekali terhadap kinerja.
* Atur konfigurasi bahasa default server agar sesuai dengan bahasa yang digunakan di situs.
* Jangan menyetel deklarasi bahasa kecuali Anda menggunakan bahasa non-default.
* Selalu gunakan Opsi eksplisit di VBScript.
* Selalu matikan status Sesi di tingkat halaman atau aplikasi bila tidak diperlukan.
* Gunakan Sertakan file hanya ketika kode dibagikan antar halaman.
* Pada suatu halaman, jika kode akan digunakan lebih dari sekali, sertakan kode tersebut dalam area fungsi.
* Bila perlu, pindahkan deklarasi variabel ke dalam lingkup fungsi.
* Gunakan penanganan kesalahan hanya jika terjadi kondisi yang berada di luar kemampuan pengujian atau kontrol.
* Gunakan pemrosesan konteks hanya ketika dua atau lebih operasi dilakukan sebagai satu unit.
Melihat ke belakang sekarang, ada sejumlah pertanyaan yang dapat menjadi pedoman umum:
* Hindari redundansi--jangan setel properti yang sudah disetel secara default.
* Batasi jumlah pemanggilan fungsi.
* Kurangi cakupan kode.