ใครก็ตามที่เขียน ASP ที่ใหญ่กว่าเล็กน้อยจะรู้ดีว่า Session object นั้นใช้งานง่ายมาก สามารถใช้บันทึกตัวแปรข้อมูลส่วนตัวของผู้ใช้ได้ ซึ่งทั้งปลอดภัยและสะดวก แต่คุณรู้หรือไม่ว่า Session ทำงานอย่างไร? ใครก็ตามที่เขียน ASP ที่ใหญ่กว่าเล็กน้อยจะรู้ดีว่า Session object นั้นใช้งานง่ายมาก สามารถใช้บันทึกตัวแปรข้อมูลส่วนตัวของผู้ใช้ได้ ซึ่งทั้งปลอดภัยและสะดวก แต่คุณรู้หรือไม่ว่า Session ทำงานอย่างไร? บางทีหลังจากเข้าใจแล้ว คุณจะไม่กล้าใช้วัตถุอันเป็นที่รักและเกลียดนี้อีกต่อไป แม้ว่าวิธีการอื่นจะยุ่งยากเล็กน้อย แต่หลังจากพิจารณามาเป็นเวลานานแล้วก็ต้องทำ
ก่อนอื่นเรามาพูดถึงประโยชน์ของ Session กันก่อน สามารถใช้เพื่อบันทึกตัวแปรข้อมูลส่วนตัวของลูกค้าและจะไม่หายไปภายในช่วงเวลา นี่เป็นฟังก์ชันที่สำคัญจริงๆ โดยเฉพาะอย่างยิ่งสำหรับระบบที่มีสมาชิกที่ต้องใช้ เช่นบัญชีเข้าสู่ระบบของสมาชิก เวลา สถานะ และข้อมูลเรียลไทม์จำนวนมากที่ควรบันทึกไว้ (เช่น ระบบการซื้อของที่บันทึกรายการในตะกร้าสินค้าของผู้ใช้) ข้อมูลนี้เป็นที่ต้องการส่วนตัวของผู้ใช้แต่ละรายและโดยปกติแล้วนักพัฒนาจะใช้ . การประมวลผลบันทึกเซสชัน
อย่างไรก็ตาม เซสชันใน ASP ประกอบด้วยคุกกี้ และเซิร์ฟเวอร์จะส่งข้อมูลทั้งหมดที่บันทึกไว้ในเซสชันไปยังเบราว์เซอร์ของผู้ใช้ในรูปแบบของคุกกี้ โดยปกติแล้วเบราว์เซอร์ทั่วไปจะจัดเก็บคุกกี้เหล่านี้ เมื่อใดก็ตามที่ผู้ใช้คลิกลิงก์และเชื่อมต่อกับเซิร์ฟเวอร์อีกครั้ง เบราว์เซอร์จะส่งคุกกี้เหล่านี้กลับไปยังเซิร์ฟเวอร์เพื่อประมวลผล นี่คือหลักการทำงานของ Session เมื่อปริมาณข้อมูลเพิ่มมากขึ้นเนื่องจากต้องส่งออกและนำกลับ ไม่เพียงแต่กินแบนด์วิธของบรรทัดเท่านั้น แต่ยังลดประสิทธิภาพลงด้วย เนื่องจากเซิร์ฟเวอร์ต้องใช้ทรัพยากรมากขึ้นในการประมวลผลและกำหนดค่าออนไลน์ใหม่ หน่วยความจำ การดำเนินการเริ่มต้น ตอนนี้คุณอาจกำลังคิดว่า "ฉันต้องใช้ฟังก์ชันนี้ ดังนั้นฉันจึงต้องเสียสละมัน" อย่างไรก็ตาม บทความนี้พูดถึงเซสชัน ในทางกลับกัน จะสอนให้คุณใช้มันน้อยลง มีทางเลือกอื่น สิ่งต่อไปที่ปรากฏขึ้นก็คือมันเป็นของ Global.asa Application object
แอปพลิเคชันยังสามารถบันทึกและประมวลผลข้อมูลชั่วคราวได้ดี ความสามารถและการใช้งานเหมือนกับเซสชันในทุกด้าน อย่างไรก็ตาม เมื่อเปรียบเทียบแล้ว ข้อมูลที่บันทึกจะเป็นแบบสาธารณะ นั่นคือ พื้นที่ตัวแปรที่ผู้ใช้ทุกคนสามารถแชร์ได้ ต่างจากเซสชัน แอปพลิเคชันจะไม่ถ่ายโอนข้อมูลไปยังผู้ใช้และรอให้การเชื่อมต่อครั้งถัดไปอ่านกลับ ซึ่งจะถูกบันทึกโดยตรงในหน่วยความจำบนเซิร์ฟเวอร์ ในการเปรียบเทียบ ประสิทธิภาพจะเร็วกว่าเซสชันมาก
เนื่องจากออบเจ็กต์ Application เป็นแบบสาธารณะ สิ่งแรกที่ต้องทำคือการวางแผนพื้นที่ส่วนกลางสำหรับผู้ใช้แต่ละคน เพื่อให้ผู้ใช้แต่ละคนมีพื้นที่ของตนเองในการบันทึกข้อมูล เพื่อให้บรรลุวัตถุประสงค์ในการจำลองเซสชัน มีสองแนวทางในขณะนี้:
1. เริ่มต้น สร้าง และจัดสรรพื้นที่หน่วยความจำของผู้ใช้ล่วงหน้าเมื่อเปิดใช้งานเซิร์ฟเวอร์ โดยปกติแล้ว แม้ว่าวิธีนี้จะใช้ทรัพยากรจำนวนมากทันทีที่เซิร์ฟเวอร์เริ่มทำงาน แต่ก็ช่วยประหยัดปัญหาในการจัดสรรทุกครั้งที่ผู้ใช้ กำลังออนไลน์อยู่ในอนาคต แต่มีข้อจำกัด วิธีนี้ต้องจำกัดจำนวนคนสูงสุด เนื่องจากจะถูกเตรียมใช้งานทันทีที่เปิดใช้งาน เราจึงสามารถประมาณการสร้างพื้นที่หน่วยความจำได้เพียงจำนวนหนึ่งเท่านั้น ดังนั้น วิธีนี้จึงมักใช้ในโปรแกรมขนาดเล็ก เช่น ห้องสนทนา
2. วิธีการนี้ควรได้รับการพิจารณาว่าเหมาะสมกว่าสำหรับแอปพลิเคชันขนาดใหญ่ โดยใช้วิธีการจัดสรรแบบไดนามิกและเริ่มจัดสรรทรัพยากรให้กับผู้ใช้เมื่อผู้ใช้เชื่อมต่อกับเซิร์ฟเวอร์เป็นครั้งแรก วัตถุประสงค์ของการจำลองเซสชันทั้งสองวิธีนี้คือเพื่อลดการใช้ทรัพยากรของเซสชัน แต่ท้ายที่สุดแล้ว เราไม่สามารถแทนที่ได้ทั้งหมด เรายังต้องใช้เซสชันเพียงเล็กน้อย ซึ่งอย่างน้อยก็ช่วยลดภาระได้มาก เซิร์ฟเวอร์
ตัวเลือกแรก
ก่อนอื่นเราเริ่มต้นการใช้งานโซลูชันแรก เนื่องจากแอปพลิเคชันเริ่มต้นระหว่างการเปิดใช้งาน แน่นอนว่าเราต้องเริ่มจาก Global.asa:
การเริ่มต้นเสร็จสมบูรณ์ แต่จะใช้งานได้อย่างไร? เราจำเป็นต้องเปลี่ยนข้อมูลที่จัดเก็บไว้แต่เดิมโดยใช้เซสชัน เช่น หมายเลขบัญชีและเวลาเข้าสู่ระบบ ลงในออบเจ็กต์แอปพลิเคชันที่เราสร้างขึ้นโดยที่ผู้ใช้เข้าสู่ระบบ:
คัดลอกรหัสรหัสดังต่อไปนี้:
'มองหาพื้นที่ที่ไม่ได้ใช้
สำหรับ i = 1 ถึงแอปพลิเคชัน (ClientMax)
ถ้า Application(User_Status_ & i) = 0 แล้ว
'หมายเลขชั่วคราวของผู้ใช้
เซสชั่น(ดัชนี) = i
'ล็อค
แอปพลิเคชัน แอปพลิเคชันล็อค
'ตั้งค่าเป็นสถานะที่ใช้'
แอปพลิเคชัน (User_Status_ & i) = 1 'ใส่ข้อมูลตัวแปร
แอปพลิเคชัน (User_Account_ & i) = บัญชี
แอปพลิเคชัน (User_Logtime_ & i) = ตอนนี้ ()
'ปลดล็อค
แอปพลิเคชั่นปลดล็อค
ออกเพื่อ
สิ้นสุดถ้า
ต่อไป
หากต้องการรับข้อมูลตัวแปรที่เกี่ยวข้องกับผู้ใช้ ให้ทำดังต่อไปนี้:
Response.Write (แอปพลิเคชัน (User_Account_ & เซสชัน (ดัชนี))
คุณอาจพบว่าไม่ได้บอกว่าไม่ให้ใช้ Session ใช่ไหม แล้วทำไม Session ถึงยังคงอยู่ในซอร์สโค้ดข้างต้น? ดังที่กล่าวไว้ก่อนหน้านี้ ทางเลือกนี้ไม่สามารถแทนที่เซสชันได้อย่างสมบูรณ์ เบราว์เซอร์ไม่ได้ออนไลน์เสมอไปกับเซิร์ฟเวอร์ มันจะถูกตัดการเชื่อมต่อหลังจากอ่านเพจ แล้วเราจะรู้ได้อย่างไรว่าบุคคลเดียวกันนั้นเชื่อมต่ออยู่ในครั้งถัดไป ในเวลานี้เราจะต้องพึ่งพา Session เราให้ชุดตัวเลขแบบเรียลไทม์แก่ผู้ใช้ ตัวเลขนี้คือจำนวนพื้นที่ตัวแปรของผู้ใช้ใน Application คุณสามารถจินตนาการได้ว่ามีตู้นิรภัยมากมายในธนาคาร กุญแจและกุญแจ มีตัวเลขอยู่บนนั้นและหมายเลขบนกุญแจช่วยให้พนักงานนำคุณไปยังตู้เซฟของคุณเองได้ ยังคงมีการปรับปรุงวิธีนี้ แต่ก็เพียงพอสำหรับการใช้งานขนาดเล็ก
ตัวเลือกที่สอง
เกี่ยวกับโซลูชันก่อนหน้านี้ คุณอาจคิดว่าหมายเลขที่กำหนดเองของเราได้รับการบันทึกโดยใช้เซสชัน เมื่อพูดถึงตัวเลข ออบเจ็กต์เซสชันจะมีวิธี "SessionID" ถูกต้องไม่ว่าเราจะต้องการใช้หรือไม่ก็ตาม Server จะกำหนดหมายเลขให้กับผู้ใช้แต่ละคนโดยอัตโนมัติและหมายเลขนี้จะไม่ซ้ำกัน ส่วนหมายเลขนี้จะได้รับโดยใช้ Session.SessionID การกำหนดหมายเลขนี้เป็นการกระทำที่ Session จะทำอย่างแน่นอน เราสามารถใช้มันเพื่อแทนที่โปรแกรมการกำหนดหมายเลขที่เราเขียนเอง ซึ่งช่วยประหยัดความพยายามได้มากและยังให้ความสามารถในการขยายขนาดที่มากขึ้นอีกด้วย แต่โดยพื้นฐานแล้ว โซลูชันแรกข้างต้นยังคงมีการใช้งานอยู่ เช่น แอปพลิเคชันขนาดเล็ก เช่น ห้องสนทนาที่จำกัดจำนวนคน ทางเลือกถัดไปคือสำหรับระบบที่ใหญ่กว่า
สำหรับเว็บไซต์ที่มีผู้เยี่ยมชมนับร้อย นับพัน หรือหลายหมื่นคนต่อวินาที วิธีแก้ปัญหาก่อนหน้านี้จะไม่ทำงานอย่างแน่นอน สมมติว่าคุณกำหนดขีดจำกัดสูงสุดของจำนวนผู้ใช้ไว้ที่ 10,000 คน เมื่อเปิดใช้งานแล้ว เซิร์ฟเวอร์จะช่วยคุณตัดพื้นที่ 10,000 พื้นที่สำหรับผู้ใช้ 10,000 ราย หากมีตัวแปร 5 ตัวในพื้นที่ และตัวแปรหนึ่งตัวใช้พื้นที่ 32 ไบต์ แสดงว่าพื้นที่นั้นกินพื้นที่มากกว่า 10,000 ตัว มากกว่า 320000 K (320MB) เซิร์ฟเวอร์ ทันทีที่เปิดใช้งาน ขยะจำนวนมากจะถูกอัดแน่นอยู่ในหน่วยความจำ และประสิทธิภาพจะลดลงอย่างมากก่อนที่จะเข้าสู่สนามรบ และอย่าดูตัวเลขเล็กๆ เหล่านี้ และคิดว่า 512 MB ของคุณจะเป็น ตัวเลขข้างต้นถือเป็นจำนวนขั้นต่ำบวกกับไม่ทราบว่าเซิร์ฟเวอร์จะใช้ทรัพยากรเพิ่มเติมจำนวนเท่าใดในการกำหนดค่าหน่วยความจำจึงจะมากขึ้นเท่านั้นไม่น้อย ดังนั้น วิธีแก้ปัญหาเดียวคือกำหนดค่าพื้นที่ตัวแปรผู้ใช้แบบไดนามิก และตัดพื้นที่ออกเฉพาะเมื่อผู้ใช้เชื่อมต่อกับเซิร์ฟเวอร์ ด้วยวิธีนี้ ไม่จำเป็นต้องกำหนดค่าหน่วยความจำขนาดใหญ่ล่วงหน้า
ตัวเลือกที่สองนั้นค่อนข้างง่ายในการใช้งาน โปรดทิ้งทุกสิ่งในตัวเลือกแรก เราไม่จำเป็นต้องแตะ Global.asa เราเพียงแต่ต้องเปลี่ยนสถานที่เข้าสู่ระบบของผู้ใช้และสถานที่ที่มีประโยชน์อื่น ๆ เท่านั้น:
คัดลอกรหัสรหัสดังต่อไปนี้:
'LockApplicationApplication.Lock' ใส่ข้อมูลตัวแปร
แอปพลิเคชัน (User_Account_ & Session.SessionID) = บัญชี
Application(User_Logtime_ & Session.SessionID) = Now() 'ปลดล็อค Application.Unlock
หากต้องการรับข้อมูลตัวแปรที่เกี่ยวข้องกับผู้ใช้ ให้ทำดังต่อไปนี้:
คัดลอกรหัสรหัสดังต่อไปนี้:
Response.Write (แอปพลิเคชัน (User_Account_ & Session.SessionID))
ในอดีต ฉันอ่านหนังสือหลายเล่มที่บอกว่าเซสชันต้องใช้ทรัพยากรมาก ดังนั้นพยายามอย่าใช้มัน แต่คุณยังคงต้องใช้เมื่อจำเป็น และหนังสือเหล่านี้ไม่ได้สอนวิธีแก้ปัญหาที่เหมาะสมไปกว่านี้แล้ว ตอนนี้คุณเข้าใจวิธีแทนที่เซสชันแล้ว ใช้ประโยชน์จากมันได้เลย! บางทีปัญหาด้านประสิทธิภาพที่คอยกวนใจฉันมาตลอดสามารถปรับปรุงได้มาก!