Siapa pun yang telah menulis ASP yang sedikit lebih besar tahu bahwa sesi sangat berguna. Tapi apakah Anda benar -benar tahu bagaimana sesi bekerja? Mungkin setelah Anda mengerti, Anda tidak akan pernah berani menggunakan objek cinta-benci ini lagi. Meskipun metode perubahan menjadi alternatif agak merepotkan, setelah pertimbangan jangka panjang, saya harus melakukannya.
Pertama, mari kita bicara tentang manfaat sesi, yang dapat digunakan untuk merekam variabel data yang dimiliki secara pribadi oleh klien dan tidak akan hilang dalam rentang waktu. Ini benar -benar fungsi yang penting, terutama yang harus digunakan oleh sistem dengan anggota. Misalnya, akun login anggota, waktu, status, dan banyak data real-time yang direkam (seperti sistem belanja mencatat produk di keranjang belanja pengguna), informasi ini adalah kebutuhan pribadi setiap pengguna, dan biasanya pengembang digunakan pengembang itu.
Namun, sesi dalam ASP terdiri dari cookie, dan server mengirimkan semua informasi yang dicatat dalam sesi ke browser pengguna dalam bentuk cookie. Biasanya, browser akan menyimpan cookie ini. Ini adalah prinsip operasi sesi. Konfigurasikan kembali memori, dll. Tindakan awal. Sekarang Anda mungkin berpikir, "Saya harus menggunakan fungsi ini, jadi saya harus berkorban sedikit." Kursus ada alternatif.
Aplikasi juga bagus dalam merekam dan memproses data sementara. Aplikasi tidak seperti sesi, yang tidak meneruskan data kepada pengguna dan menunggu waktu berikutnya untuk membacanya kembali secara online.
Karena objek aplikasi bersifat publik, hal pertama yang harus dilakukan adalah merencanakan area umum untuk setiap pengguna, sehingga setiap pengguna memiliki area sendiri untuk merekam data untuk mencapai tujuan sesi simulasi. Ada dua cara untuk melakukannya sekarang:
1. Inisialisasi dan alokasikan ruang memori pengguna terlebih dahulu saat server diaktifkan. . Namun, ada batasan. Menggunakan metode ini harus membatasi jumlah maksimum orang. Program kecil seperti ruang obrolan.
2. Metode ini harus dianggap lebih tepat untuk aplikasi besar. Tujuan dari dua solusi sesi yang disimulasikan ini adalah untuk mengurangi konsumsi sumber daya sesi, tetapi bagaimanapun juga, itu masih tak tergantikan.
■ Rencana pertama
Pertama, kami memulai implementasi solusi pertama.
Inisialisasi telah selesai, tetapi bagaimana menggunakannya? Kami hanya perlu mengubah informasi yang disimpan dalam sesi, seperti akun dan waktu login, ke dalam objek aplikasi yang telah kami buat, di mana pengguna masuk:
| 'Mencari ruang yang tidak digunakan Untuk i = 1 ke aplikasi (clientmax) Jika aplikasi (user_status_ & i) = 0 lalu Nomor sementara pengguna Sesi (indeks) = i 'Mengunci Aplikasi Aplikasi.lock 'Diatur ke keadaan bekas Aplikasi (user_status_ & i) = 1 'dimasukkan ke dalam data variabel Aplikasi (user_account_ & i) = akun Aplikasi (user_logtime_ & i) = sekarang () 'Tidak dikunci Application.unlock Keluar untuk Akhiri jika Berikutnya |
Untuk mendapatkan data variabel yang relevan pengguna, itu seperti berikut:
| Response.write (aplikasi (user_account_ & session (index)) |
Anda mungkin menemukan bahwa Anda tidak bermaksud tidak menggunakan sesi? Lalu mengapa sesi ada dalam kode asli di atas? Seperti yang disebutkan sebelumnya, alternatif ini tidak dapat sepenuhnya menggantikan sesi. Pada saat ini, kami harus mengandalkan sesi. Anda memiliki kunci, dan kuncinya ada angka di atasnya, dan angka pada kunci memungkinkan pelatih untuk membawa Anda ke brankas Anda sendiri. Metode ini memiliki beberapa perbaikan, tetapi cukup untuk aplikasi kecil.
■ Rencana Kedua
Mengenai solusi sebelumnya, Anda juga dapat berpikir bahwa nomor yang disesuaikan kami menggunakan sesi untuk merekam. Itu benar, tidak peduli apakah kami ingin menggunakannya atau tidak, server akan secara otomatis membantu setiap pengguna menetapkan nomor, dan nomor ini tidak akan diulangi. Penomoran ini adalah tindakan yang pasti akan dilakukan sesi, sehingga kami dapat menggunakannya untuk mengganti program penomoran yang kami tulis sendiri, yang menghemat upaya lain dan bahkan memiliki ekspansi yang lebih besar. Tetapi pada dasarnya, solusi pertama di atas masih berguna, seperti ruang obrolan yang membatasi jumlah orang dan aplikasi kecil lainnya.
Jika situs web dengan ratusan, ribuan atau bahkan puluhan ribu orang di situs web setiap detik, itu pasti tidak akan berfungsi jika menggunakan solusi sebelumnya. Misalkan Anda menetapkan batas atas 10.000 orang, setelah server diaktifkan, itu akan membantu Anda memotong 10.000 area untuk mempersiapkan 10.000 pengguna. Ini hanya menyumbang lebih dari 320.000 K (320MB). Setelah server diaktifkan, itu akan memasukkan begitu banyak sampah ke dalam memori. Beberapa, saya pikir 512MB Anda sendiri akan cukup. Oleh karena itu, solusinya adalah mengonfigurasi ruang variabel pengguna secara dinamis, dan memotong area saat pengguna online dengan server, sehingga tidak perlu mengkonfigurasi memori yang sangat besar sebelumnya.
Solusi kedua relatif mudah dilakukan.
| 'Lock ApplicationApplication.lock' Letakkan data variabel Aplikasi (user_account_ & session.SessionId) = akun Aplikasi (user_logtime_ & session.SessionId) = now () 'Buka kunci buka kunci aplikasi.unlock |
Untuk mendapatkan data variabel yang relevan pengguna, itu seperti berikut:
| Response.write (aplikasi (user_account_ & session.SessionId)) |
Di masa lalu, saya membaca banyak buku yang mengatakan sesi sangat sulit untuk dimakan sumber daya, jadi cobalah untuk tidak menggunakannya, tetapi saya masih harus menggunakannya ketika mereka harus melakukannya, dan buku -buku itu tidak mengajarkan solusi yang lebih tepat. Sekarang ketika Anda memahami cara mengganti sesi, memanfaatkannya dengan baik! Mungkin masalah efisiensi yang selalu bermasalah dapat ditingkatkan banyak!