ประสิทธิภาพเป็นคุณลักษณะ คุณต้องวิศวกรเพื่อประสิทธิภาพการทำงานล่วงหน้า ไม่เช่นนั้นคุณจะต้องเขียนใบสมัครใหม่ในภายหลัง ที่กล่าวว่ามีกลยุทธ์ที่ดีในการเพิ่มประสิทธิภาพแอปพลิเคชัน Active Server Pages (ASP) ให้สูงสุดคืออะไร
บทความนี้อธิบายเทคนิคสำหรับการเพิ่มประสิทธิภาพแอปพลิเคชัน ASP และ Visual Basic® Scripting Edition (VBScript) บทความนี้กล่าวถึงข้อผิดพลาดหลายประการ คำแนะนำที่ระบุไว้ในบทความนี้ได้รับการทดสอบที่ http://www.microsoft.com และไซต์อื่นๆ และผลลัพธ์ที่ได้มีความสำคัญมาก บทความนี้อนุมานว่าคุณมีความเข้าใจพื้นฐานเกี่ยวกับการพัฒนา ASP แล้ว รวมถึง VBScript และ/หรือ JScript, แอปพลิเคชัน ASP, เซสชัน ASP และวัตถุโดยธรรมชาติของ ASP อื่นๆ (คำขอ การตอบสนอง และเซิร์ฟเวอร์)
โดยทั่วไปแล้ว ประสิทธิภาพของ ASP ขึ้นอยู่กับปัจจัยหลายประการนอกเหนือจากโค้ด ASP เป็นหลัก แทนที่จะแสดงรายการข้อมูลทั้งหมดในบทความเดียว เราจะแสดงรายการทรัพยากรที่เกี่ยวข้องกับประสิทธิภาพไว้ที่ส่วนท้ายของบทความ ลิงค์เหล่านี้ครอบคลุมหัวข้อ ASP และที่ไม่ใช่ ASP รวมถึง ActiveX® Data Objects (ADO), Component Object Model (COM), ฐานข้อมูล และการกำหนดค่า Internet Information Server (IIS) นี่คือลิงค์โปรดบางส่วนของเรา - อย่าลืมลองดู
เคล็ดลับ 1: แคชข้อมูลที่ใช้บ่อยบนเว็บเซิร์ฟเวอร์
เพจ ASP ทั่วไปดึงข้อมูลจากที่เก็บข้อมูลส่วนหลัง จากนั้นแปลงผลลัพธ์เป็นภาษา Hypertext Markup (HTML) ไม่ว่าฐานข้อมูลจะเร็วแค่ไหนก็ตาม การดึงข้อมูลจากหน่วยความจำจะเร็วกว่าการดึงข้อมูลจากที่เก็บข้อมูลส่วนหลังเสมอ โดยทั่วไปการอ่านข้อมูลจากฮาร์ดไดรฟ์ในเครื่องจะเร็วกว่าการดึงข้อมูลจากฐานข้อมูล ดังนั้น ประสิทธิภาพมักจะได้รับการปรับปรุงโดยการแคชข้อมูลบนเว็บเซิร์ฟเวอร์ (เก็บไว้ในหน่วยความจำหรือบนดิสก์)
การแคชเป็นวิธีดั้งเดิมในการแลกเปลี่ยนพื้นที่ตามเวลา หากคุณแคชเนื้อหาที่ถูกต้อง คุณจะเห็นการปรับปรุงประสิทธิภาพที่สำคัญ เพื่อให้การแคชมีประสิทธิภาพ ต้องบันทึกข้อมูลที่นำมาใช้ซ้ำบ่อยครั้ง และการคำนวณข้อมูลนี้ใหม่ต้องใช้ค่าใช้จ่ายจำนวนมาก (ปานกลาง) หากแคชเป็นข้อมูลเก่าทั้งหมด จะทำให้หน่วยความจำสิ้นเปลือง
ข้อมูลที่เปลี่ยนแปลงไม่บ่อยนักเป็นตัวเลือกที่ดีสำหรับการแคช เนื่องจากคุณไม่ต้องกังวลกับการซิงค์ข้อมูลนั้นกับฐานข้อมูลเมื่อเวลาผ่านไป รายการกล่องคำสั่งผสม ตารางอ้างอิง แฟรกเมนต์ DHTML สตริง Extensible Markup Language (XML) รายการเมนู และตัวแปรการกำหนดค่าไซต์ (รวมถึงชื่อแหล่งข้อมูล (DSN) ที่อยู่อินเทอร์เน็ตโปรโตคอล (IP) และเส้นทางเว็บ) ล้วนเป็นแคชที่ดี เนื้อหา. โปรดทราบว่าคุณสามารถแคช "การเป็นตัวแทน" ของข้อมูลได้โดยไม่ต้องแคชข้อมูลเอง หากเพจ ASP เปลี่ยนแปลงน้อยมากและมีราคาแพงในการแคช (เช่น แค็ตตาล็อกผลิตภัณฑ์ทั้งหมด) คุณควรพิจารณาสร้าง HTML ล่วงหน้าแทนที่จะแสดงซ้ำเพื่อตอบสนองคำขอแต่ละรายการ
ข้อมูลควรถูกแคชไว้ที่ไหนและมีกลยุทธ์การแคชอะไรบ้าง? โดยทั่วไป ข้อมูลจะถูกแคชไว้ในหน่วยความจำหรือดิสก์ของเว็บเซิร์ฟเวอร์ เคล็ดลับสองข้อถัดไปจะครอบคลุมทั้งสองวิธี
เคล็ดลับ 2: แคชข้อมูลที่ใช้บ่อยในแอปพลิเคชันหรือวัตถุเซสชัน
แอปพลิเคชัน ASP และวัตถุเซสชันจัดเตรียมคอนเทนเนอร์ที่สะดวกสำหรับการแคชข้อมูลในหน่วยความจำ คุณสามารถกำหนดข้อมูลให้กับออบเจ็กต์แอปพลิเคชันและเซสชันได้ และข้อมูลจะยังคงอยู่ในหน่วยความจำระหว่างการโทร HTTP ข้อมูลเซสชันจะถูกจัดเก็บแยกกันสำหรับผู้ใช้แต่ละราย ในขณะที่ข้อมูลแอปพลิเคชันจะถูกแชร์ระหว่างผู้ใช้ทั้งหมด
เมื่อใดจึงควรโหลดข้อมูลเข้าสู่ Application หรือ Session? โดยทั่วไป ข้อมูลจะถูกโหลดเมื่อแอปพลิเคชันหรือเซสชันเริ่มต้นขึ้น หากต้องการโหลดข้อมูลระหว่างการเริ่มต้นแอปพลิเคชันหรือเซสชัน ให้เพิ่มโค้ดที่เหมาะสมลงใน Application_OnStart() หรือ Session_OnStart() ตามลำดับ ฟังก์ชันเหล่านี้ควรอยู่ใน Global.asa หากไม่ใช่ คุณสามารถเพิ่มฟังก์ชันเหล่านี้ได้ ข้อมูลนี้ยังสามารถโหลดได้ในครั้งแรกที่ต้องการ เมื่อต้องการทำเช่นนี้ ให้เพิ่มโค้ดบางส่วนลงในเพจ ASP (หรือเขียนฟังก์ชันสคริปต์ที่ใช้ซ้ำได้) เพื่อตรวจสอบว่ามีข้อมูลอยู่หรือไม่ และถ้าไม่มี ให้โหลดข้อมูล นี่เป็นเทคนิคการปฏิบัติงานแบบดั้งเดิมที่เรียกว่า "การประเมินแบบ Lazy" - ไม่ใช่การคำนวณค่าจนกว่าคุณจะรู้ว่าคุณต้องการมัน ตัวอย่างเช่น:
<%
ฟังก์ชัน GetEmploymentStatusList
ดิม ดี
d = แอปพลิเคชัน (?EmploymentStatusList?)
ถ้า d = ??แล้ว
' ฟังก์ชัน FetchEmploymentStatusList (ไม่แสดง)
' ดึงข้อมูลจาก DB ส่งคืน Array
d = FetchEmploymentStatusList()
แอปพลิเคชัน(?EmploymentStatusList?) = d
สิ้นสุดถ้า
GetEmploymentStatusList = วัน
ฟังก์ชันสิ้นสุด
-
สามารถเขียนฟังก์ชันที่คล้ายกันสำหรับแต่ละบล็อคข้อมูลที่ต้องการได้
ข้อมูลควรจัดเก็บในรูปแบบใด? คุณสามารถจัดเก็บตัวแปรประเภทใดก็ได้เนื่องจากตัวแปรสคริปต์ทั้งหมดเป็นประเภทตัวแปร ตัวอย่างเช่น คุณสามารถจัดเก็บสตริง จำนวนเต็ม หรืออาร์เรย์ได้ โดยทั่วไป คุณจะเก็บเนื้อหาของชุดระเบียน ADO ไว้ในประเภทตัวแปรเหล่านี้อย่างใดอย่างหนึ่ง หากต้องการรับข้อมูลจากชุดระเบียน ADO คุณสามารถคัดลอกข้อมูลลงในตัวแปร VBScript ด้วยตนเองได้ครั้งละหนึ่งฟิลด์ รวดเร็วและง่ายกว่าในการใช้ฟังก์ชันคงอยู่ของชุดระเบียน ADO อย่างใดอย่างหนึ่ง GetRows(), GetString() หรือ Save() (ADO 2.5) รายละเอียดอยู่นอกเหนือขอบเขตของบทความนี้ แต่นี่คือตัวอย่างฟังก์ชันที่ใช้ GetRows() เพื่อส่งคืนอาร์เรย์ของข้อมูลชุดระเบียน:
' Get Recordset, return as an Array
ฟังก์ชัน FetchEmploymentStatusList
หรี่แสง
ตั้งค่า rs = CreateObject(?ADODB.Recordset?)
rs.Open ?เลือก StatusName, StatusID จาก EmployeeStatus?, _
?dsn=พนักงาน;uid=sa;pwd=;?
FetchEmploymentStatusList = rs.GetRows() ? ส่งคืนข้อมูลเป็นอาร์เรย์
rs.ปิด
Setrs=ไม่มีอะไร
End Function
ปรับปรุงตัวอย่างข้างต้นเพิ่มเติมโดยการแคช HTML เป็นรายการแทนที่จะเป็นอาร์เรย์ นี่คือตัวอย่างง่ายๆ:
' รับ Recordset ส่งกลับเป็นรายการตัวเลือก HTML
ฟังก์ชัน FetchEmploymentStatusList
ติ่มซำ rs, fldName, s
ตั้งค่า rs = CreateObject(?ADODB.Recordset?)
rs.Open ?เลือก StatusName, StatusID จาก EmployeeStatus?, _
?dsn=พนักงาน;uid=sa;pwd=;?
s = ?<เลือกชื่อ=??สถานะการจ้างงาน??>? & vbCrLf
ตั้งค่า fldName = rs.Fields(?StatusName?) ' การเชื่อมฟิลด์ ADO
ทำจนถึง rs.EOF
' บรรทัดถัดไปละเมิด Don't Do String Concats
' แต่ก็ไม่เป็นไรเพราะเรากำลังสร้างแคช
s = s & ? <ตัวเลือก>? & fldName & ?</option>?
rs.MoveNext
วนซ้ำ
s = s & ?</select>? & vbCrLf
rs.ปิด
Set rs = Nothing ' ดูการเปิดตัวล่วงหน้า
FetchEmploymentStatusList = s ' ส่งคืนข้อมูลในรูปแบบสตริง
ฟังก์ชันสิ้นสุด
ภายใต้เงื่อนไขที่เหมาะสม ชุดระเบียน ADO สามารถแคชได้ในขอบเขตแอปพลิเคชันหรือเซสชัน มีข้อแม้สองประการ:
ADO ต้องถูกทำเครื่องหมายเป็นเธรดอิสระ และต้องใช้ชุดระเบียนที่ยกเลิกการเชื่อมต่อ
ถ้าไม่รับประกันข้อกำหนดทั้งสองนี้ อย่าแคชชุดระเบียน ADO ในเคล็ดลับ "คอมโพเนนต์ที่ไม่คล่องตัว" และ "อย่าแคชการเชื่อมต่อ" ต่อไปนี้ เราจะหารือเกี่ยวกับอันตรายของการจัดเก็บวัตถุ COM ในขอบเขตแอปพลิเคชันหรือเซสชัน
เมื่อคุณจัดเก็บข้อมูลในขอบเขตแอปพลิเคชันหรือเซสชัน ข้อมูลจะยังคงอยู่จนกว่าคุณจะเปลี่ยนแปลงโดยทางโปรแกรม เซสชันหมดอายุ หรือแอปพลิเคชันบนเว็บถูกรีสตาร์ท จะทำอย่างไรหากข้อมูลจำเป็นต้องได้รับการอัปเดต? หากต้องการบังคับอัปเดตข้อมูลแอปพลิเคชันด้วยตนเอง คุณสามารถเข้าถึงเพจ ASP ของผู้ดูแลระบบเท่านั้นเพื่ออัปเดตข้อมูล หรือคุณสามารถรีเฟรชข้อมูลโดยอัตโนมัติตามช่วงเวลาปกติผ่านฟังก์ชันได้ ตัวอย่างต่อไปนี้จัดเก็บการประทับเวลาด้วยข้อมูลที่แคชไว้ และรีเฟรชข้อมูลหลังจากช่วงระยะเวลาหนึ่ง
-
' ไม่แสดงข้อผิดพลาดในการส่ง...
Const UPDATE_INTERVAL = 300 ' ช่วงเวลารีเฟรช เป็นวินาที
' ฟังก์ชันเพื่อส่งคืนรายการสถานะการจ้างงาน
ฟังก์ชัน GetEmploymentStatusList
อัพเดทสถานะการจ้างงาน
GetEmploymentStatusList = แอปพลิเคชัน (?EmploymentStatusList?)
End Function
' อัปเดตข้อมูลที่แคชเป็นระยะๆ
ย่อย UpdateEmploymentStatusList
ติ่ม d, strLastUpdate
strLastUpdate = แอปพลิเคชัน (?อัพเดตล่าสุด?)
ถ้า (strLastUpdate = ??) หรือ _
(UPDATE_INTERVAL < DateDiff(?s?, strLastUpdate, Now)) จากนั้น
' หมายเหตุ: อาจมีการเรียกสองครั้งขึ้นไปที่นี่ ซึ่งเป็นเรื่องปกติ
' ส่งผลให้มีการดึงข้อมูลที่ไม่จำเป็นบางส่วน (มีวิธีแก้ไขปัญหานี้)
' ฟังก์ชัน FetchEmploymentStatusList (ไม่แสดง)
' ดึงข้อมูลจาก DB ส่งคืน Array
d = FetchEmploymentStatusList()
' อัพเดต Application object.
' เพื่อให้มั่นใจว่าข้อมูลมีความสอดคล้องกัน
แอปพลิเคชั่นล็อค
Application(?EmploymentStatusList?) = เหตุการณ์
Application(?LastUpdate?) = CStr(ตอนนี้)
แอปพลิเคชั่นปลดล็อค
สิ้นสุดถ้า
จบหมวดย่อย
ดูกล่องรายการที่เร็วที่สุดในโลกพร้อมข้อมูลแอปพลิเคชันซึ่งมีตัวอย่างด้วย
โปรดทราบว่าการแคชอาร์เรย์ขนาดใหญ่ในวัตถุเซสชันหรือแอปพลิเคชันไม่ใช่แนวทางปฏิบัติที่ดี ไวยากรณ์ของภาษาสคริปต์กำหนดให้ต้องคัดลอกอาร์เรย์ทั้งหมดชั่วคราวก่อนที่จะเข้าถึงองค์ประกอบใดๆ ของอาร์เรย์ ตัวอย่างเช่น หากคุณแคชอาร์เรย์ 100,000 องค์ประกอบของสตริงที่แมปรหัสไปรษณีย์ของสหรัฐอเมริกากับสถานีตรวจอากาศในพื้นที่ในออบเจ็กต์แอปพลิเคชัน ASP จะต้องคัดลอกสถานีตรวจอากาศทั้งหมด 100,000 รายการลงในอาร์เรย์ชั่วคราว จากนั้นจึงจะสามารถแตกสตริงได้ ในกรณีนี้ ควรสร้างส่วนประกอบที่กำหนดเองด้วยวิธีการที่กำหนดเองเพื่อจัดเก็บสถานีตรวจอากาศ หรือใช้ส่วนประกอบพจนานุกรมจะดีกว่า
ขอเตือนอีกประการหนึ่ง อย่าโยนทารกออกไปพร้อมกับน้ำอาบ เนื่องจากอาร์เรย์สามารถค้นหาได้อย่างรวดเร็วและจัดเก็บไว้ในหน่วยความจำเป็นคู่ข้อมูลคีย์ที่อยู่ติดกัน การทำดัชนีพจนานุกรมช้ากว่าการสร้างดัชนีอาร์เรย์มาก คุณควรเลือกโครงสร้างข้อมูลที่ให้ประสิทธิภาพที่ดีที่สุดสำหรับสถานการณ์ของคุณ
เคล็ดลับ 3: ข้อมูลแคชและ HTML บนดิสก์ของเว็บเซิร์ฟเวอร์
บางครั้งอาจมีข้อมูลมากเกินไปในการแคชในหน่วยความจำ "มากเกินไป" เป็นเพียงวิธีการบอกว่าขึ้นอยู่กับจำนวนหน่วยความจำที่คุณต้องการใช้ รวมถึงจำนวนรายการที่คุณต้องการแคช และความถี่ที่คุณต้องการเรียกคืน ไม่ว่าในกรณีใด หากข้อมูลมีมากเกินไปที่จะแคชไว้ในหน่วยความจำ ให้พิจารณาแคชข้อมูลบนฮาร์ดไดรฟ์ของเว็บเซิร์ฟเวอร์เป็นไฟล์ข้อความหรือ XML ข้อมูลสามารถแคชไว้บนดิสก์และในหน่วยความจำได้ในเวลาเดียวกัน เพื่อสร้างกลยุทธ์การแคชที่เหมาะสมที่สุดสำหรับไซต์ของคุณ
โปรดทราบว่าเมื่อวัดประสิทธิภาพของเพจ ASP เดียว การดึงข้อมูลจากดิสก์อาจไม่จำเป็นต้องเร็วกว่าการดึงข้อมูลจากฐานข้อมูล แต่การแคชจะช่วยลดภาระในฐานข้อมูลและเครือข่าย ภายใต้ภาระหนัก สิ่งนี้สามารถปรับปรุงปริมาณงานโดยรวมได้อย่างมาก ซึ่งจะมีประสิทธิภาพมากเมื่อแคชผลลัพธ์ของการสืบค้นที่มีราคาแพง (เช่น การรวมหลายตารางหรือขั้นตอนการจัดเก็บแบบผสม) หรือชุดผลลัพธ์ขนาดใหญ่ เช่นเคย ให้ทดสอบข้อดีข้อเสียของหลายตัวเลือก
ASP และ COM จัดเตรียมเครื่องมือสำหรับการตั้งค่าโซลูชันการแคชบนดิสก์ ฟังก์ชันบันทึก () และ Open() ของชุดระเบียน ADO จะบันทึกและโหลดชุดระเบียนจากดิสก์ คุณสามารถใช้วิธีการเหล่านี้เพื่อเขียนตัวอย่างโค้ดใหม่ในเทคนิคการแคชข้อมูลแอปพลิเคชันด้านบน โดยใช้ Save() ของไฟล์แทนการเขียนโค้ดลงในออบเจ็กต์แอปพลิเคชัน
มีองค์ประกอบอื่นๆ บางประการที่ทำงานกับไฟล์ได้:
Scripting.FileSystemObject ให้คุณสร้าง อ่าน และเขียนไฟล์ได้
Microsoft® XML parser (MSXML) ที่มาพร้อมกับ Internet Explorer รองรับการบันทึกและการโหลดเอกสาร XML
อ็อบเจ็กต์ LookupTable (ใช้บน MSN เป็นต้น) เป็นตัวเลือกที่ดีที่สุดสำหรับการโหลดรายการแบบง่ายจากดิสก์
สุดท้าย ให้พิจารณาแคชการแสดงข้อมูลบนดิสก์ แทนที่จะพิจารณาตัวข้อมูลเอง HTML ที่แปลงไว้ล่วงหน้าสามารถจัดเก็บไว้ในดิสก์ในรูปแบบไฟล์ .htm หรือ .asp และไฮเปอร์ลิงก์สามารถชี้ไปที่ไฟล์เหล่านี้ได้โดยตรง คุณสามารถใช้เครื่องมือเชิงพาณิชย์ เช่น XBuilder หรือคุณลักษณะ Microsoft® SQL Server® Internet Publishing เพื่อทำให้กระบวนการสร้าง HTML เป็นแบบอัตโนมัติ หรือคุณสามารถวางข้อมูลโค้ด HTML ในไฟล์ .asp ได้ คุณยังสามารถใช้ FileSystemObject เพื่ออ่านไฟล์ HTML จากดิสก์ หรือใช้ XML เพื่อแปลงไฟล์ตั้งแต่เนิ่นๆ
เคล็ดลับ 4: หลีกเลี่ยงการแคชส่วนประกอบที่ไม่คล่องตัวในแอปพลิเคชันหรือวัตถุเซสชัน
แม้ว่าการแคชข้อมูลในวัตถุแอปพลิเคชันหรือเซสชันเป็นวิธีปฏิบัติที่ดี แต่การแคชวัตถุ COM มีข้อผิดพลาดร้ายแรง โดยทั่วไปแล้ว ผู้ใช้มักจะแคชวัตถุ COM ที่ใช้บ่อยลงในวัตถุแอปพลิเคชันหรือเซสชัน น่าเสียดาย วัตถุ COM จำนวนมาก (รวมถึงวัตถุทั้งหมดที่เขียนใน Visual Basic 6.0 หรือรุ่นก่อนหน้า) ทำให้เกิดปัญหาคอขวดที่ร้ายแรงเมื่อเก็บไว้ในวัตถุแอปพลิเคชันหรือเซสชัน
โดยเฉพาะอย่างยิ่ง เมื่อมีการแคชส่วนประกอบที่ไม่คล่องตัวในอ็อบเจ็กต์เซสชันหรือแอปพลิเคชัน จะทำให้เกิดปัญหาคอขวดด้านประสิทธิภาพ ส่วนประกอบแบบ Agile คือส่วนประกอบที่มีเครื่องหมาย ThreadingModel=Both ซึ่งรวม Free-threaded marshaler (FTM) หรือส่วนประกอบที่มีเครื่องหมาย ThreadingModel=Neutral (รุ่น Neutral เป็นรุ่นใหม่สำหรับ Windows® 2000 และ COM+) ส่วนประกอบต่อไปนี้ไม่คล่องตัว:
ส่วนประกอบแบบ Free-threaded (เว้นแต่จะรวม FTM)
ส่วนประกอบด้ายอพาร์ทเมนท์
ส่วนประกอบเกลียวเดี่ยว
ส่วนประกอบที่กำหนดค่า (ไลบรารี Microsoft Transaction Server (MTS)/COM+ และแพ็คเกจ/แอปพลิเคชันเซิร์ฟเวอร์) จะไม่คล่องตัวเว้นแต่จะเป็นเธรดที่เป็นกลาง ส่วนประกอบแบบเธรดอพาร์ทเมนท์และส่วนประกอบที่ไม่คล่องตัวอื่นๆ เหมาะสมที่สุดที่ขอบเขตเพจ (นั่นคือ ส่วนประกอบเหล่านั้นถูกสร้างขึ้นและทำลายบนเพจ ASP เดียว)
ใน IIS 4.0 ส่วนประกอบที่มีเครื่องหมาย ThreadingModel=Both ถือว่ามีความคล่องตัว ใน IIS 5.0 เพียงอย่างเดียวนี้ยังไม่เพียงพอ คอมโพเนนต์ต้องไม่เพียงแค่ทำเครื่องหมายทั้งสองเท่านั้น แต่ยังต้องรวม FTM ด้วย บทความเกี่ยวกับความคล่องตัวจะอธิบายวิธีรวม FTM กับส่วนประกอบ C++ ที่เขียนใน Active Template Library โปรดทราบว่าถ้าส่วนประกอบแคชตัวชี้อินเทอร์เฟซ ตัวชี้เหล่านั้นจะต้องคล่องตัวหรือต้องเก็บไว้ในตารางอินเทอร์เฟซทั่วไป (GIT) ของ COM หากคุณไม่สามารถคอมไพล์ส่วนประกอบทั้งสองเธรดใหม่เพื่อรวม FTM คุณสามารถทำเครื่องหมายส่วนประกอบด้วย ThreadingModel=Neutral อีกทางหนึ่ง ถ้าคุณไม่ต้องการให้ IIS ทำการตรวจสอบความคล่องตัว (ดังนั้น คุณสามารถอนุญาตให้เก็บส่วนประกอบที่ไม่คล่องตัวในขอบเขตแอปพลิเคชันหรือเซสชัน) คุณสามารถตั้งค่า AspTrackThreadingModel เป็น True ใน metabase ไม่แนะนำให้เปลี่ยน AspTrackThreadingModel
IIS 5.0 จะแสดงข้อผิดพลาดหากคุณต้องการจัดเก็บคอมโพเนนต์ที่ไม่คล่องตัวที่สร้างด้วย Server.CreateObject ในวัตถุแอปพลิเคชัน คุณสามารถหลีกเลี่ยงข้อผิดพลาดนี้ได้โดยใช้ <object runat=server scope=application ...> ใน Global.asa แต่ไม่แนะนำ เนื่องจากอาจนำไปสู่การรวมกลุ่มและการทำให้เป็นอนุกรมได้ ตามที่อธิบายไว้ด้านล่าง
จะเกิดอะไรขึ้นหากคุณแคชส่วนประกอบที่ไม่คล่องตัว ส่วนประกอบที่ไม่คล่องตัวที่แคชไว้ในวัตถุเซสชันจะล็อกเซสชันไปยังเธรดของผู้ปฏิบัติงาน ASP ASP ดูแลรักษากลุ่มเธรดผู้ปฏิบัติงานเพื่อจัดการกับคำขอ โดยปกติแล้ว คำขอใหม่จะได้รับการจัดการโดยเธรดผู้ปฏิบัติงานแรกที่มีอยู่เสมอ หากเซสชันถูกล็อคไว้กับเธรด การร้องขอต้องรอจนกว่าเธรดที่เกี่ยวข้องจะพร้อมใช้งาน การเปรียบเทียบที่อาจช่วยได้: คุณไปที่ซูเปอร์มาร์เก็ต เลือกสินค้าบางรายการ และชำระเงินที่เคาน์เตอร์ชำระเงิน #_3 หลังจากนั้น เมื่อใดก็ตามที่คุณชำระค่าสินค้าในซูเปอร์มาร์เก็ตนั้น คุณจะต้องชำระเงินที่จุดชำระเงิน #_3 เสมอ แม้ว่าจุดชำระเงินอื่นจะมีคิวน้อยลงหรือไม่มีเลยก็ตาม
การจัดเก็บส่วนประกอบที่ไม่คล่องตัวในขอบเขตของแอปพลิเคชันมีผลกระทบต่อประสิทธิภาพที่แย่ลงไปอีก ASP ต้องสร้างเธรดพิเศษเพื่อเรียกใช้คอมโพเนนต์ที่ไม่คล่องตัวที่จัดเก็บไว้ในขอบเขตแอปพลิเคชัน สิ่งนี้มีผลกระทบสองประการ: การโทรทั้งหมดจะต้องถูกส่งไปยังเธรดนี้ และการโทรทั้งหมดจะถูกจัดคิว "การรวมกลุ่ม" หมายความว่าต้องจัดเก็บพารามิเตอร์ไว้ในพื้นที่หน่วยความจำที่ใช้ร่วมกัน ดำเนินการสลับบริบทที่มีราคาแพงไปยังเธรดพิเศษ ดำเนินการวิธีการของส่วนประกอบ รวมผลลัพธ์ลงในพื้นที่ที่ใช้ร่วมกัน ดำเนินการสลับบริบทที่มีราคาแพงอื่น ไปยังเธรดเดิม "การทำให้เป็นอนุกรม" หมายความว่าเรียกใช้ได้ครั้งละหนึ่งวิธีเท่านั้น เธรดผู้ปฏิบัติงาน ASP ที่แตกต่างกันสองเธรดไม่สามารถดำเนินการหลายวิธีบนส่วนประกอบที่ใช้ร่วมกันพร้อมกันได้ วิธีนี้จะช่วยลดการทำงานพร้อมกัน โดยเฉพาะบนคอมพิวเตอร์ที่ใช้โปรเซสเซอร์หลายตัว ที่แย่กว่านั้นคือ ส่วนประกอบที่ไม่ใช่ขอบเขตแอปพลิเคชันแบบ Agile ทั้งหมดจะใช้เธรดเดียว (โฮสต์ STA) ดังนั้นผลกระทบของการทำให้เป็นอนุกรมจึงมีความสำคัญมากยิ่งขึ้น
ฉันจะทำอย่างไร? ต่อไปนี้เป็นกฎทั่วไปบางประการ หากคุณเขียนวัตถุโดยใช้ Visual Basic (6.0) หรือรุ่นก่อนหน้า อย่าแคชวัตถุเหล่านั้นในวัตถุแอปพลิเคชันหรือเซสชัน หากคุณไม่ทราบโมเดลเธรดของออบเจ็กต์ อย่าแคช อย่าแคชวัตถุที่ไม่คล่องตัว แต่ให้สร้างและปล่อยวัตถุเหล่านั้นในแต่ละหน้าแทน ออบเจ็กต์ทำงานโดยตรงบนเธรดของผู้ปฏิบัติงาน ASP ดังนั้นจึงไม่มีการพูลหรือการทำให้เป็นอนุกรม ถ้าวัตถุ COM กำลังทำงานบนเซิร์ฟเวอร์ IIS ประสิทธิภาพเป็นที่ยอมรับได้หากไม่ได้ใช้เวลานานในการเตรียมใช้งานและลบ โปรดทราบว่าวัตถุแบบเธรดเดี่ยวไม่ควรใช้ในลักษณะนี้ ระวัง - VB สามารถสร้างวัตถุแบบเธรดเดียวได้! หากคุณต้องใช้ออบเจ็กต์แบบเธรดเดียว (เช่น สเปรดชีต Microsoft Excel) เช่นนี้ อย่าคาดหวังว่าจะมีปริมาณงานสูง
เมื่อ ADO ถูกทำเครื่องหมายเป็นเธรดอิสระ ชุดระเบียน ADO สามารถถูกแคชได้อย่างปลอดภัย หากต้องการทำเครื่องหมาย ADO ว่าเป็น free-threaded ให้ใช้ไฟล์ Makfre15.bat ซึ่งโดยปกติจะอยู่ในไดเร็กทอรี \Program FilesCommonSystemADO
คำเตือน ถ้าคุณใช้ Microsoft Access เป็นฐานข้อมูลของคุณ คุณไม่ควรทำเครื่องหมาย ADO เป็นแบบ free-threaded ชุดระเบียน ADO จะต้องถูกตัดการเชื่อมต่อด้วย โดยทั่วไป ถ้าคุณไม่ควบคุมการกำหนดค่า ADO ในไซต์ของคุณ (ตัวอย่างเช่น คุณเป็นผู้จำหน่ายซอฟต์แวร์อิสระ [ISV] ที่ขายแอปพลิเคชันบนเว็บให้กับลูกค้าที่จัดการการกำหนดค่าของตนเอง) วิธีที่ดีที่สุดคือไม่แคชชุดระเบียน
ส่วนประกอบของพจนานุกรมก็เป็นวัตถุที่คล่องตัวเช่นกัน LookupTable โหลดข้อมูลจากไฟล์ข้อมูลและสามารถใช้สำหรับข้อมูลกล่องคำสั่งผสมและข้อมูลการกำหนดค่า ออบเจ็กต์ PageCache ใน Duwamish Books มีไวยากรณ์ของพจนานุกรม เช่นเดียวกับ Caprock Dictionary อ็อบเจ็กต์เหล่านี้หรืออ็อบเจ็กต์ที่ได้รับสามารถสร้างพื้นฐานของกลยุทธ์การแคชที่มีประสิทธิภาพ โปรดทราบว่าอ็อบเจ็กต์ Scripting.Dictionary ไม่คล่องตัวและไม่ควรจัดเก็บไว้ในขอบเขตแอปพลิเคชันหรือเซสชัน
เคล็ดลับ 5: อย่าแคชการเชื่อมต่อฐานข้อมูลในแอปพลิเคชันหรือวัตถุเซสชัน
การแคชการเชื่อมต่อ ADO โดยทั่วไปเป็นกลยุทธ์ที่ไม่ดี หากออบเจ็กต์การเชื่อมต่อถูกจัดเก็บไว้ในออบเจ็กต์แอปพลิเคชันและใช้ในทุกเพจ ทุกเพจจะแข่งขันกันเพื่อการเชื่อมต่อนี้ ถ้าวัตถุการเชื่อมต่อถูกเก็บไว้ในวัตถุเซสชัน ASP การเชื่อมต่อฐานข้อมูลจะถูกสร้างขึ้นสำหรับผู้ใช้แต่ละคน สิ่งนี้จะลบล้างข้อดีของการรวมการเชื่อมต่อและสร้างแรงกดดันที่ไม่จำเป็นต่อเว็บเซิร์ฟเวอร์และฐานข้อมูล
แทนที่จะแคชการเชื่อมต่อฐานข้อมูล คุณสามารถสร้างและลบวัตถุ ADO ในแต่ละเพจ ASP ที่ใช้ ADO สิ่งนี้มีประสิทธิภาพเนื่องจาก IIS มีการรวมการเชื่อมต่อฐานข้อมูลในตัว เพื่อให้แม่นยำยิ่งขึ้น IIS จะเปิดใช้งานการรวมการเชื่อมต่อ OLEDB และ ODBC โดยอัตโนมัติ เพื่อให้แน่ใจว่าการเชื่อมต่อที่สร้างและลบในทุกเพจจะใช้งานได้
เนื่องจากชุดระเบียนที่เชื่อมต่อเก็บการอ้างอิงไปยังการเชื่อมต่อฐานข้อมูล คุณไม่ควรแคชชุดระเบียนที่เชื่อมต่อในวัตถุแอปพลิเคชันหรือเซสชัน อย่างไรก็ตาม คุณสามารถแคชชุดระเบียนที่ไม่ได้เชื่อมต่อซึ่งไม่มีการอ้างอิงถึงการเชื่อมต่อข้อมูลได้อย่างปลอดภัย เมื่อต้องการยกเลิกการเชื่อมต่อชุดระเบียน ให้ดำเนินการสองขั้นตอนต่อไปนี้:
Set rs = Server.CreateObject(?ADODB.RecordSet?)
rs.CursorLocation = adUseClient ' ขั้นตอนที่ 1
' เติมชุดระเบียนด้วยข้อมูล
rs.Open strQuery, strProv
' ตอนนี้ยกเลิกการเชื่อมต่อชุดระเบียนจากผู้ให้บริการข้อมูลและแหล่งข้อมูล
rs.ActiveConnection = ไม่มี ' ขั้นตอนที่ 2
ข้อมูลรายละเอียดเพิ่มเติมเกี่ยวกับการพูลการเชื่อมต่อสามารถพบได้ในเอกสารอ้างอิง ADO และ SQL Server
เคล็ดลับ 6: ใช้เซสชันออบเจ็กต์อย่างถูกต้อง
ตอนนี้เราได้พูดถึงข้อดีของการแคชในแอปพลิเคชันและเซสชันแล้ว เรามาอภิปรายเกี่ยวกับการหลีกเลี่ยงการใช้อ็อบเจ็กต์เซสชันกัน ตามที่กล่าวไว้ด้านล่าง เซสชันมีข้อเสียหลายประการเมื่อใช้กับไซต์ที่ไม่ว่าง โดยทั่วไป "ไม่ว่าง" หมายถึงไซต์ที่ต้องใช้หลายร้อยเพจต่อวินาทีหรือผู้ใช้หลายพันคนพร้อมกัน เคล็ดลับนี้มีความสำคัญมากยิ่งขึ้นสำหรับไซต์ที่ต้องปรับขนาดในแนวนอน นั่นคือไซต์ที่ใช้เซิร์ฟเวอร์หลายเครื่องเพื่อจัดการโหลดหรือยอมรับข้อผิดพลาด สำหรับไซต์ขนาดเล็ก เช่น ไซต์อินทราเน็ต หากคุณต้องการทราบถึงประโยชน์ที่ได้รับจากเซสชัน ค่าใช้จ่ายของระบบก็จะเพิ่มขึ้นอย่างหลีกเลี่ยงไม่ได้
กล่าวโดยสรุป ASP จะสร้างเซสชันโดยอัตโนมัติสำหรับผู้ใช้แต่ละรายที่เข้าถึงเว็บเซิร์ฟเวอร์ แต่ละเซสชันต้องใช้หน่วยความจำประมาณ 10 KB (สิ่งสำคัญคือข้อมูลจะถูกจัดเก็บไว้ในเซสชัน) ซึ่งจะทำให้คำขอทั้งหมดช้าลง เซสชันยังคงใช้ได้จนกว่าช่วงหมดเวลาที่กำหนดค่าไว้ (ปกติคือ 20 นาที) จะผ่านไป
ปัญหาที่ใหญ่ที่สุดของเซสชันไม่ใช่ประสิทธิภาพ แต่เป็นความสามารถในการปรับขนาด เซสชันไม่สามารถครอบคลุมเว็บเซิร์ฟเวอร์หลายแห่งได้ เมื่อสร้างเซสชันบนเซิร์ฟเวอร์เดียว ข้อมูลจะยังคงอยู่ตรงนั้น ซึ่งหมายความว่าหากคุณใช้เซสชันในเว็บเซิร์ฟเวอร์ฟาร์ม คุณต้องออกแบบนโยบายที่จะส่งคำขอของผู้ใช้แต่ละคนไปยังเซิร์ฟเวอร์ที่มีเซสชันของผู้ใช้อยู่เสมอ สิ่งนี้เรียกว่า "การติดกาว" ผู้ใช้กับเว็บเซิร์ฟเวอร์ คำว่า "เซสชันติดหนึบ" มาจากสิ่งนี้ หากเว็บเซิร์ฟเวอร์ล่ม ผู้ใช้ "ติด" จะสูญเสียสถานะเซสชันของตนเนื่องจากเซสชันไม่ติดอยู่บนดิสก์
กลยุทธ์ในการบรรลุเซสชันที่เหนียวแน่น ได้แก่ โซลูชันฮาร์ดแวร์และซอฟต์แวร์ โซลูชันต่างๆ เช่น Network Load Balancing ใน Windows 2000 Advanced Server และ Local Director ของ Cisco สามารถใช้เซสชันที่ติดหนึบได้โดยต้องแลกกับความสามารถในการปรับขนาดในระดับหนึ่ง วิธีแก้ปัญหาเหล่านี้ไม่สมบูรณ์ ไม่แนะนำให้ปรับใช้โซลูชันซอฟต์แวร์ของคุณเองในขณะนี้ (เราเคยใช้ตัวกรอง ISAPI และการแปลง URL เป็นต้น)
ออบเจ็กต์แอปพลิเคชันยังไม่ครอบคลุมหลายเซิร์ฟเวอร์ หากคุณต้องแชร์และอัปเดตข้อมูลแอปพลิเคชันผ่านฟาร์มของเว็บเซิร์ฟเวอร์ คุณต้องใช้ฐานข้อมูลส่วนหลัง อย่างไรก็ตาม ข้อมูลแอปพลิเคชันแบบอ่านอย่างเดียวยังคงมีประโยชน์ในเว็บเซิร์ฟเวอร์ฟาร์ม
ไซต์ที่มีความสำคัญต่อภารกิจส่วนใหญ่ต้องการเว็บเซิร์ฟเวอร์อย่างน้อยสองเซิร์ฟเวอร์ หากเพียงเพื่อเพิ่มเวลาทำงาน (เพื่อจัดการการเฟลโอเวอร์และการบำรุงรักษาเซิร์ฟเวอร์) ดังนั้น เมื่อออกแบบแอปพลิเคชันที่มีความสำคัญต่อภารกิจ คุณต้องใช้ "เซสชันที่ติดหนึบ" หรือหลีกเลี่ยงการใช้เซสชันและเทคโนโลยีการจัดการสถานะอื่น ๆ ที่เก็บสถานะผู้ใช้ไว้บนเว็บเซิร์ฟเวอร์เดียว
หากคุณไม่ได้ใช้เซสชัน อย่าลืมปิดเซสชันเหล่านั้น คุณสามารถทำเช่นนี้สำหรับแอปพลิเคชันผ่านทาง Internet Services Manager (ดูเอกสารประกอบ ISM) หากคุณตัดสินใจใช้เซสชัน คุณจะลดผลกระทบที่มีต่อประสิทธิภาพได้หลายวิธี
คุณสามารถย้ายเนื้อหาที่ไม่จำเป็นต้องมีเซสชัน (เช่น หน้าจอวิธีใช้ พื้นที่ผู้เยี่ยมชม ฯลฯ) ไปยังแอปพลิเคชัน ASP อื่นที่ปิดเซสชันแล้ว คุณสามารถพร้อมท์ ASP ทีละหน้าว่าคุณไม่ต้องการวัตถุเซสชันบนหน้านั้นอีกต่อไป โดยใช้คำสั่งต่อไปนี้ที่ด้านบนของหน้า ASP:
<% @EnableSessionState=False %>
เหตุผลที่ดีสำหรับการใช้สิ่งนี้ คำสั่งคือเซสชันเหล่านี้มีปัญหาที่น่าสนใจกับชุดเฟรม ASP รับประกันว่าจะมีการดำเนินการคำขอเดียวเท่านั้นในเซสชันได้ตลอดเวลา สิ่งนี้ทำให้แน่ใจได้ว่าหากเบราว์เซอร์ร้องขอหลายเพจสำหรับผู้ใช้ หนึ่งคำขอ ASP เดียวเท่านั้นที่จะแตะเซสชันในแต่ละครั้ง ดังนั้นจึงหลีกเลี่ยงปัญหามัลติเธรดที่เกิดขึ้นเมื่อเข้าถึงอ็อบเจ็กต์เซสชัน ขออภัย หน้าทั้งหมดในเฟรมเซตจะแสดงตามลำดับ ทีละหน้า แทนที่จะแสดงพร้อมกัน ผู้ใช้อาจต้องรอเป็นเวลานานจึงจะเห็นเฟรมทั้งหมด คติประจำใจของเรื่องราว: หากเพจเฟรมเซ็ตบางเพจไม่ต้องใช้เซสชัน อย่าลืมบอก ASP โดยใช้ @EnableSessionState=False directive
มีหลายวิธีในการจัดการสถานะเซสชันที่สามารถแทนที่การใช้ออบเจ็กต์เซสชันได้ สำหรับสถานะจำนวนเล็กน้อย (น้อยกว่า 4 KB) โดยทั่วไปเราแนะนำให้ใช้คุกกี้ ตัวแปร QueryString และตัวแปรโดยนัย สำหรับข้อมูลปริมาณมาก เช่น ตะกร้าสินค้า ฐานข้อมูลแบ็คเอนด์คือตัวเลือกที่เหมาะสมที่สุด มีการเขียนมากมายเกี่ยวกับเทคนิคการจัดการสถานะในเว็บเซิร์ฟเวอร์ฟาร์ม สำหรับข้อมูลเพิ่มเติม โปรดดูที่ การอ้างอิงสถานะเซสชัน
เคล็ดลับ 7: สรุปโค้ดในวัตถุ COM
หากคุณมี VBScript หรือ JScript จำนวนมาก คุณสามารถปรับปรุงประสิทธิภาพได้โดยการย้ายโค้ดของคุณไปยังวัตถุ COM ที่คอมไพล์แล้ว โค้ดที่คอมไพล์มักจะทำงานเร็วกว่าโค้ดที่ตีความ วัตถุ COM ที่คอมไพล์แล้วสามารถเข้าถึงวัตถุ COM อื่นๆ ผ่าน "การผูกล่วงหน้า" ซึ่งเป็นวิธีการเรียกวัตถุ COM ที่มีประสิทธิภาพมากกว่า "การผูกล่าช้า" ที่ใช้โดยสคริปต์
การห่อหุ้มโค้ดในออบเจ็กต์ COM มีข้อดีหลายประการ (นอกเหนือจากประสิทธิภาพ):
ออบเจ็กต์ COM ช่วยแยกตรรกะการนำเสนอออกจากตรรกะทางธุรกิจ
วัตถุ COM ช่วยให้มั่นใจว่ามีการใช้โค้ดซ้ำ
นักพัฒนาหลายคนพบว่าโค้ดที่เขียนด้วย VB, C++ หรือ Visual J++ นั้นแก้ไขได้ง่ายกว่า ASP
ออบเจ็กต์ COM ก็มีข้อเสียเช่นกัน รวมถึงเวลาเริ่มต้นในการพัฒนาและต้องใช้ทักษะการเขียนโปรแกรมที่แตกต่างกัน โปรดทราบว่าการห่อหุ้ม ASP จำนวนเล็กน้อยอาจทำให้ประสิทธิภาพลดลงโดยไม่ปรับปรุงประสิทธิภาพ สถานการณ์นี้มักจะเกิดขึ้นเมื่อรหัส ASP จำนวนเล็กน้อยถูกห่อหุ้มลงในวัตถุ COM ในกรณีนี้ ค่าใช้จ่ายในการสร้างและการเรียกวัตถุ COM มีมากกว่าข้อดีของโค้ดที่คอมไพล์แล้ว ควรใช้การทดลองและข้อผิดพลาดเพื่อกำหนดว่าสคริปต์ ASP และรหัสวัตถุ COM ใดที่ทำให้เกิดประสิทธิภาพที่ดีที่สุด โปรดทราบว่ามีการปรับปรุงที่สำคัญในการเขียนสคริปต์และประสิทธิภาพ ADO ใน Windows 2000/IIS 5.0 เมื่อเปรียบเทียบกับ Microsoft Windows NT® 4.0/IIS 4.0 ดังนั้น ด้วยการเปิดตัว IIS 5.0 ข้อได้เปรียบด้านประสิทธิภาพของโค้ดที่คอมไพล์แล้วบนโค้ด ASP จึงลดลง
สำหรับการอภิปรายโดยละเอียดเกี่ยวกับข้อดีและข้อเสียของการใช้ COM ใน ASP โปรดดูแนวทางคอมโพเนนต์ ASP และแอปพลิเคชันแบบกระจายการเขียนโปรแกรมด้วยและ Microsoft Visual Basic 6.0 ถ้าคุณปรับใช้คอมโพเนนต์ COM สิ่งสำคัญอย่างยิ่งในการทดสอบภายใต้โหลด ในความเป็นจริงแล้ว แอปพลิเคชัน ASP ทั้งหมดควรได้รับการทดสอบโหลดอย่างแน่นอน
เคล็ดลับ 8: รับทรัพยากรในภายหลังและเผยแพร่ก่อนหน้านี้ ต่อไป
นี้เป็นเคล็ดลับเล็กๆ น้อยๆ สำหรับการอ้างอิงของคุณ โดยทั่วไปแล้ว จะดีกว่าหากได้รับทรัพยากรในภายหลังและเผยแพร่ก่อนหน้านี้ สิ่งนี้ใช้กับวัตถุ COM รวมถึงตัวจัดการไฟล์และทรัพยากรอื่นๆ
วิธีการปรับให้เหมาะสมนี้ส่วนใหญ่จะใช้สำหรับการเชื่อมต่อ ADO และชุดระเบียน เมื่อคุณทำชุดระเบียนเสร็จแล้ว เช่น หลังจากแสดงตารางและข้อมูลแล้ว คุณควรปล่อยชุดระเบียนทันทีแทนที่จะรอจนถึงจุดสิ้นสุดของหน้า แนวทางปฏิบัติที่ดีที่สุดในการตั้งค่าตัวแปร VBScript เป็น Nothing อย่าปล่อยให้ชุดระเบียนอยู่นอกขอบเขต นอกจากนี้ ให้ปล่อยออบเจ็กต์ Command หรือ Connection ที่เกี่ยวข้อง (อย่าลืมเรียก Close() ก่อนที่จะตั้งค่าชุดระเบียนหรือการเชื่อมต่อเป็น = Nothing) ซึ่งจะช่วยลดเวลาที่ฐานข้อมูลต้องเตรียมทรัพยากรสำหรับคุณ และเผยแพร่การเชื่อมต่อฐานข้อมูลไปยังพูลการเชื่อมต่อโดยเร็วที่สุด
เคล็ดลับ 9: การดำเนินการนอกกระบวนการแลกเปลี่ยนประสิทธิภาพเพื่อความน่าเชื่อถือ
ทั้ง ASP และ MTS/COM+ มีตัวเลือกการกำหนดค่าที่ช่วยให้คุณสามารถแลกเปลี่ยนความน่าเชื่อถือกับประสิทธิภาพได้ เมื่อสร้างและปรับใช้แอปพลิเคชัน คุณควรรู้วิธีสร้างสมดุลระหว่างประสิทธิภาพกับทั้งสองอย่าง
ตัวเลือก ASP กำหนดค่าแอปพลิเคชัน ASP ให้ทำงานด้วยวิธีใดวิธีหนึ่งจากสามวิธี ใน IIS 5.0 คำว่า "ระดับการแยก" ถูกนำมาใช้เพื่ออธิบายตัวเลือกเหล่านี้ ระดับการแยกสามระดับคือระดับต่ำ ระดับกลาง และระดับสูง:
การแยกระดับต่ำ รองรับ IIS ทุกเวอร์ชันและเป็นเวอร์ชันที่เร็วที่สุด มันรัน ASP ใน Inetinfo.exe ซึ่งเป็นกระบวนการ IIS หลัก หากแอปพลิเคชัน ASP ขัดข้อง IIS ก็จะเป็นเช่นนั้น (ในการรีสตาร์ท IIS ภายใต้ IIS 4.0 ผู้ดูแลเว็บไซต์ควรตรวจสอบไซต์โดยใช้เครื่องมือ เช่น InetMon และเปิดใช้งานแบตช์ไฟล์เพื่อรีสตาร์ทเซิร์ฟเวอร์หากเซิร์ฟเวอร์ล้มเหลว IIS 5.0 แนะนำการรีสตาร์ทที่เชื่อถือได้ ซึ่งเป็นวิธีการรีสตาร์ทเซิร์ฟเวอร์ที่ล้มเหลวโดยอัตโนมัติ ).
การแยกตัวระดับกลาง IIS 5.0 แนะนำระดับใหม่นี้ ซึ่งเรียกว่าระดับนอกกระบวนการเนื่องจาก ASP ทำงานนอกกระบวนการ IIS ในการแยกระดับกลาง แอปพลิเคชัน ASP ทั้งหมดที่ได้รับการกำหนดค่าให้ทำงานเป็นการแยกระดับกลางจะใช้พื้นที่กระบวนการร่วมกัน ซึ่งจะช่วยลดจำนวนกระบวนการที่จำเป็นในการเรียกใช้แอปพลิเคชัน ASP ที่ไม่อยู่ในกระบวนการหลายรายการบนเซิร์ฟเวอร์เดียว การแยกระดับปานกลางคือระดับการแยกเริ่มต้นใน IIS 5.0
การแยกขั้นสูง ระดับนี้ได้รับการสนับสนุนใน IIS 4.0 และ IIS 5.0 และการแยกขั้นสูงก็ไม่อยู่ในกระบวนการเช่นกัน หาก ASP ขัดข้อง เว็บเซิร์ฟเวอร์จะไม่ขัดข้อง แอปพลิเคชัน ASP จะรีสตาร์ทโดยอัตโนมัติในครั้งถัดไปที่มีการร้องขอ ASP ในการแยกขั้นสูง แอปพลิเคชัน ASP แต่ละตัวได้รับการกำหนดค่าให้ทำงานในขณะที่การแยกขั้นสูงทำงานในพื้นที่กระบวนการของตัวเอง การทำเช่นนี้จะช่วยปกป้องแอปพลิเคชัน ASP ไม่ให้รบกวนซึ่งกันและกัน ข้อเสียคือต้องใช้กระบวนการแยกต่างหากสำหรับแต่ละแอปพลิเคชัน ASP เมื่อแอพพลิเคชั่นจำนวนมากต้องทำงานบนเซิร์ฟเวอร์เดียว โอเวอร์เฮดของระบบก็จะเพิ่มขึ้นอย่างมาก
ตัวเลือกใดดีที่สุด? ใน IIS 4.0 การหมดกระบวนการจะลดประสิทธิภาพลงอย่างมาก ใน IIS 5.0 มีการปรับปรุงหลายอย่างเพื่อลดค่าใช้จ่ายที่เกิดจากการเรียกใช้แอปพลิเคชัน ASP ที่ไม่อยู่ในกระบวนการ ในความเป็นจริง ในการทดสอบส่วนใหญ่ แอปพลิเคชัน ASP ที่ไม่อยู่ในกระบวนการใน IIS 5.0 ทำงานเร็วกว่าแอปพลิเคชันที่อยู่ระหว่างดำเนินการใน IIS 4.0 ไม่ว่าบนทั้งสองแพลตฟอร์ม ในกระบวนการ (ระดับการแยกต่ำ) จะทำงานได้ดีที่สุด อย่างไรก็ตาม หากอัตราการเข้าถึงค่อนข้างต่ำหรือปริมาณงานสูงสุดต่ำ ข้อดีของระดับการแยกต่ำจะชัดเจนน้อยลง ดังนั้น การตั้งค่าระดับการแยกต่ำอาจจำเป็นเฉพาะในกรณีที่คุณต้องการหลายร้อยหรือหลายพันเพจต่อวินาทีต่อเว็บเซิร์ฟเวอร์ และเช่นเคย ให้ทดสอบการกำหนดค่าหลายรายการเพื่อดูว่าคุณต้องการประนีประนอมแบบใด
โปรดทราบว่าเมื่อคุณเรียกใช้แอปพลิเคชัน ASP ที่ไม่อยู่ในกระบวนการ (การแยกระดับกลางหรือสูง) แอปพลิเคชันเหล่านี้จะทำงานใน MTS ใน NT4 และใน COM+ ใน Windows 2000 นั่นคือใน NT4 จะทำงานใน Mtx.exe; ใน Windows 2000 จะทำงานใน DllHost.exe คุณสามารถเห็นกระบวนการเหล่านี้ทำงานอยู่ในตัวจัดการงาน คุณยังสามารถดูว่า IIS กำหนดค่าแพ็คเกจ MTS หรือแอปพลิเคชัน COM+ สำหรับแอปพลิเคชัน ASP ที่ไม่อยู่ในกระบวนการได้อย่างไร
ตัวเลือก COM ส่วนประกอบ COM ยังมีตัวเลือกการกำหนดค่าสามตัวเลือก แม้ว่าจะไม่เหมือนกับตัวเลือก ASP ทุกประการก็ตาม ส่วนประกอบ COM สามารถ "ไม่ได้กำหนดค่า" กำหนดค่าเป็นแอปพลิเคชันไลบรารี หรือกำหนดค่าเป็นแอปพลิเคชันเซิร์ฟเวอร์ "ไม่ได้กำหนดค่า" หมายความว่าส่วนประกอบไม่ได้ลงทะเบียนกับ COM+ คอมโพเนนต์จะทำงานในพื้นที่กระบวนการของโปรแกรมที่เรียก นั่นคือคอมโพเนนต์ "อยู่ระหว่างดำเนินการ" แอปพลิเคชันไลบรารียังอยู่ระหว่างดำเนินการ แต่ใช้บริการ COM+ รวมถึงความปลอดภัย ธุรกรรม และการสนับสนุนบริบท แอปพลิเคชันเซิร์ฟเวอร์ได้รับการกำหนดค่าให้ทำงานภายในพื้นที่กระบวนการของตนเอง
คุณจะเห็นว่าส่วนประกอบที่ไม่ได้กำหนดค่ามีข้อได้เปรียบเหนือแอปพลิเคชันไลบรารีเล็กน้อย แอปพลิเคชันไลบรารีมีข้อได้เปรียบด้านประสิทธิภาพมากกว่าแอปพลิเคชันเซิร์ฟเวอร์ เนื่องจากแอปพลิเคชันไลบรารีทำงานในกระบวนการเดียวกับ ASP ในขณะที่แอปพลิเคชันเซิร์ฟเวอร์ทำงานในกระบวนการของตนเอง การโทรระหว่างกระบวนการมีราคาแพงกว่าการโทรภายในกระบวนการ นอกจากนี้ เมื่อส่งข้อมูล เช่น ชุดระเบียนระหว่างกระบวนการ ข้อมูลทั้งหมดจะต้องถูกคัดลอกระหว่างทั้งสองกระบวนการ
กับดัก! เมื่อใช้แอปพลิเคชันเซิร์ฟเวอร์ COM ถ้าคุณส่งวัตถุระหว่าง ASP และ COM ตรวจสอบให้แน่ใจว่าวัตถุดำเนินการ "รวมกลุ่มตามค่า" หรือ MBV วัตถุที่ทำ MBV จะคัดลอกตัวเองจากกระบวนการหนึ่งไปยังอีกกระบวนการหนึ่ง นี่เป็นการดีกว่าแนวทางที่วัตถุยังอยู่ในกระบวนการของผู้สร้าง และอีกกระบวนการหนึ่งเรียกกระบวนการสร้างซ้ำๆ เพื่อใช้วัตถุ ชุดระเบียน ADO ที่ตัดการเชื่อมต่อจะถูก "จัดกลุ่มตามค่า" ชุดระเบียนที่เชื่อมต่อจะไม่เป็นเช่นนั้น Scripting.Dictionary ไม่ทำงาน MBV และไม่ถูกส่งต่อระหว่างกระบวนการ สุดท้ายนี้ หมายเหตุถึงโปรแกรมเมอร์ VB: MBV ไม่ได้มาจากการส่งพารามิเตอร์ ByVal MBV ดำเนินการโดยผู้เขียนส่วนประกอบดั้งเดิม
จะทำอย่างไร?
หากเราถูกขอให้แนะนำการกำหนดค่าที่เหมาะสมที่สมดุลระหว่างประสิทธิภาพและความน่าเชื่อถือ สิ่งเหล่านี้จะเป็นดังนี้:
ใน IIS 4.0 ให้ใช้ ASP ระดับการแยกต่ำ และใช้แพ็คเกจเซิร์ฟเวอร์ MTS
บน IIS 5.0 ให้ใช้ระดับการแยกกลางของ ASP และใช้แอปพลิเคชันไลบรารี COM+
นี่เป็นหลักการทั่วไป บริษัทโฮสติ้งมักจะรัน ASP ในระดับการแยกกลางหรือสูง ในขณะที่เว็บเซิร์ฟเวอร์สำหรับวัตถุประสงค์เดียวสามารถทำงานได้ในระดับการแยกต่ำ ชั่งน้ำหนักข้อดีและข้อเสีย แล้วตัดสินใจด้วยตัวเองว่าการกำหนดค่าแบบใดที่เหมาะกับความต้องการของคุณมากที่สุด
เคล็ดลับ 10: ใช้ตัวเลือก
ตัวเลือกที่ชัดเจนควรใช้อย่างชัดเจนในไฟล์. asp คำสั่งนี้ถูกวางไว้ที่ด้านบนของไฟล์. asp และบังคับให้นักพัฒนาประกาศตัวแปรทั้งหมดที่จะใช้ โปรแกรมเมอร์จำนวนมากพบว่าวิธีนี้มีประโยชน์ในการดีบักแอปพลิเคชันเนื่องจากหลีกเลี่ยงความเป็นไปได้ของชื่อตัวแปรที่ผิดพลาดและการสร้างตัวแปรใหม่โดยไม่ตั้งใจ (ตัวอย่างเช่น myxmlString =) แทน myxlmstring = ....
บางทีที่สำคัญกว่านั้นตัวแปรที่ประกาศเร็วกว่าตัวแปรที่ไม่ได้ประกาศ ด้วยวิธีนี้ทุกครั้งที่สคริปต์ใช้ตัวแปรที่ไม่ได้ประกาศเมื่อรันไทม์จะอ้างอิงตามชื่อ ในทางกลับกันตัวแปรจะถูกประกาศตามลำดับไม่ว่าจะเป็นเวลาคอมไพล์หรือเวลาทำงาน จากนี้ไปตัวแปรที่ประกาศจะถูกอ้างอิงในลำดับนี้ เนื่องจากตัวเลือกการประกาศตัวแปรที่ชัดเจนของกองกำลังจึงทำให้มั่นใจได้ว่าตัวแปรทั้งหมดจะถูกประกาศดังนั้นการเข้าถึงจึงรวดเร็ว
เคล็ดลับที่ 11: ใช้ตัวแปรท้องถิ่นในรูทีนย่อยและฟังก์ชั่น
ตัวแปรท้องถิ่นคือตัวแปรที่ประกาศภายในรูทีนย่อยและฟังก์ชั่น ภายในฟังก์ชั่นหรือรูทีนย่อยการเข้าถึงตัวแปรในท้องถิ่นนั้นเร็วกว่าการเข้าถึงตัวแปรทั่วโลก การใช้ตัวแปรท้องถิ่นจะทำให้รหัสชัดเจนขึ้นดังนั้นควรใช้ตัวแปรท้องถิ่นทุกครั้งที่ทำได้
เคล็ดลับ 12: คัดลอกข้อมูลที่ใช้บ่อยลงในตัวแปรสคริปต์
เมื่อเข้าถึงวัตถุ COM ใน ASP ข้อมูลวัตถุที่ใช้บ่อยควรถูกคัดลอกไปยังตัวแปรสคริปต์ การทำเช่นนี้ช่วยลดการโทรวิธี COM ซึ่งค่อนข้างแพงเมื่อเทียบกับการเข้าถึงตัวแปรสคริปต์ เทคนิคนี้ยังช่วยลดการค้นหาที่มีราคาแพงเมื่อเข้าถึงคอลเลกชันและวัตถุพจนานุกรม
โดยทั่วไปหากคุณวางแผนที่จะเข้าถึงข้อมูลวัตถุมากกว่าหนึ่งครั้งคุณควรใส่ข้อมูลในตัวแปรสคริปต์ เป้าหมายหลักของการเพิ่มประสิทธิภาพนี้คือตัวแปรคำขอ (ตัวแปรแบบฟอร์มและแบบสอบถาม) ตัวอย่างเช่นเว็บไซต์ของคุณสามารถผ่านตัวแปร QueryString ชื่อผู้ใช้ USERID สมมติว่าผู้ใช้นี้อ้างอิงถึง 12 ครั้งในหน้าใดหน้าหนึ่ง แทนที่จะใช้คำขอเรียก (? userId?) 12 ครั้งคุณสามารถกำหนด USERID ให้กับตัวแปรที่ด้านบนของหน้า ASP จากนั้นใช้ตัวแปรนั้นตลอดทั้งหน้า สิ่งนี้จะช่วยประหยัดวิธีการที่ 11 COM
ในความเป็นจริงการเข้าถึงคุณสมบัติหรือวิธีการของ COM นั้นไม่แพงเลย นี่คือตัวอย่างของรหัสทั่วไปที่ค่อนข้างเป็นธรรม (การพูดทางไวยากรณ์):
foo.bar.blah.baz = foo.bar.blah.qaz (1)
ถ้า foo.bar.blah.zaq = foo.bar.blah.abc แล้ว '...
เมื่อรหัสนี้ทำงานนี่คือสิ่งที่เกิดขึ้น:
ตัวแปร FOO ได้รับการแก้ไขเป็นวัตถุทั่วโลก
แถบตัวแปรได้รับการแก้ไขในฐานะสมาชิกของ Foo นี่คือการเรียกวิธีการ com
ตัวแปร blah ได้รับการแก้ไขในฐานะสมาชิกของ foo.bar นี่เป็นวิธีการโทรหาวิธี COM อื่น
ตัวแปร qaz ได้รับการแก้ไขในฐานะสมาชิกของ foo.bar.blah ถูกต้องนี่ยังคงเป็นวิธีการเรียกใช้ COM
โทรหา foo.bar.blah.quaz (1) โทรหาวิธีการอื่น เข้าใจแล้ว?
ทำตามขั้นตอนที่ 1 ถึง 3 อีกครั้งเพื่อแยกวิเคราะห์ Baz ระบบไม่ทราบว่าการโทร QAZ เปลี่ยนโมเดลวัตถุหรือไม่ดังนั้นขั้นตอนที่ 1 ถึง 3 จะต้องดำเนินการอีกครั้งเพื่อแก้ไข BAZ
แก้ไข Baz ในฐานะสมาชิกของ foo.bar.blah กำหนดแอตทริบิวต์
ทำตามขั้นตอนที่ 1 ถึง 3 อีกครั้งเพื่อแยกวิเคราะห์ Zaq
ทำตามขั้นตอนที่ 1 ถึง 3 อีกครั้งเพื่อแยกวิเคราะห์ ABC
อย่างที่คุณเห็นประสิทธิภาพค่อนข้างแย่ (และช้า) วิธีที่รวดเร็วในการเขียนโค้ดนี้ใน VBScript คือ:
ตั้งค่า myobj = foo.bar.blah 'ทำความละเอียดของ blah ครั้งเดียว
myobj.baz = myobj.qaz (1)
ถ้า myobj.zaq = myobj.abc แล้ว '...
หากคุณใช้ vbscript 5.0 หรือสูงกว่าคุณสามารถเขียนรหัสนี้โดยใช้คำสั่งด้วย:
ด้วย foo.bar.blah
.BAZ = .QAZ (1)
ถ้า. zaq = .ABC แล้ว '...
-
จบด้วย
โปรดทราบว่าเทคนิคนี้ยังใช้กับการเขียนโปรแกรม VB
เคล็ดลับที่ 13: หลีกเลี่ยงอาร์เรย์ที่มีการลดขนาดใหม่
ควรหลีกเลี่ยงอาร์เรย์ Redim หากเป็นไปได้ ในแง่ของประสิทธิภาพหากคอมพิวเตอร์มีขนาดหน่วยความจำทางกายภาพที่ จำกัด จะเป็นการดีกว่าที่จะตั้งค่ามิติเริ่มต้นของอาร์เรย์ให้เป็นสถานการณ์ที่เลวร้ายที่สุด-หรือเพื่อกำหนดมิติให้เป็นสถานการณ์ที่ดีที่สุด ตามความจำเป็น นี่ไม่ได้หมายถึงการจัดสรรหน่วยความจำเพียงไม่กี่เมกะไบต์เมื่อคุณรู้ว่าคุณไม่ต้องการมัน
รหัสต่อไปนี้แสดงให้คุณเห็นการใช้ DIM และ REDIM ที่ไม่เหมาะสม
-
Dimmyarray ()
RedimmyArray (2)
MyArray (0) =? สวัสดี?
MyArray (1) =? ลาก่อน?
MyArray (2) =? อำลา?
-
'รหัสอื่น ๆ ที่คุณต้องการพื้นที่มากขึ้นแล้ว ...
Redim Preserve MyArray (5)
MyArray (3) =?
MyArray (4) =?
MyArray (5) =? ยังมีอีกมาก?
%>
มันจะดีกว่ามากที่จะหรี่ขนาดเริ่มต้นของอาร์เรย์อย่างถูกต้องตั้งแต่ต้น (ในกรณีนี้ 5) มากกว่าที่จะปรับอาร์เรย์ให้มากขึ้นเพื่อให้มันใหญ่ขึ้น คุณอาจเสียความทรงจำบางอย่าง (ถ้าคุณไม่ได้ใช้องค์ประกอบทั้งหมด) แต่ประโยชน์ก็คือมันจะเร็วขึ้น
เคล็ดลับ 14: ใช้บัฟเฟอร์การตอบสนอง
คุณสามารถบัฟเฟอร์ทั้งหน้าของเอาต์พุตโดยเปิดใช้งาน "การตอบสนองการตอบสนอง" สิ่งนี้จะช่วยลดจำนวนการเขียนไปยังเบราว์เซอร์เพื่อปรับปรุงประสิทธิภาพโดยรวม การดำเนินการเขียนแต่ละครั้งมีค่าใช้จ่ายอย่างมีนัยสำคัญ (ทั้งใน IIS และในแง่ของจำนวนข้อมูลที่ส่งผ่านเครือข่าย) ดังนั้นยิ่งเขียนน้อยลง เนื่องจากการเริ่มต้นอย่างช้าๆและการใช้อัลกอริทึม Nagling (ใช้เพื่อบรรเทาความแออัดของเครือข่าย) TCP/IP จึงมีประสิทธิภาพมากขึ้นเมื่อส่งข้อมูลจำนวนมากน้อยกว่าเมื่อต้องส่งชิ้นเล็ก ๆ จำนวนมาก
มีสองวิธีในการเปิดใช้งานบัฟเฟอร์การตอบสนอง ก่อนอื่นคุณสามารถใช้ Internet Services Manager เพื่อเปิดใช้งานการบัฟเฟอร์การตอบกลับสำหรับแอปพลิเคชันทั้งหมด เราขอแนะนำวิธีการนี้เปิดใช้งานการบัฟเฟอร์การตอบกลับโดยค่าเริ่มต้นสำหรับแอปพลิเคชัน ASP ใหม่ใน IIS 4.0 และ IIS 5.0 ประการที่สองคุณสามารถเปิดใช้งานบัฟเฟอร์การตอบกลับได้โดยการเพิ่มบรรทัดของรหัสต่อไปนี้ใกล้กับด้านบนของแต่ละหน้า ASP:
< % response.buffer = true %>
บรรทัดของรหัสนี้จะต้องดำเนินการก่อนที่ข้อมูลการตอบกลับใด ๆ จะถูกเขียนไปยังเบราว์เซอร์ (นั่นคือก่อนที่ HTML ใด ๆ จะปรากฏในสคริปต์ ASP และก่อนที่จะตั้งค่าคุกกี้ใด ๆ โดยใช้การตอบสนองการรวบรวม Cookies) โดยทั่วไปแล้วควรเปิดใช้งานการตอบสนองการตอบสนองสำหรับแอปพลิเคชันทั้งหมด ด้วยวิธีนี้คุณไม่จำเป็นต้องเขียนบรรทัดของโค้ดด้านบนที่ด้านบนของทุกหน้า
การตอบสนองฟลัช
การร้องเรียนทั่วไปเกี่ยวกับการบัฟเฟอร์การตอบสนองคือผู้ใช้รับรู้หน้า ASP ช้าในการตอบสนอง (แม้ว่าเวลาตอบสนองโดยรวมจะดีขึ้น) เพราะพวกเขาต้องรอจนกว่าทั้งหน้าจะถูกสร้างขึ้นก่อนที่พวกเขาจะเห็นอะไร สำหรับหน้าระยะยาวคุณสามารถตั้งค่าการตอบสนอง Buffer = FALSE เพื่อปิดการใช้งานบัฟเฟอร์การตอบสนอง อย่างไรก็ตามกลยุทธ์ที่ดีกว่าคือการใช้วิธีการตอบสนอง วิธีนี้ส่ง HTML ทั้งหมดที่แปลงโดย ASP ไปยังเบราว์เซอร์ ตัวอย่างเช่นหลังจากแปลง 100 แถวแรกของตาราง 1,000 แถว ASP สามารถเรียกตอบกลับฟลัชเพื่อบังคับให้ผลลัพธ์ของการแปลงเป็นเบราว์เซอร์ทำให้ผู้ใช้สามารถดู 100 แถวแรกก่อนที่แถวที่เหลือจะพร้อม เทคนิคนี้รวมการบัฟเฟอร์การตอบสนองเข้ากับเบราว์เซอร์ค่อยๆแสดงข้อมูล
(โปรดทราบว่าในตัวอย่างตาราง 1,000 แถวด้านบนเบราว์เซอร์จำนวนมากจะไม่เริ่มแสดงตารางจนกว่าพวกเขาจะเห็นแท็กปิด </ster> ตรวจสอบว่าเบราว์เซอร์เป้าหมายของคุณรองรับหรือไม่ แถวที่น้อยลงและการตอบกลับฟลัชหลังจากแต่ละตาราง ความกว้างของเนื้อหาของแต่ละเซลล์)
การร้องเรียนทั่วไปอีกประการหนึ่งเกี่ยวกับการบัฟเฟอร์การตอบสนองคือการใช้หน่วยความจำเซิร์ฟเวอร์จำนวนมากเมื่อมีการผลิตหน้าเว็บขนาดใหญ่มาก โดยไม่คำนึงถึงวิธีการสร้างหน้าขนาดใหญ่ปัญหานี้ยังสามารถแก้ไขได้ด้วยการใช้การตอบสนองอย่างชาญฉลาดฟลัช
เคล็ดลับที่ 15: สคริปต์แบบฝังตัวและการตอบสนองคำสั่ง Wyntax
VBScript < % = expression %> เขียนค่าของ "นิพจน์" ไปยังสตรีมเอาต์พุต ASP หากไม่ได้เปิดใช้งานการบัฟเฟอร์การตอบสนองแต่ละคำสั่งที่ดำเนินการจะเขียนข้อมูลไปยังเบราว์เซอร์ในแพ็คเก็ตขนาดเล็กจำนวนมากผ่านเครือข่าย นี่ช้ามาก ยิ่งไปกว่านั้นการดำเนินการสลับกับสคริปต์จำนวนเล็กน้อยและ HTML จะทำให้เกิดการสลับระหว่างเอ็นจิ้นสคริปต์และ HTML ซึ่งจะช่วยลดประสิทธิภาพ ดังนั้นใช้เคล็ดลับต่อไปนี้: ใช้การตอบสนองการโทรหาการโทรแทนการแสดงออกแบบอินไลน์ที่รวมกันอย่างแน่นหนา ตัวอย่างเช่นในตัวอย่างต่อไปนี้มีหนึ่งเขียนไปยังสตรีมตอบสนองต่อฟิลด์ต่อแถวและมีสวิตช์มากมายระหว่าง VBScript และ HTML ต่อแถว:
<Table>
< % สำหรับแต่ละ FLD ใน Rs.Fields %>
<th> < % = fld.name %> </th>
-
ต่อไป
ในขณะที่ไม่ใช่ Rs.EOF
-
<tr>
< % สำหรับแต่ละ FLD ใน Rs.Fields %>
<td> < % = fld.Value %> </td>
<% ถัดไป
</tr>
<% Rs.Movenext
เวน %>
</ตาราง>
รหัสด้านล่างมีประสิทธิภาพมากขึ้นโดยมีหนึ่งเขียนไปยังสตรีมตอบกลับต่อบรรทัด โค้ดทั้งหมดอยู่ในบล็อก VBScript:
<table>
-
สำหรับแต่ละ FLD ใน Rs.Fields
Response.write (? <th>? & fld.name &? </th>? & vbcrlf)
ต่อไป
ในขณะที่ไม่ใช่ Rs.EOF
Response.write (? <tr>?)
สำหรับแต่ละ FLD ใน Rs.Fields %>
Response.write (? <td>? & fld.value &? </td>? & vbcrlf)
ต่อไป
Response.write? </tr>?
เวนด์
-
</ตาราง>
เคล็ดลับนี้ใช้งานได้ดีโดยเฉพาะอย่างยิ่งเมื่อบัฟเฟอร์การตอบสนองถูกปิดใช้งาน เป็นความคิดที่ดีที่จะเปิดใช้งานบัฟเฟอร์การตอบสนองและดูว่าการตอบสนองแบบแบทช์การเขียนช่วยปรับปรุงประสิทธิภาพหรือไม่
(ในตัวอย่างนี้โดยเฉพาะลูปซ้อนที่สร้างร่างกายของตาราง (ในขณะที่ไม่ใช่ Rs.EOF ... ) สามารถถูกแทนที่ด้วยการโทรที่สร้างขึ้นอย่างระมัดระวัง)
เคล็ดลับ 16: หากหน้านั้นใช้เวลานานกว่าจะเสร็จสมบูรณ์ ทำถ้าผู้ใช้ใจร้อนก่อนที่จะใช้การตอบสนองที่เชื่อมต่อกัน
พวกเขาอาจละทิ้งหน้า ASP ก่อนที่คุณจะเริ่มดำเนินการตามคำขอของพวกเขา หากพวกเขาคลิกรีเฟรชหรือย้ายไปยังหน้าอื่นบนเซิร์ฟเวอร์มีคำขอใหม่รออยู่ท้ายคิวคำขอ ASP และคำขอที่ตัดการเชื่อมต่อที่อยู่ตรงกลางของคิว สิ่งนี้มักจะเกิดขึ้นเมื่อโหลดบนเซิร์ฟเวอร์สูง (และดังนั้นคิวการร้องขอนั้นยาวและเวลาตอบสนองยาวตามลำดับ) ซึ่งทำให้สถานการณ์แย่ลงเท่านั้น ไม่มีจุดในการดำเนินการหน้า ASP (โดยเฉพาะอย่างยิ่งหน้า ASP ที่ช้าและมีขนาดใหญ่) หากผู้ใช้ไม่ได้เชื่อมต่ออีกต่อไป คุณสามารถตรวจสอบสิ่งนี้ได้โดยใช้คุณสมบัติ Response.IsclientConnected หากส่งคืนเท็จควรเรียกใช้และส่วนที่เหลือของหน้าควรถูกยกเลิก ในความเป็นจริง IIS 5.0 มีพฤติกรรมนี้ตั้งโปรแกรมไว้ - ทุกครั้งที่ ASP กำลังดำเนินการตามคำขอใหม่จะตรวจสอบระยะเวลาที่คำขอรออยู่ในคิว หากรออยู่ที่นั่นนานกว่า 3 วินาที ASP จะตรวจสอบว่าลูกค้ายังคงเชื่อมต่อหรือไม่และหากไม่ได้ยกเลิกคำขอทันที คุณสามารถปรับการหมดเวลาจาก 3 วินาทีไปยังค่าอื่นโดยใช้การตั้งค่า AspqueUeconnectionTestTime ในเมตาบัส
นอกจากนี้คุณยังสามารถตรวจสอบการตอบสนองการเชื่อมต่อที่เชื่อมต่อเป็นครั้งคราวหากหน้าเว็บใช้เวลานานกว่าจะเสร็จสมบูรณ์ เมื่อเปิดใช้งานการบัฟเฟอร์การตอบสนองเป็นความคิดที่ดีที่จะทำการตอบสนองฟลัชเป็นครั้งคราวเพื่อแจ้งให้ผู้ใช้ทราบว่าเกิดอะไรขึ้น
โปรดทราบว่าใน IIS 4.0, Response.IsclientConnected จะทำงานไม่ถูกต้องเว้นแต่การตอบสนองการเขียนจะถูกดำเนินการก่อน หากเปิดใช้งานการบัฟเฟอร์คุณต้องทำการตอบสนองด้วย ใน IIS 5.0 ไม่จำเป็นต้องทำเช่นนี้ - การตอบสนองการใช้งานที่เชื่อมต่อกันทำงานได้ดี ไม่ว่าในกรณีใดการตอบสนองที่เชื่อมต่อจะมีค่าใช้จ่ายบางอย่างดังนั้นหากการดำเนินการใช้เวลาอย่างน้อย (พูด) 500 มิลลิวินาที (เป็นเวลานานถ้าคุณต้องการรักษาปริมาณงานของหลายสิบหน้าต่อวินาที) เพียงแค่ใช้มัน ประสบการณ์แสดงให้เห็นว่าคุณไม่ควรเรียกมันว่าทุกครั้งที่มีการดำเนินการลูปแน่นซ้ำ ๆ เช่นเมื่อแสดงตารางหลายแถว - เรียกมันว่าทุก ๆ ยี่สิบหรือห้าสิบแถวอาจเหมาะสม
เคล็ดลับ 17: ใช้แท็ก <jobch> สำหรับวัตถุอินสแตนซ์
หากคุณต้องการอ้างอิงวัตถุที่ไม่ได้ใช้ในพา ธ รหัสทั้งหมด (โดยเฉพาะวัตถุเซิร์ฟเวอร์หรือแอปพลิเคชันที่ถูกปิด การประกาศใน global.asa พวกเขาแทนที่จะใช้วิธีเซิร์ฟเวอร์สร้างวิธีการสร้าง Server.CreateObject สร้างวัตถุทันที หากคุณไม่ได้ใช้วัตถุในอนาคตคุณจะสูญเสียทรัพยากร แท็ก <object id = objname> ประกาศ objname แต่ objname ไม่ได้ถูกสร้างขึ้นจนกว่าวิธีการหรือคุณสมบัติจะถูกใช้เป็นครั้งแรก
นี่เป็นอีกตัวอย่างหนึ่งของการประเมินที่ขี้เกียจ
เคล็ดลับ 18: ใช้การประกาศ Typelib สำหรับ ADO และส่วนประกอบอื่น ๆ
เมื่อใช้ ADO นักพัฒนามักจะเพิ่ม ADOVBS.txt เพื่อเข้าถึงค่าคงที่ ADO ต่างๆ ไฟล์นี้จะต้องรวมอยู่ในทุกหน้าที่จะใช้ค่าคงที่ ไฟล์คงที่นี้ค่อนข้างใหญ่เพิ่มค่าใช้จ่ายจำนวนมากในเวลาการรวบรวมและขนาดสคริปต์ของแต่ละหน้า ASP
IIS 5.0 แนะนำความสามารถในการผูกกับไลบรารีประเภทส่วนประกอบ สิ่งนี้ช่วยให้คุณสามารถอ้างอิงไลบรารีประเภทหนึ่งครั้งและใช้ในทุกหน้า ASP ไม่มีค่าใช้จ่ายในการรวบรวมไฟล์คงที่สำหรับแต่ละหน้าและนักพัฒนาส่วนประกอบไม่จำเป็นต้องสร้างไฟล์ vbscript#_include สำหรับใช้กับ ASP
ในการเข้าถึง ADO Typelib ให้วางข้อความต่อไปนี้ใน global.asa
<!- metadata name =? Microsoft Activex Data Object 2.5 ไลบรารี?
type =? typelib?
หรือ
<!- metadata type =? typelib?
file =? c: Program Files Common Files System Ado
Msado15.dll
? บริการให้การสนับสนุน ใช้คุณสมบัติเหล่านี้เมื่อเป็นไปได้ เทคโนโลยีทั้งหมดเหล่านี้ดำเนินการตรวจสอบฝั่งไคลเอ็นต์และการแคชข้อมูลทำให้ไม่จำเป็นต้องเดินทางไปกลับไปยังเว็บเซิร์ฟเวอร์ หากคุณใช้เบราว์เซอร์อัจฉริยะเบราว์เซอร์สามารถตรวจสอบความถูกต้องสำหรับคุณ (ตัวอย่างเช่นตรวจสอบว่าการตรวจสอบบัตรเครดิตนั้นถูกต้องก่อนที่จะทำการโพสต์) ใช้คุณสมบัตินี้เมื่อเป็นไปได้ ด้วยการลดการเดินทางไปกลับของไคลเอนต์-เซิร์ฟเวอร์คุณจะลดการโหลดบนเว็บเซิร์ฟเวอร์และลดทราฟฟิกเครือข่าย (แม้ว่าหน้าแรกที่ส่งไปยังเบราว์เซอร์อาจมีขนาดใหญ่กว่า) และทรัพยากรแบ็คเอนด์ใด ๆ ที่เซิร์ฟเวอร์เข้าถึงได้ นอกจากนี้ผู้ใช้ไม่จำเป็นต้องอ่านหน้าใหม่ตามปกติดังนั้นผู้ใช้จึงรู้สึกดีขึ้น การทำเช่นนี้ไม่ได้หมายความว่าคุณสามารถข้ามการตรวจสอบด้านเซิร์ฟเวอร์-คุณควรทำการตรวจสอบฝั่งเซิร์ฟเวอร์ด้วยเช่นกัน สิ่งนี้จะช่วยป้องกันไม่ให้ไคลเอนต์สร้างข้อมูลที่ไม่ถูกต้องด้วยเหตุผลบางประการ (เช่นแฮ็กเกอร์หรือเบราว์เซอร์ที่ไม่ใช้งานการตรวจสอบความถูกต้องฝั่งไคลเอ็นต์)
งานจำนวนมากได้พัฒนา HTML "เบราว์เซอร์อิสระ" ด้วยความกังวลนี้นักพัฒนาจึงลังเลที่จะใช้คุณสมบัติเบราว์เซอร์ยอดนิยมที่สามารถปรับปรุงประสิทธิภาพได้ สำหรับเว็บไซต์ที่มีประสิทธิภาพสูงอย่างแท้จริงปัญหา "การเข้าถึง" ของเบราว์เซอร์จะต้องเกี่ยวข้องและกลยุทธ์ที่ดีคือการเพิ่มประสิทธิภาพหน้าเพื่อปรับให้เข้ากับเบราว์เซอร์ยอดนิยม ความสามารถของเบราว์เซอร์สามารถตรวจพบได้อย่างง่ายดายใน ASP โดยใช้ส่วนประกอบความสามารถของเบราว์เซอร์ เครื่องมือเช่น Microsoft FrontPage ช่วยออกแบบรหัสที่เหมาะสมสำหรับเบราว์เซอร์และ HTML รุ่นเฉพาะ ดูว่าเมื่อไหร่จะแย่กว่ากัน? การชั่งน้ำหนักการแลกเปลี่ยนเทคโนโลยีเพื่อการอภิปรายเพิ่มเติม
เคล็ดลับที่ 20: หลีกเลี่ยงการใช้การเชื่อมต่อสตริงในลูป
หลายคนสร้างสตริงในลูปเช่นนี้:
s =?
สำหรับแต่ละ FLD ใน Rs.Fields
s = s &? <th>? & fld.name &?
ถัดไป
ในขณะที่ไม่ใช่ Rs.EOF
s = s & vbcrlf &? <tr>?
สำหรับแต่ละ FLD ใน Rs.Fields
s = s &? <td>? & fld.value &?
ต่อไป
s = s &? </tr>?
rs.MoveNext
Wend
S = S & VBCRLF &? </table>? & vbcrlf
Response.write s
ปัญหาบางอย่างเกิดขึ้นกับวิธีการนี้ ปัญหาแรกคือสตริงที่ต่อกันซ้ำ ๆ ต้องใช้เวลากับพลังของสอง ตัวอย่างที่ง่ายกว่าจะแสดงปัญหานี้ชัดเจนยิ่งขึ้น
s = ??
สำหรับ i = asc (? a?) ถึง asc (? z?)
S = S & Chr (i)
ต่อไป
ในการทำซ้ำครั้งแรกคุณจะได้รับสตริงตัวอักษรเดียว? ในการทำซ้ำครั้งที่สอง VBScript จะต้องจัดสรรสตริงใหม่และคัดลอกสองอักขระ (? ab?) ลงใน s ในการทำซ้ำครั้งที่สามมันจะต้องจัดสรร S อีกครั้งและคัดลอกสามอักขระลงใน s ในการทำซ้ำ N (26) มันจะต้องจัดสรรใหม่และคัดลอกอักขระ n ลงใน s ยอดรวมคือ 1+2+3+...+n นั่นคือ n*(n+1)/2 สำเนา
ในตัวอย่างชุดบันทึกข้างต้นหากมี 100 ระเบียนและ 5 ฟิลด์ลูปด้านในจะถูกดำเนินการ 100*5 = 500 ครั้งและเวลาที่ใช้ในการคัดลอกและการจัดสรรใหม่ทั้งหมดเป็นสัดส่วน 500*500 = 250,000 นี่คือการดำเนินการคัดลอกมากเกินไปสำหรับชุดระเบียนขนาดปานกลาง
ในกรณีนี้รหัสสามารถปรับปรุงได้โดยใช้ response.write () หรือการเขียนสคริปต์แบบอินไลน์ (< % = fld.Value %>) แทนการต่อกันของสตริง หากเปิดใช้งานการบัฟเฟอร์การตอบกลับ (ควร) สิ่งนี้จะเร็วขึ้นเนื่องจากการตอบสนองการเขียนจะผนวกข้อมูลไปยังจุดสิ้นสุดของบัฟเฟอร์การตอบกลับเท่านั้น ไม่มีการจัดสรรใหม่ที่เกี่ยวข้องดังนั้นจึงมีประสิทธิภาพมาก
ในกรณีเฉพาะของการแปลงชุดบันทึก ADO เป็นตาราง HTML คุณควรพิจารณาใช้ getrows หรือ getString
หากคุณกำลังเชื่อมต่อสตริงใน JScript ขอแนะนำโดยเฉพาะอย่างยิ่งในการใช้ตัวดำเนินการ += นั่นคือใช้ S +=? สตริง?
เคล็ดลับที่ 21: เปิดใช้งานเบราว์เซอร์และการแคชพร็อกซี
โดยค่าเริ่มต้น ASP ปิดการใช้งานการแคชในเบราว์เซอร์และพร็อกซี สิ่งนี้สมเหตุสมผลเพราะหน้า ASP นั้นเป็นไปตามธรรมชาติแบบไดนามิกด้วยข้อมูลพื้นฐานที่เปลี่ยนแปลงตลอดเวลา หากหน้าไม่จำเป็นต้องมีการรีเฟรชในทุกมุมมองคุณควรเปิดใช้งานเบราว์เซอร์และการแคชพร็อกซี สิ่งนี้ช่วยให้เบราว์เซอร์และพร็อกซีใช้สำเนา "แคช" ของหน้าเว็บในระยะเวลาหนึ่งความยาวที่คุณสามารถควบคุมได้ การแคชสามารถลดการโหลดบนเซิร์ฟเวอร์ได้อย่างมากและลดเวลารอของผู้ใช้ให้สั้นลง
หน้าไดนามิกใดที่สามารถใช้เป็นหน้าเว็บที่จะแคชได้ นี่คือตัวอย่างบางส่วน:
หน้าพยากรณ์อากาศในหน้านี้การพยากรณ์อากาศได้รับการปรับปรุงทุก 5 นาที
รายการโฮมเพจรายการข่าวหรือการเผยแพร่อัปเดตวันละสองครั้ง
รายการประสิทธิภาพของกองทุนรวมที่มีการปรับปรุงสถิติพื้นฐานทุกสองสามชั่วโมง
โปรดทราบว่าเมื่อใช้เบราว์เซอร์หรือการแคชพร็อกซีจำนวนการเข้าชมที่บันทึกไว้บนเว็บเซิร์ฟเวอร์จะลดลง หากคุณต้องการวัดมุมมองหรือโพสต์ทั้งหมดอย่างถูกต้องคุณไม่ต้องการใช้เบราว์เซอร์และการแคชพร็อกซี
การแคชเบราว์เซอร์ถูกควบคุมโดยส่วนหัว "หมดอายุ" HTTP ซึ่งถูกส่งไปยังเบราว์เซอร์โดยเว็บเซิร์ฟเวอร์ ASP มีกลไกง่ายๆสองประการสำหรับการส่งส่วนหัวนี้ หากต้องการตั้งค่าจำนวนนาทีหลังจากนั้นหน้าจะหมดอายุให้ตั้งค่าคุณสมบัติการตอบสนอง ตัวอย่างต่อไปนี้บอกเบราว์เซอร์ว่าเนื้อหาจะหมดอายุใน 10 นาที:
< % การตอบสนอง expires = 10 %>
การตั้งค่าการตอบสนองที่มีจำนวนลบหรือ 0 ปิดใช้งานการแคช ตรวจสอบให้แน่ใจว่าใช้จำนวนลบจำนวนมากเช่น -1000 (มากกว่าหนึ่งวัน) เพื่อหลีกเลี่ยงการไม่ตรงกันระหว่างนาฬิกาเซิร์ฟเวอร์และเบราว์เซอร์ คุณสมบัติที่สองคือ Response.expiresabsolute จะช่วยให้คุณกำหนดเวลาเฉพาะเมื่อเนื้อหาจะหมดอายุ:
< % การตอบสนอง expiresabsolute = #may 31,2001 13: 30: 15 # %>
แทนที่จะใช้วัตถุตอบสนองเพื่อตั้งค่าเวลาหมดอายุคุณสามารถเขียนแท็ก <meta> ลงใน HTML โดยปกติจะอยู่ในส่วน <head> ของไฟล์ HTML เบราว์เซอร์บางตัวจะเคารพคำสั่งนี้ในขณะที่ผู้รับมอบฉันทะจะไม่
<meta http-equiv =? Expires?
ในที่สุดคุณสามารถใช้คุณสมบัติการตอบสนอง cachecontrol เพื่อระบุว่าเนื้อหาของมันสามารถแคชได้โดยพร็อกซี HTTP หรือไม่ การตั้งค่าคุณสมบัตินี้เป็น "สาธารณะ" ช่วยให้พร็อกซีสามารถแคชเนื้อหานี้ได้
< % response.cachecontrol =? %? %>
โดยค่าเริ่มต้นคุณสมบัตินี้ถูกตั้งค่าเป็น "ส่วนตัว" โปรดทราบว่าไม่ควรเปิดใช้งานการแคชพร็อกซีสำหรับหน้าเว็บที่แสดงข้อมูลเฉพาะกับผู้ใช้เนื่องจากพร็อกซีอาจให้บริการหน้าผู้ใช้ที่เป็นของผู้ใช้รายอื่น
เคล็ดลับที่ 22: ใช้เซิร์ฟเวอร์การถ่ายโอนแทนการตอบสนองการแก้ไขเมื่อใดก็ตามที่เป็นไป
ได้ ฟังก์ชั่นนี้มักใช้เพื่อเปลี่ยนเส้นทางผู้ใช้ไปยังหน้าเข้าสู่ระบบหรือหน้าข้อผิดพลาด เนื่องจากการเปลี่ยนเส้นทางบังคับให้มีการร้องขอหน้าใหม่ผลลัพธ์คือเบราว์เซอร์จะต้องทำการเดินทางรอบสองไปยังเว็บเซิร์ฟเวอร์และเว็บเซิร์ฟเวอร์จะต้องจัดการอีกหนึ่งคำขอ IIS 5.0 แนะนำเซิร์ฟเวอร์ฟังก์ชั่นใหม่การถ่ายโอนซึ่งถ่ายโอนการดำเนินการไปยังหน้า ASP อื่นบนเซิร์ฟเวอร์เดียวกัน สิ่งนี้จะช่วยหลีกเลี่ยงการเดินทางไปกลับเบราว์เซอร์เบราว์เซอร์-เซิร์ฟเวอร์ซ้ำซ้อนปรับปรุงประสิทธิภาพของระบบโดยรวมและเวลาตอบสนองของผู้ใช้ ตรวจสอบ "ทิศทางใหม่" ใน "การเปลี่ยนเส้นทาง" ควรเป็นเซิร์ฟเวอร์การถ่ายโอนและเซิร์ฟเวอร์ execute
ดูการใช้ประโยชน์จาก ASP ใน IIS 5.0 สำหรับรายการคุณสมบัติใหม่ที่สมบูรณ์ใน IIS 5.0 และ ASP 3.0
เคล็ดลับ 23: ใช้แบ็คสแลชใน URL ไดเรกทอรี
เคล็ดลับที่เกี่ยวข้องคือการทำให้แน่ใจว่าคุณใช้ backslash (/) ใน URL ที่ชี้ไปที่ไดเรกทอรี หากคุณละเว้นสแลชต่อท้ายเบราว์เซอร์จะทำการร้องขอไปยังเซิร์ฟเวอร์เพื่อบอกเซิร์ฟเวอร์ว่ากำลังขอไดเรกทอรี เบราว์เซอร์ทำการร้องขอครั้งที่สองต่อท้าย Slash กับ URL และจากนั้นเซิร์ฟเวอร์สามารถตอบกลับด้วยเอกสารเริ่มต้นของไดเรกทอรีหรือรายการไดเรกทอรี (หากไม่มีเอกสารเริ่มต้นและเปิดใช้งานการเรียกดูไดเรกทอรี) การต่อท้ายสแลชกำจัดการกลับมาที่ไร้ประโยชน์ครั้งแรก เพื่อให้ผู้ใช้อ่านได้ง่ายขึ้น Slash ในชื่อการแสดงผลสามารถละเว้นได้
ตัวอย่างเช่นเขียน:
<a href =? http: //msdn.microsoft.com/workshop/? title =? msdn web
เวิร์กช็อป?> http://msdn.microsoft.com/workshop </a>
สิ่งนี้ใช้กับ URL ที่ชี้ไปที่โฮมเพจบนเว็บไซต์: ใช้สิ่งต่อไปนี้: <a href =? http: //msdn.microsoft.com/?> แทนที่จะเป็น <a href =? http: //msdn.microsoft . com?>.
เคล็ดลับ 24: หลีกเลี่ยงการใช้ตัวแปร
เซิร์ฟเวอร์ สถานการณ์คล้ายกับการค้นหาไฟล์ในโฟลเดอร์ในห้องใต้หลังคา เมื่อคุณต้องการค้นหาเอกสารนั้นคุณต้องไปที่ห้องใต้หลังคาค้นหาโฟลเดอร์แล้วค้นหาเอกสาร สิ่งเดียวกันนี้เกิดขึ้นเมื่อคุณขอตัวแปรเซิร์ฟเวอร์ - ครั้งแรกที่คุณขอตัวแปรเซิร์ฟเวอร์ประสิทธิภาพ คำขอที่ตามมาไปยังตัวแปรเซิร์ฟเวอร์อื่น ๆ จะไม่มีผลกระทบต่อประสิทธิภาพ
อย่าเข้าถึงวัตถุคำขอที่ไม่มีเงื่อนไข (ตัวอย่างเช่นคำขอ ("ข้อมูล")) request.serverVariables เรียกว่าโดยปริยายสำหรับรายการที่ไม่ได้อยู่ในคำขอ. cookies, request.form, request.querystring หรือ request.clientcertificate คอลเลกชัน ServerVariables นั้นช้ากว่าคอลเลกชันอื่น ๆ มาก
เคล็ดลับ 25: การอัพเกรดเป็น
ส่วนประกอบของระบบล่าสุดและยิ่งใหญ่ที่สุดนั้นเป็นค่าคงที่และเราขอแนะนำให้คุณอัปเกรดเป็นการกำหนดค่าล่าสุดและยิ่งใหญ่ที่สุด เป็นการดีที่สุดที่จะอัพเกรดเป็น Windows 2000 (และดังนั้น IIS 5.0, ADO 2.5, MSXML 2.5, Internet Explorer 5.0, VBScript 5.1 และ JScript 5.1) ในคอมพิวเตอร์หลายโปรเซสเซอร์การใช้ IIS 5.0 และ ADO 2.5 สามารถปรับปรุงประสิทธิภาพได้อย่างมีนัยสำคัญ ภายใต้ Windows 2000, ASP ปรับขนาดได้ดีถึงสี่โปรเซสเซอร์ขึ้นไปในขณะที่ภายใต้ IIS 4.0, ASP ไม่ได้ปรับขนาดเกินสองโปรเซสเซอร์ ยิ่งรหัสสคริปต์และ ADO ที่คุณใช้ในแอปพลิเคชันของคุณมากเท่าไหร่คุณก็จะได้รับการปรับปรุงประสิทธิภาพมากขึ้นหลังจากอัพเกรดเป็น Windows 2000
หากคุณไม่สามารถอัปเกรดเป็น Windows 2000 ได้คุณสามารถอัปเกรดเป็น SQL Server, ADO, VBScript และ JScript, MSXML, Internet Explorer และชุดบริการ NT 4 รุ่นล่าสุด พวกเขาทั้งสองปรับปรุงประสิทธิภาพและความน่าเชื่อถือ
เคล็ดลับ 26: เพิ่มประสิทธิภาพเว็บเซิร์ฟเวอร์
มีพารามิเตอร์การเพิ่มประสิทธิภาพ IIS ที่หลากหลายซึ่งสามารถปรับปรุงประสิทธิภาพของไซต์ได้ ตัวอย่างเช่นด้วย IIS 4.0 เรามักจะพบว่าการเพิ่มพารามิเตอร์ ASP ProcessOrthreadMax (ดูเอกสาร IIS) สามารถปรับปรุงประสิทธิภาพได้อย่างมีนัยสำคัญโดยเฉพาะอย่างยิ่งในเว็บไซต์ที่มีแนวโน้มที่จะรอทรัพยากรแบ็คเอนด์ (เช่นฐานข้อมูล) หรือผลิตภัณฑ์ระดับกลางอื่น ๆ (เช่น เป็นแปรงหน้าจอ) ใน IIS 5.0 คุณอาจพบว่าการเปิดใช้งานเธรด gating นั้นมีประสิทธิภาพมากกว่าการหาการตั้งค่าที่ดีที่สุดสำหรับ AspprocessorthreadMax ซึ่งตอนนี้เป็นที่รู้จักกันดี
สำหรับการอ้างอิงที่ดีให้ดูการเพิ่มประสิทธิภาพ IIS ด้านล่าง
การตั้งค่าการกำหนดค่าที่ดีที่สุดขึ้นอยู่กับปัจจัยอื่น ๆ รหัสแอปพลิเคชันฮาร์ดแวร์ระบบที่กำลังทำงานอยู่และภาระงานของไคลเอนต์ วิธีเดียวที่จะค้นหาการตั้งค่าที่ดีที่สุดคือการทดสอบประสิทธิภาพซึ่งเราจะพูดคุยกันในเคล็ดลับถัดไป
เคล็ดลับ 27: ดำเนินการทดสอบประสิทธิภาพ
ตามที่เราได้กล่าวไว้ก่อนหน้านี้ประสิทธิภาพเป็นลักษณะ หากคุณต้องการปรับปรุงประสิทธิภาพของเว็บไซต์ให้ตั้งเป้าหมายประสิทธิภาพและค่อยๆปรับปรุงจนกว่าคุณจะไปถึง ไม่จะไม่มีการทดสอบประสิทธิภาพ บ่อยครั้งในตอนท้ายของโครงการมันสายเกินไปที่จะทำการเปลี่ยนแปลงโครงสร้างที่จำเป็นและลูกค้าของคุณจะผิดหวัง ดำเนินการทดสอบประสิทธิภาพเป็นส่วนหนึ่งของกิจวัตรการทดสอบของคุณ คุณสามารถทำการทดสอบประสิทธิภาพในแต่ละองค์ประกอบเป็นรายบุคคลเช่นหน้า ASP หรือวัตถุ COM หรือบนเว็บไซต์โดยรวม
หลายคนใช้เบราว์เซอร์เดียวเพื่อขอหน้าเพื่อทดสอบประสิทธิภาพของเว็บไซต์ การทำเช่นนี้จะทำให้คุณรู้สึกว่าเว็บไซต์ของคุณตอบสนองได้ แต่มันจะไม่บอกคุณว่าเว็บไซต์ของคุณทำงานได้อย่างไรภายใต้การโหลด
โดยทั่วไปเพื่อทดสอบประสิทธิภาพอย่างถูกต้องคุณต้องมีสภาพแวดล้อมการทดสอบโดยเฉพาะ สภาพแวดล้อมนี้ควรรวมถึงฮาร์ดแวร์ที่คล้ายกับสภาพแวดล้อมการผลิตในแง่ของความเร็วโปรเซสเซอร์จำนวนโปรเซสเซอร์หน่วยความจำดิสก์การกำหนดค่าเครือข่าย ฯลฯ ประการที่สองคุณต้องระบุภาระงานของลูกค้า: มีผู้ใช้กี่คนพร้อมกันความถี่ที่พวกเขาทำคำขอประเภทของหน้าใดที่พวกเขาคลิก ฯลฯ หากคุณไม่มีข้อมูลเกี่ยวกับการใช้งานเว็บไซต์จริงคุณต้องประเมินการใช้งาน ในที่สุดคุณต้องใช้เครื่องมือที่สามารถจำลองปริมาณงานของไคลเอนต์ที่คาดหวังได้ ด้วยเครื่องมือเหล่านี้คุณสามารถเริ่มตอบคำถามเช่น "ถ้าฉันมีผู้ใช้พร้อมกันฉันต้องการเซิร์ฟเวอร์กี่เซิร์ฟเวอร์" นอกจากนี้คุณยังสามารถระบุสาเหตุของคอขวดและปรับให้เหมาะสมกับพวกเขา
รายการด้านล่างนี้เป็นเครื่องมือทดสอบการโหลดเว็บที่ดี เราขอแนะนำชุดเครื่องมือ Microsoft Web Application Stress (เป็น) ช่วยให้คุณสามารถบันทึกสคริปต์ทดสอบแล้วจำลองผู้ใช้หลายร้อยหรือหลายพันคนที่เข้าถึงเว็บเซิร์ฟเวอร์ เป็นรายงานจำนวนสถิติรวมถึงคำขอต่อวินาทีการแจกแจงเวลาตอบสนองและการนับข้อผิดพลาด มีอยู่ในทั้งอินเทอร์เฟซไคลเอนต์ที่สมบูรณ์และอินเทอร์เฟซบนเว็บที่ช่วยให้คุณสามารถทำการทดสอบระยะไกลได้
อย่าลืมอ่านคู่มือการปรับแต่ง IIS 5.0
เคล็ดลับ 28: อ่านลิงก์ทรัพยากร
ด้านล่างเป็นลิงค์ไปยังแหล่งข้อมูลที่เกี่ยวข้องกับประสิทธิภาพที่ยอดเยี่ยม หากคุณต้องการเรียนรู้เกี่ยวกับมันอ่านการพัฒนาเว็บแอปพลิเคชันที่ปรับขนาดได้
การเพิ่มประสิทธิภาพของ
สคริปต์ ASP ที่พัฒนาเว็บแอปพลิเคชันที่ปรับขนาดได้
มี
แคช
ใด ๆ หรือไม่
?
ทรัพยากรความเร็วและการเพิ่มประสิทธิภาพ
โดย Nancy Winnick Cluts
เพิ่มประสิทธิภาพ IIS
โดย Charles Carrollศิลปะและวิทยาศาสตร์ของการปรับแต่งเว็บเซิร์ฟเวอร์ด้วยบริการข้อมูลอินเทอร์เน็ต 5.0
ใช้ประโยชน์จาก ASP ใน IIS 5.0,
Tuning IIS 4.0 สำหรับไซต์ที่มีปริมาณสูงโดย JD Meier, การปรับข้อมูลอินเทอร์เน็ต ประสิทธิภาพของเซิร์ฟเวอร์โดย Michael Stephenson
นำทางเขาวงกตของการตั้งค่าสำหรับการเพิ่มประสิทธิภาพประสิทธิภาพของเว็บเซิร์ฟเวอร์
โดย Mike Moore
การจัดการ
ข้อมูลอินเทอร์เน็ตเซิร์ฟเวอร์ 4.0 สำหรับประสิทธิภาพโดย Todd Wanke,
ADO และ SQL Server
โดย Hans HugliTop Tip Tips: เข้าถึง SQL ผ่าน ADO
และ ASPประสิทธิภาพของแอปพลิเคชัน MDAC ของคุณโดย
JD Meier
รวมเข้ากับส่วนประกอบการเข้าถึงข้อมูลของ Microsoft โดย Suresh Kannan,
SQL Server: มาตรฐานประสิทธิภาพและคำแนะนำโดย
Leland Ahlbeck และ Don Willitsปรับปรุงประสิทธิภาพของส่วนประกอบการเข้าถึงข้อมูลด้วย IIS
4.0 MDAC) และเคล็ดลับการปฏิบัติงาน Data ActiveX (ADO) โดย Leland Ahlbeck,
Microsoft
SQL Server 7.0 การปรับแต่งประสิทธิภาพการทำงานและการเพิ่มประสิทธิภาพของเซิร์ฟเวอร์ - มุมมองของเซิร์ฟเวอร์โดย Leland Ahlbeck,
Microsoft SQL Server 7.0 การปรับแต่งประสิทธิภาพการทำงานและการปรับให้เหมาะสมของเซิร์ฟเวอร์ มุมมองของแอปพลิเคชันโดย Damien Lindauer
เข้าถึงชุดบันทึกผ่านอินเทอร์เน็ตโดย Dino Esposito
ASP
Component Guidelines โดย JD Meier
Q243548: ข้อมูล: แนวทางการออกแบบสำหรับส่วนประกอบ VB ภายใต้
โมเดล
เธรด
ASPที่อธิบายโดย Nancy Winnick Cluts
ส่วนประกอบเซิร์ฟเวอร์ที่ใช้งานอยู่กับ ATL โดย
Nancy Winnick Cluts
ความคล่องตัวในส่วนประกอบเซิร์ฟเวอร์โดย George Reillyสร้างส่วนประกอบระดับกลางประสิทธิภาพสูงด้วย C ++ โดย
Neil Allain
หน้าเซิร์ฟเวอร์ที่ใช้งาน
อยู่ หน้าเซิร์ฟเวอร์ที่ใช้งานอยู่โดย Don Box,
House of COM: บริบทโดย Don Box,
House of Com: การแลกเปลี่ยนประสิทธิภาพของสภาพแวดล้อมการดำเนินการส่วนประกอบ Windows 2000 โดย Don Box,
ส่วนประกอบ COM ที่ใช้ประโยชน์อย่างเต็มที่จาก Visual Basic และ Scripting โดย IVO Salmre
Component Design หลักการสำหรับองค์ประกอบพจนานุกรม MTS
การ
สร้าง
วัตถุแคชหน้าโดย Robert Coleridge
เพื่อ
สรุปวัตถุพจนานุกรม: ทีม ASP สร้างวัตถุค้นหาตารางโดย Robert Carter
Caprock
Q175167: Howto: ค่าคงที่โดยไม่มีเซสชัน
Q157906: Howto: วิธีรักษาสถานะข้ามหน้าด้วยพฤติกรรมการคงอยู่ของ VBScript
XML
ที่ใช้การแก้ไขอาการปวดหัวของเว็บฟาร์มโดย Aaron Skonnard
House of Com: การเขียนโปรแกรมไร้สัญชาติโดย Don Box
Performance
ไซต์ที่ใช้ Microsoft Windows DNA DNA Platform
Performance และนักฆ่าความสามารถในการปรับขนาดได้โดย
ศูนย์ความสามารถในการปรับขนาดของ George Reilly Microsoft Visual Studio
Fitch & Mather Stocks 2000
การปรับแอพพลิเคชั่น FMSTOCKS
แอปพลิเคชัน
ภาพพื้นฐานที่มีประสิทธิภาพสูงโดย Ken Spencer
Duwamish Books
และวิธีการป้องกันพวกเขาโดย Gary Geiger และ Jon Pulsipher
อาคารจาก HTML แบบคงที่ไปจนถึงฟาร์มเว็บที่มีประสิทธิภาพสูงโดย Shawn Bice
Microsoft Web Application Stress เครื่องมือความเครียด
ฉัน
ไม่สามารถเครียดได้เพียงพอ-โหลดแอปพลิเคชัน ASP ของคุณโดย JD Meier
Windows DNA
กิจกรรมการตรวจสอบชุดประสิทธิภาพ
ในแอปพลิเคชันแบบกระจายโดยใช้ Visual Studio Analyzer โดย Mai-Lan Tomsen
Bibliography
Professional Professional Active Pages 3.0, WROX Press (โดยเฉพาะบทที่ 26: การเพิ่มประสิทธิภาพ ASP Performance, George Reilly กับ Matthew Gibbs)
คู่มือทรัพยากร Microsoft Internet Information Services 5.0 (พร้อมชุดทรัพยากรเซิร์ฟเวอร์ Windows 2000), Microsoft Press
Microsoft Internet Information Server Resource Kit (สำหรับ IIS 4.0), Microsoft Press
การเขียนโปรแกรมแบบกระจายแอพพลิเคชั่นที่มี COM และ Microsoft Visual Basic 6.0 โดย Ted Pattison, Microsoft Press
COM ที่มีประสิทธิภาพโดย Don Box, Keith Brown, Tim Ewald และ Chris ขาย
การพัฒนาความสามารถในการใช้งานเว็บ: การฝึกฝนความเรียบง่ายโดย Jakob Nielsen นักปั่นใหม่
ASP Web SitesMicrosoft
Technet สำหรับ IIS
learnasp.com
4GUYSFROMROLLA.com
15Seconds.com
ASPTODAY.com
ASP101.com
ASPLISTS.com รายชื่อผู้รับจดหมายระดับมืออาชีพจำนวนมากรวมถึง:
Fast Code!
ASP ขั้นสูง
ไม่ใช่การจัดการใหม่
ความสามารถในการขยายขนาด
ส่วนประกอบพื้นฐานของภาพ
XML
การสร้างส่วนประกอบ C ++/ATL
useit.com: การใช้งานเว็บ
สไตล์ ASP
ASP แนวทางปฏิบัติที่ดีที่สุดโดย George Reilly
ASP บทเรียนด่วนโดย Charles Carroll
วางแผนสำหรับ ASP John Meade
ASP GuidelinesXML
โดย JD Meier
ภายในประสิทธิภาพ XML โดย Chris Lovett
ภายใน MSXML3 Performance โดย Chris Lovett