นักพัฒนา ASP พยายามอย่างต่อเนื่องเพื่อให้ได้ประสิทธิภาพและความสามารถในการปรับขนาดที่ดีขึ้นในโครงการออกแบบของตน โชคดีที่มีหนังสือและเว็บไซต์มากมายที่ให้คำแนะนำที่ดีเกี่ยวกับเรื่องนี้ อย่างไรก็ตาม ข้อเสนอแนะเหล่านี้ขึ้นอยู่กับข้อสรุปที่ได้จากโครงสร้างของงานของแพลตฟอร์ม ASP และไม่มีการวัดเชิงปริมาณของการปรับปรุงประสิทธิภาพจริง เนื่องจากคำแนะนำเหล่านี้ต้องการการเข้ารหัสที่ซับซ้อนมากขึ้น และทำให้โค้ดอ่านได้น้อยลง นักพัฒนาจึงถูกทิ้งให้ชั่งน้ำหนักว่าการปรับปรุงประสิทธิภาพของแอปพลิเคชัน ASP ของตนนั้นคุ้มค่าหรือไม่โดยไม่เห็นผลลัพธ์ที่แท้จริง
บทความนี้แบ่งออกเป็นสองส่วน ฉันจะนำเสนอผลการทดสอบประสิทธิภาพเพื่อช่วยให้นักพัฒนาทราบว่าความคิดริเริ่มเฉพาะนั้นคุ้มค่าหรือไม่ไม่เพียงแต่สำหรับโครงการในอนาคตเท่านั้น แต่ยังรวมถึงการอัปเดตโครงการดั้งเดิมด้วย ในส่วนแรก ผมจะทบทวนประเด็นพื้นฐานของการพัฒนา ASP ในส่วนที่สอง คุณจะครอบคลุมถึงการปรับฟังก์ชัน ADO บางอย่างให้เหมาะสม และการเปรียบเทียบผลลัพธ์กับเพจ ASP ที่เรียกวัตถุ VB COM เพื่อดำเนินการฟังก์ชัน ADO เดียวกัน ผลลัพธ์ที่ได้นั้นเปิดหูเปิดตาและบางครั้งก็น่าประหลาดใจ
ในบทความนี้เราจะตอบคำถามต่อไปนี้:
* วิธีที่มีประสิทธิภาพที่สุดในการเขียนเนื้อหาที่สร้างโดย ASP ลงในสตรีมการตอบกลับคืออะไร?
* ควรเปิดใช้งานบัฟเฟอร์หรือไม่
* คุณควรพิจารณาเพิ่มความคิดเห็นในโค้ด ASP ของคุณหรือไม่
* ควรตั้งค่าภาษาเริ่มต้นอย่างชัดเจนสำหรับเพจหรือไม่
* ควรปิดสถานะเซสชันหากไม่จำเป็น?
* ควรวางสคริปต์ตรรกะไว้ในรูทีนย่อยและพื้นที่ฟังก์ชันหรือไม่
* อะไรคือผลกระทบของการใช้ไฟล์รวม?
* ภาระประเภทใดที่เกิดขึ้นเมื่อดำเนินการจัดการข้อผิดพลาด?
* การตั้งค่าตัวจัดการบริบทมีผลกระทบต่อประสิทธิภาพหรือไม่
การทดสอบทั้งหมดดำเนินการโดยใช้ Web Application Focus Tool (WAST) ของ Microsoft ซึ่งเป็นเครื่องมือฟรีที่สามารถพบได้ที่นี่ ฉันสร้างสคริปต์ทดสอบอย่างง่ายโดยใช้ WAST ซึ่งเรียกการทดสอบหน้า ASP ซ้ำๆ ตามที่อธิบายไว้ด้านล่าง (มากกว่า 70,000 ครั้งในแต่ละครั้ง) เวลาตอบสนองจะขึ้นอยู่กับเวลาเฉลี่ยรวมไบต์สุดท้าย (TTLB) ซึ่งเป็นเวลานับจากเวลาของการร้องขอครั้งแรกจนถึงเวลาที่เครื่องมือได้รับข้อมูลบิตสุดท้ายจากเซิร์ฟเวอร์ เซิร์ฟเวอร์ทดสอบของเราคือ Pentium 166 พร้อม RAM 196MB และไคลเอนต์คือ Pentium 450 พร้อม RAM 256MB คุณอาจคิดว่าประสิทธิภาพของเครื่องเหล่านี้ไม่ได้ก้าวหน้ามากนัก แต่อย่าลืม เราไม่ได้ทดสอบความสามารถของเซิร์ฟเวอร์ เราแค่ทดสอบเวลาที่เซิร์ฟเวอร์ใช้ในการประมวลผลทีละหน้า เครื่องจักรไม่ทำงานอื่นในระหว่างการทดสอบ สคริปต์ทดสอบ WAST รายงานการทดสอบ และหน้าทดสอบ ASP ทั้งหมดจะรวมอยู่ในไฟล์ ZIP เพื่อให้คุณสามารถตรวจสอบและทดสอบด้วยตัวเอง
วิธีที่มีประสิทธิภาพที่สุดในการเขียนเนื้อหาที่สร้างโดย ASP ลงในสตรีมการตอบสนองคืออะไร?
หนึ่งในเหตุผลที่ใหญ่ที่สุดในการใช้ ASP คือการสร้างเนื้อหาแบบไดนามิกบนเซิร์ฟเวอร์ ดังนั้นจุดเริ่มต้นที่ชัดเจนสำหรับการทดสอบของเราคือการกำหนดวิธีที่เหมาะสมที่สุดในการส่งเนื้อหาแบบไดนามิกไปยังสตรีมการตอบกลับ ในบรรดาตัวเลือกต่างๆ มีสองตัวเลือกพื้นฐานที่สุด: ตัวเลือกแรกคือการใช้แท็ก ASP แบบอินไลน์ และอีกตัวเลือกคือการใช้คำสั่ง Response.Write
เพื่อทดสอบตัวเลือกเหล่านี้ เราได้สร้างเพจ ASP แบบง่ายซึ่งเรากำหนดตัวแปรบางตัวแล้วแทรกค่าลงในตาราง แม้ว่าหน้านี้เรียบง่ายและใช้งานไม่ได้มากนัก แต่ก็ช่วยให้เราสามารถแยกและทดสอบปัญหาบางอย่างได้
การใช้แท็กอินไลน์ ASP
การทดสอบครั้งแรกเกี่ยวข้องกับการใช้แท็ก ASP แบบอินไลน์ < %= x % > โดยที่ x คือตัวแปรที่กำหนด วิธีนี้เป็นวิธีที่ทำได้ง่ายที่สุด และช่วยรักษาส่วน HTML ของหน้าให้อยู่ในรูปแบบที่อ่านและดูแลรักษาได้ง่าย
＜% ตัวเลือกที่ชัดเจน
ชื่อจริงดิม
DimLastName
Dim Middleเริ่มต้น
ที่อยู่สลัว
เมืองดิม
รัฐสลัว
ดิมโฟนนัมเบอร์
Dim FaxNumber
อีเมลสลัว
DimBirthDate
ชื่อ = จอห์น
MiddleInitial = ถาม
นามสกุล = สาธารณะ
ที่อยู่ = 100 ถนนสายหลัก
เมือง=นิวยอร์ก
รัฐ=นิวยอร์ก
หมายเลขโทรศัพท์ = 1-212-555-1234
หมายเลขแฟกซ์ = 1-212-555-1234
อีเมล์ = [email protected]
วันเกิด = 1/1/1950
-
<HTML>
＜หัว><
＜ หัวข้อ ＞ การทดสอบการตอบสนอง ＜ / หัวข้อ ＞
＜ /หัวหน้า ><
<ร่างกาย>
＜ H1 >< การทดสอบการตอบสนอง ＜ /H1 >
＜ ตาราง ＞
＜ tr ＞＜ td ＞＜ b ＞ชื่อ:＜ /b ＞＜ /td ＞＜ td ＞＜ %= ชื่อ % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞เริ่มต้นกลาง:＜ /b ＞＜ /td ＞＜ td ＞＜ %= MiddleInitial % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞นามสกุล:＜ /b ＞＜ /td ＞＜ td ＞＜ %= นามสกุล % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞ที่อยู่:＜ /b ＞＜ /td ＞＜ td ＞＜ %= ที่อยู่ % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞เมือง:＜ /b ＞＜ /td ＞＜ td ＞＜ %= เมือง % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞สถานะ:＜ /b ＞＜ /td ＞＜ td ＞＜ %= สถานะ % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞หมายเลขโทรศัพท์:＜ /b ＞＜ /td ＞＜ td ＞＜ %= หมายเลขโทรศัพท์ % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞หมายเลขแฟกซ์:＜ /b ＞＜ /td ＞＜ td ＞＜ %= หมายเลขแฟกซ์ % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞อีเมล:＜ /b ＞＜ /td ＞＜ td ＞＜ %= อีเมล % ＞＜ /td ＞＜ /tr ＞
＜ tr ＞＜ td ＞＜ b ＞วันเกิด:＜ /b ＞＜ /td ＞＜ td ＞＜ %= วันเกิด % ＞＜ /td ＞＜ /tr ＞
＜ /ตาราง ＞
＜ /ร่างกาย ＞
＜ /HTML ><
รหัสที่สมบูรณ์ของ /app1/response1.asp
ดีที่สุดก่อนหน้า (ความเร็วในการตอบสนอง) = 8.28 มิลลิวินาที/หน้า
ใช้คำสั่ง Response.Write ในแต่ละบรรทัดของ HTML
เอกสารการเรียนรู้ที่ดีกว่าหลายฉบับแนะนำให้หลีกเลี่ยงวิธีการแบบเดิม สาเหตุหลักก็คือ ในกระบวนการส่งออกเพจและประมวลผลเพจเพื่อกำหนดเวลาแฝง หากเว็บเซิร์ฟเวอร์ต้องแปลงระหว่างการส่ง HTML ธรรมดาและสคริปต์ประมวลผล ปัญหาที่เรียกว่าการสลับบริบทจะเกิดขึ้น เมื่อโปรแกรมเมอร์ส่วนใหญ่ได้ยินสิ่งนี้ ปฏิกิริยาแรกของพวกเขาคือการรวม HTML ดิบแต่ละบรรทัดไว้ในฟังก์ชัน Response.Write
-
การตอบกลับเขียน(<html>)
ตอบกลับเขียน(<หัว>)
Response.Write(<หัวข้อ>การทดสอบการตอบสนอง</หัวข้อ>)
ตอบกลับเขียน(＜/หัว><)
ตอบกลับเขียน(<เนื้อหา>)
การตอบสนองเขียน(<h1>การทดสอบการตอบสนอง</h1>)
การตอบกลับเขียน(<ตาราง>)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞ชื่อ:＜ /b ＞＜ /td ＞＜ td ＞ & ชื่อ & ＜ /td ＞＜ /tr ＞)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞เริ่มต้นกลาง:＜ /b ＞＜ /td ＞＜ td ＞ & MiddleInitial & ＜ /td ＞＜ /tr ＞)
-
ส่วนของ /app1/response2.asp
ดีที่สุดก่อนหน้า (ความเร็วในการตอบสนอง) = 8.28 มิลลิวินาที/หน้า
เวลาตอบสนอง = 8.08 มิลลิวินาที/หน้า
ส่วนต่าง = -0.20 มิลลิวินาที (ลดลง 2.4%)
เราจะเห็นได้ว่าประสิทธิภาพที่ได้รับจากการใช้วิธีการนี้มีขนาดเล็กมากเมื่อเทียบกับการใช้มาร์กอัปแบบอินไลน์ อาจเป็นเพราะเพจโหลดเซิร์ฟเวอร์ด้วยการเรียกใช้ฟังก์ชันเล็กๆ น้อยๆ จำนวนมาก ข้อเสียที่ใหญ่ที่สุดของแนวทางนี้คือ เนื่องจากตอนนี้ HTML ถูกฝังอยู่ในสคริปต์แล้ว โค้ดสคริปต์จึงมีรายละเอียดมากขึ้น และอ่านและบำรุงรักษาได้ยากขึ้น
ใช้ฟังก์ชันตัวห่อหุ้ม
บางทีการค้นพบที่ท้อใจที่สุดเมื่อพยายามใช้วิธีคำสั่ง Response.Write ก็คือ ฟังก์ชัน Response.Write ไม่สามารถวาง CRLF ที่ส่วนท้ายของแต่ละบรรทัดได้ ดังนั้นเมื่อคุณอ่านซอร์สโค้ดจากเบราว์เซอร์ HTML ที่ถูกจัดวางอย่างสมบูรณ์แบบจะกลายเป็นบรรทัดเดียวโดยไม่มีจุดสิ้นสุด ฉันคิดว่าการค้นพบครั้งต่อไปของคุณอาจจะน่ากลัวยิ่งกว่าเดิม: ไม่มีฟังก์ชันน้องสาว Writeln ในวัตถุ Response ดังนั้น ปฏิกิริยาที่ชัดเจนคือการสร้างฟังก์ชัน wrapper สำหรับฟังก์ชัน Response.Write เพื่อผนวก CRLF เข้ากับแต่ละบรรทัด
-
writeCR(＜ tr ＞＜ td ＞＜ b ＞ชื่อ:＜ /b ＞＜ /td ＞＜ td ＞ & ชื่อ & ＜ /td ＞＜ /tr ＞)
-
ย่อยเขียน CR(str)
การตอบกลับเขียน (str & vbCRLF)
จบย่อย
ส่วนของ /app1/response4.asp
ดีที่สุดก่อนหน้า (ความเร็วในการตอบสนอง) = 8.08 มิลลิวินาที/หน้า
เวลาตอบสนอง = 10.11 มิลลิวินาที/หน้า
ส่วนต่าง = +2.03 มิลลิวินาที (เพิ่มขึ้น 25.1%)
แน่นอนว่า เนื่องจากแนวทางนี้เพิ่มจำนวนการเรียกใช้ฟังก์ชันได้อย่างมีประสิทธิภาพเป็นสองเท่า ผลกระทบต่อประสิทธิภาพจึงมีความสำคัญ และควรหลีกเลี่ยงไม่ว่าจะด้วยวิธีใดก็ตาม น่าแปลกที่ CRLF ยังเพิ่ม 2 ไบต์ต่อบรรทัดในสตรีมแบบโต้ตอบ ซึ่งเบราว์เซอร์ไม่จำเป็นต้องแสดงผลบนเพจ HTML ที่มีการจัดรูปแบบที่ดีทั้งหมดช่วยให้คู่แข่งของคุณอ่านซอร์สโค้ด HTML ของคุณและเข้าใจการออกแบบของคุณได้ง่ายขึ้น
เชื่อมต่อการตอบสนองที่ต่อเนื่องกัน เขียนเป็นคำสั่งเดียว
ไม่ว่าการทดสอบก่อนหน้านี้กับฟังก์ชัน Wrapper จะเป็นเช่นไร ขั้นตอนถัดไปคือการแยกสตริงทั้งหมดออกจากคำสั่ง Response.Write ที่แยกจากกัน และต่อเข้าด้วยกันเป็นคำสั่งเดียว ซึ่งจะช่วยลดจำนวนการเรียกใช้ฟังก์ชัน ซึ่งช่วยปรับปรุงประสิทธิภาพของเพจได้อย่างมาก
-
การตอบกลับเขียน(<html>&_
＜ หัว ＞ & _
＜หัวข้อ＞การทดสอบการตอบสนอง＜/หัวข้อ＞ & _
＜ /หัว >< & _
＜ร่างกาย＞ & _
＜ h1 >< การทดสอบการตอบสนอง < /h1 > & _
＜ ตาราง ＞ & _
＜ tr ＞＜ td ＞＜ b ＞ชื่อ:＜ /b ＞＜ /td ＞＜ td ＞ & ชื่อ & ＜ /td ＞＜ /tr ＞ & _
-
＜ tr ＞＜ td ＞＜ b ＞วันเกิด:＜ /b ＞＜ /td ＞＜ td ＞ & วันเกิด & ＜ /td ＞＜ /tr ＞ & _
＜ /โต๊ะ >< & _
＜ /ตัว >< & _
＜ /html ><)
ส่วนของ /app1/response3.asp
ดีที่สุดก่อนหน้า (ความเร็วในการตอบสนอง) = 8.08 มิลลิวินาที/หน้า
เวลาตอบสนอง = 7.05 มิลลิวินาที/หน้า
ส่วนต่าง = -1.03 มิลลิวินาที (ลดลง 12.7%)
ปัจจุบันนี่คือการกำหนดค่าที่เหมาะสมที่สุด
เชื่อมต่อการตอบกลับที่ต่อเนื่องกัน เขียนลงในคำสั่งเดียว โดยเพิ่ม CRLF ที่ท้ายแต่ละบรรทัด
เมื่อพิจารณาถึงผู้ที่ต้องการให้ซอร์สโค้ดของตนดูบริสุทธิ์จากเบราว์เซอร์ ฉันใช้ค่าคงที่ vbCRLF เพื่อแทรกการขึ้นบรรทัดใหม่บางส่วนที่ส่วนท้ายของแต่ละบรรทัดในการทดสอบครั้งก่อนแล้วรันใหม่
-
การตอบกลับเขียน(<html>&vbCRLF&_
＜ หัว ＞ & vbCRLF & _
＜ ชื่อ ＞ การทดสอบการตอบสนอง ＜ / หัวเรื่อง > & vbCRLF & _
＜ /หัว >< & vbCRLF & _
-
ส่วนของ /app1/response5.asp
ดีที่สุดก่อนหน้า (ความเร็วในการตอบสนอง) = 7.05 มิลลิวินาที/หน้า
เวลาตอบสนอง = 7.63 มิลลิวินาที/หน้า
ส่วนต่าง = +0.58 มิลลิวินาที (เพิ่มขึ้น 8.5%)
ผลลัพธ์ที่ได้คือประสิทธิภาพลดลงเล็กน้อย อาจเนื่องมาจากการต่อข้อมูลเพิ่มเติมและจำนวนอักขระที่เพิ่มขึ้น
ทบทวนและสังเกต
กฎบางข้อสามารถดึงมาจากการทดสอบก่อนหน้าบนเอาต์พุต ASP:
* หลีกเลี่ยงการใช้ ASP แบบอินไลน์มากเกินไป
* เชื่อมต่อ Response.Write คำสั่งที่ต่อเนื่องกันเสมอให้เป็นคำสั่งเดียว
* ห้ามใช้ฟังก์ชัน wrapper รอบ Response.Write เพื่อผนวก CRLF
* หากต้องจัดรูปแบบเอาต์พุต HTML ให้ผนวก CRLF โดยตรงภายในคำสั่ง Response.Write
ควรเปิดใช้งานบัฟเฟอร์หรือไม่
เริ่มบัฟเฟอร์ผ่านสคริปต์
ด้วยการรวม Response.Buffer=True ไว้ที่ด้านบนของสคริปต์ ASP IIS จะแคชเนื้อหาของเพจ
＜% ตัวเลือกที่ชัดเจน
Response.Buffer = จริง
ชื่อจริงดิม
-
ส่วนของ /app1/buffer__1.asp
ดีที่สุดก่อนหน้า (เวลาตอบสนอง) = 7.05 มิลลิวินาที/หน้า
เวลาตอบสนอง = 6.08 มิลลิวินาที/หน้า
ส่วนต่าง = -0.97 มิลลิวินาที (ลดลง 13.7%)
ประสิทธิภาพได้รับการปรับปรุงอย่างมาก แต่เดี๋ยวก่อนมีบางอย่างที่ดีกว่า
เริ่มบัฟเฟอร์ผ่านการกำหนดค่าเซิร์ฟเวอร์
แม้ว่าบัฟเฟอร์จะถูกเปิดใช้งานตามค่าเริ่มต้นใน IIS 5.0 แต่จะต้องเปิดใช้งานด้วยตนเองใน IIS 4.0 ตอนนี้ค้นหากล่องโต้ตอบคุณสมบัติของไซต์แล้วเลือกปุ่มกำหนดค่าจากแท็บโฮมไดเร็กทอรี จากนั้นเลือกเปิดใช้งานการบัฟเฟอร์ภายใต้ตัวเลือกแอพ สำหรับการทดสอบนี้ คำสั่ง Response.Buffer ถูกย้ายออกจากสคริปต์
ดีที่สุดก่อนหน้า = 7.05 มิลลิวินาที/หน้า
เวลาตอบสนอง = 5.57 มิลลิวินาที/หน้า
ส่วนต่าง = -1.48 มิลลิวินาที (ลดลง 21.0%)
ในปัจจุบัน นี่คือการตอบกลับที่เร็วที่สุดที่เราเคยมี ซึ่งต่ำกว่าเวลาตอบกลับที่ดีที่สุดครั้งก่อนถึง 21% จากนี้ไป การทดสอบในอนาคตของเราจะใช้เวลาปฏิกิริยานี้เป็นค่าพื้นฐาน
ทบทวนและสังเกต
บัฟเฟอร์เป็นวิธีที่ดีในการปรับปรุงประสิทธิภาพ ดังนั้นการตั้งค่าบัฟเฟอร์ให้เป็นค่าเริ่มต้นของเซิร์ฟเวอร์จึงมีความจำเป็น หากเพจไม่สามารถรันบัฟเฟอร์ได้อย่างถูกต้องด้วยเหตุผลบางประการ เพียงใช้คำสั่ง Response.Buffer=False ข้อเสียประการหนึ่งของบัฟเฟอร์คือผู้ใช้ไม่เห็นสิ่งใดจากเซิร์ฟเวอร์จนกว่าหน้าทั้งหมดจะได้รับการประมวลผล ดังนั้น ในระหว่างการประมวลผลเพจที่ซับซ้อน จึงเป็นความคิดที่ดีที่จะเรียก Response.Flush เป็นครั้งคราวเพื่ออัปเดตผู้ใช้
ตอนนี้เราได้เพิ่มกฎอีกหนึ่งข้อ: เปิดใช้งานการบัฟเฟอร์ผ่านการตั้งค่าเซิร์ฟเวอร์เสมอ
คุณควรพิจารณาเพิ่มความคิดเห็นในโค้ด ASP ของคุณหรือไม่
นักพัฒนา HTML ส่วนใหญ่ทราบดีว่าการใส่ความคิดเห็น HTML นั้นเป็นความคิดที่ไม่ดี ประการแรก จะเพิ่มขนาดของข้อมูลที่กำลังถ่ายโอน และประการที่สอง พวกเขาเพียงให้ข้อมูลเกี่ยวกับการจัดระเบียบเพจของคุณแก่นักพัฒนารายอื่น แต่ความคิดเห็นบนหน้า ASP ล่ะ? พวกเขาไม่เคยออกจากเซิร์ฟเวอร์ แต่จะเพิ่มขนาดของเพจ ดังนั้นจึงต้องแยกย่อยโดยใช้ ASP
ในการทดสอบนี้ เราได้เพิ่มความคิดเห็น 20 รายการ แต่ละความคิดเห็นมีอักขระ 80 ตัว รวมเป็น 1,600 อักขระ
＜% ตัวเลือกที่ชัดเจน
'------------------------------------------------ - ---------------------------------
…20 บรรทัด…
'------------------------------------------------ - ---------------------------------
ชื่อจริงดิม
-
/app2/comment_1.asp ส่วน
พื้นฐาน = 5.57 มิลลิวินาที/เพจ
เวลาตอบสนอง = 5.58 มิลลิวินาที/หน้า
ส่วนต่าง = +0.01 มิลลิวินาที (เพิ่มขึ้น 0.1%)
ผลการทดสอบก็น่าประหลาดใจ แม้ว่าความคิดเห็นจะมีความยาวมากกว่าตัวไฟล์เกือบสองเท่า แต่การมีอยู่ของความคิดเห็นเหล่านั้นไม่ได้ส่งผลกระทบอย่างมากต่อเวลาตอบสนอง ดังนั้นเราจึงสามารถปฏิบัติตามกฎต่อไปนี้:
ตราบใดที่ใช้ในระดับปานกลาง คำอธิบายประกอบ ASP จะมีผลกระทบต่อประสิทธิภาพการทำงานเพียงเล็กน้อยหรือไม่มีเลย
ควรตั้งค่าภาษาเริ่มต้นอย่างชัดเจนสำหรับเพจหรือไม่
IIS จัดการ VBScript ตามค่าเริ่มต้น แต่ฉันเห็นว่าในกรณีส่วนใหญ่ภาษาจะถูกตั้งค่าเป็น VBScript อย่างชัดเจนโดยใช้คำสั่ง <%@LANGUAGE=VBSCRIPT%> การทดสอบครั้งต่อไปของเราจะตรวจสอบว่าการประกาศนี้มีผลกระทบต่อประสิทธิภาพการทำงานอย่างไร
＜ %@ LANGUAGE=VBSCRIPT % >
＜% ตัวเลือกที่ชัดเจน
ชื่อจริงดิม
-
/app2/ language1.asp ส่วน
พื้นฐาน = 5.57 มิลลิวินาที/เพจ
เวลาตอบสนอง = 5.64 มิลลิวินาที/หน้า
ส่วนต่าง = +0.07 มิลลิวินาที (เพิ่มขึ้น 1.2%)
อย่างที่คุณเห็น การรวมการประกาศภาษามีผลกระทบเล็กน้อยต่อประสิทธิภาพ ดังนั้น:
* ตั้งค่าการกำหนดค่าภาษาเริ่มต้นของเซิร์ฟเวอร์ให้ตรงกับภาษาที่ใช้บนเว็บไซต์
* อย่าตั้งค่าการประกาศภาษาเว้นแต่คุณจะใช้ภาษาที่ไม่ใช่ค่าเริ่มต้น
ควรปิดสถานะเซสชันหากไม่จำเป็นหรือไม่
มีเหตุผลหลายประการที่ควรหลีกเลี่ยงการใช้บริบทของเซสชัน IIS และเหตุผลเหล่านั้นอาจเป็นบทความของตัวเอง คำถามที่เราพยายามตอบตอนนี้คือการปิดบริบทเซสชันเมื่อเพจไม่จำเป็นจะช่วยปรับปรุงประสิทธิภาพหรือไม่ ตามทฤษฎีแล้ว ควรเป็นใช่ เนื่องจากไม่จำเป็นต้องใช้เพจเพื่อสร้างอินสแตนซ์บริบทของเซสชัน
เช่นเดียวกับบัฟเฟอร์ มีสองวิธีในการกำหนดค่าสถานะเซสชัน: ผ่านสคริปต์และผ่านการตั้งค่าเซิร์ฟเวอร์
ปิดบริบทเซสชันผ่านสคริปต์
สำหรับการทดสอบนี้ เพื่อปิดบริบทเซสชันในหน้า ฉันได้เพิ่มการประกาศสถานะเซสชัน
＜ %@ ENABLESESSIONSTATE = FALSE % ><
＜% ตัวเลือกที่ชัดเจน
ชื่อจริงดิม
-
/app2/session_1.asp ส่วน
พื้นฐาน = 5.57 มิลลิวินาที/เพจ
เวลาตอบสนอง = 5.46 มิลลิวินาที/หน้า
ส่วนต่าง = -0.11 มิลลิวินาที (ลดลง 2.0%)
มีความก้าวหน้าที่ดีด้วยความพยายามเล็กๆ น้อยๆ เช่นนี้ ตอนนี้ดูส่วนที่สอง
ปิดบริบทเซสชันผ่านการกำหนดค่าเซิร์ฟเวอร์
เมื่อต้องการปิดบริบทของเซสชันบนเซิร์ฟเวอร์ ให้ไปที่กล่องโต้ตอบคุณสมบัติของไซต์ เลือกปุ่มการกำหนดค่าบนแท็บโฮมไดเร็กทอรี จากนั้นยกเลิกการเลือกเปิดใช้งานสถานะเซสชันภายใต้ตัวเลือกแอป เราทำการทดสอบโดยไม่มีคำสั่ง ENABLESESSIONSTATE
พื้นฐาน = 5.57 มิลลิวินาที/เพจ
เวลาตอบสนอง = 5.14 มิลลิวินาที/หน้า
ส่วนต่าง = -0.43 มิลลิวินาที (ลดลง 7.7%)
นี่เป็นการปรับปรุงประสิทธิภาพที่สำคัญอีกประการหนึ่ง ดังนั้นกฎของเราควรเป็น: ปิดสถานะเซสชันที่ระดับเพจหรือแอปพลิเคชันเสมอเมื่อไม่จำเป็น
การใช้ Option Explicit จะเปลี่ยนประสิทธิภาพอย่างมากหรือไม่
ตั้งค่า Option Explicit ที่ด้านบนของเพจ ASP เพื่อกำหนดให้ตัวแปรทั้งหมดถูกประกาศบนเพจก่อนใช้งาน มีสองเหตุผลสำหรับเรื่องนี้ ประการแรก แอปพลิเคชันสามารถประมวลผลการเข้าถึงตัวแปรได้เร็วขึ้น ประการที่สอง สิ่งนี้จะป้องกันไม่ให้เราใช้ชื่อตัวแปรไม่ถูกต้องโดยไม่ตั้งใจ ในการทดสอบนี้ เราจะลบการอ้างอิง Option Explicit และการประกาศ Dim ของตัวแปรออก
พื้นฐาน = 5.57 มิลลิวินาที/เพจ
เวลาตอบสนอง = 6.12 มิลลิวินาที/หน้า
ส่วนต่าง = +0.55 มิลลิวินาที (เพิ่มขึ้น 9.8%)
แม้ว่าโค้ดบางบรรทัดจะถูกลบออกจากเพจแล้ว แต่เวลาในการตอบสนองก็ยังคงเพิ่มขึ้น ดังนั้นแม้ว่าบางครั้งการใช้ Option ที่ชัดเจนอาจใช้เวลานาน แต่ก็มีผลกระทบอย่างมากต่อประสิทธิภาพ ดังนั้นเราจึงสามารถเพิ่มกฎอื่นได้: ใช้ Option ชัดเจนใน VBScript เสมอ
ควรวางตรรกะของสคริปต์ไว้ในรูทีนย่อยและพื้นที่ฟังก์ชันหรือไม่
การใช้ฟังก์ชันและรูทีนย่อยเป็นวิธีที่ดีในการจัดระเบียบและจัดการโค้ด โดยเฉพาะอย่างยิ่งเมื่อมีการใช้พื้นที่โค้ดหลายครั้งบนเพจ ข้อเสียคือจะเพิ่มการเรียกใช้ฟังก์ชันพิเศษให้กับระบบที่ทำงานเดียวกัน ปัญหาอีกประการหนึ่งของรูทีนย่อยและฟังก์ชันคือขอบเขตของตัวแปร ตามทฤษฎีแล้ว การระบุตัวแปรภายในพื้นที่ฟังก์ชันจะมีประสิทธิภาพมากกว่า ตอนนี้เรามาดูกันว่าทั้งสองด้านนี้เข้ามามีบทบาทอย่างไร
ย้ายคำสั่ง Response.Write ลงในรูทีนย่อย
การทดสอบนี้จะย้ายคำสั่ง Response.Write ไปยังพื้นที่รูทีนย่อย
-
โทร writeTable()
ย่อย writeTable()
การตอบกลับเขียน(<html>&_
＜ หัว ＞ & _
-
＜ tr ＞＜ td ＞＜ b ＞อีเมล:＜ /b ＞＜ /td ＞＜ td ＞ & อีเมล & ＜ /td ＞＜ /tr ＞ & _
＜ tr ＞＜ td ＞＜ b ＞วันเกิด:＜ /b ＞＜ /td ＞＜ td ＞ & วันเกิด & ＜ /td ＞＜ /tr ＞ & _
＜ /โต๊ะ >< & _
＜ /ตัว >< & _
＜ /html ><)
จบย่อย
/app2/function1.asp ส่วน
พื้นฐาน = 5.57 มิลลิวินาที/เพจ
เวลาตอบสนอง = 6.02 มิลลิวินาที/หน้า
ส่วนต่าง = +0.45 มิลลิวินาที (เพิ่มขึ้น 8.1%)
ตามที่คาดไว้ การเรียกรูทีนย่อยจะวางโอเวอร์เฮดเพิ่มเติมบนเพจ
ย้ายสคริปต์ทั้งหมดไปยังรูทีนย่อย
ในการทดสอบนี้ คำสั่ง Response.write และการประกาศตัวแปรจะถูกย้ายไปยังพื้นที่รูทีนย่อย
＜% ตัวเลือกที่ชัดเจน
โทร writeTable()
ย่อย writeTable()
ชื่อจริงดิม
-
DimBirthDate
ชื่อ = จอห์น
-
วันเกิด = 1/1/1950
การตอบกลับเขียน(<html>&_
＜ หัว ＞ & _
＜หัวข้อ＞การทดสอบการตอบสนอง＜/หัวข้อ＞ & _
＜ /หัว >< & _
＜ร่างกาย＞ & _
＜ h1 >< การทดสอบการตอบสนอง < /h1 > & _
＜ ตาราง ＞ & _
＜ tr ＞＜ td ＞＜ b ＞ชื่อ:＜ /b ＞＜ /td ＞＜ td ＞ & ชื่อ & ＜ /td ＞＜ /tr ＞ & _
-
＜ tr ＞＜ td ＞＜ b ＞วันเกิด:＜ /b ＞＜ /td ＞＜ td ＞ & วันเกิด & ＜ /td ＞＜ /tr ＞ & _
＜ /โต๊ะ >< & _
＜ /ตัว >< & _
＜ /html ><)
จบย่อย
/app2/function2.asp ส่วน
พื้นฐาน = 5.57 มิลลิวินาที/เพจ
เวลาตอบสนอง = 5.22 มิลลิวินาที/หน้า
ส่วนต่าง = -0.35 มิลลิวินาที (ลดลง 6.3%)
น่าสนใจมาก! แม้ว่าการย้ายตัวแปรไปยังขอบเขตฟังก์ชันจะเพิ่มการเรียกใช้ฟังก์ชันเพิ่มเติม แต่จริงๆ แล้วจะช่วยปรับปรุงประสิทธิภาพได้จริง เราสามารถเพิ่มกฎต่อไปนี้:
* บนเพจ หากจะใช้โค้ดมากกว่าหนึ่งครั้ง ให้ใส่โค้ดไว้ในพื้นที่ฟังก์ชัน
* เมื่อเหมาะสม ให้ย้ายการประกาศตัวแปรไปยังขอบเขตฟังก์ชัน
การใช้ไฟล์รวมมีผลกระทบอะไรบ้าง?
คุณลักษณะที่สำคัญของการเขียนโปรแกรม ASP คือการรวมโค้ดจากหน้าอื่นๆ ด้วยคุณสมบัตินี้ โปรแกรมเมอร์สามารถแชร์ฟังก์ชันต่างๆ ในหลายเพจ ทำให้ง่ายต่อการบำรุงรักษาโค้ด ข้อเสียคือเซิร์ฟเวอร์ต้องประกอบเพจจากหลายแหล่ง ด้านล่างนี้เป็นการทดสอบสองครั้งโดยใช้ไฟล์รวม
รวมไฟล์โดยใช้โค้ดอินไลน์
ในการทดสอบนี้ โค้ดเล็กๆ น้อยๆ ได้ถูกย้ายไปยังไฟล์รวม:
＜% ตัวเลือกที่ชัดเจน
ชื่อจริงดิม
-
DimBirthDate
ชื่อ = จอห์น
-
วันเกิด = 1/1/1950
-
＜ !-- #include file=inc1.asp -- >
/app2/include_1.asp ส่วน
พื้นฐาน = 5.57 มิลลิวินาที/เพจ
เวลาตอบสนอง = 5.93 มิลลิวินาที/หน้า
ส่วนต่าง = +0.36 มิลลิวินาที (เพิ่มขึ้น 6.5%)
นี่ไม่ใช่เรื่องน่าแปลกใจเลย เพย์โหลดถูกสร้างขึ้นโดยใช้ไฟล์รวม
ใช้รวมไฟล์ในพื้นที่ฟังก์ชัน
ที่นี่โค้ดถูกรวมไว้ในรูทีนย่อยในไฟล์รวม การอ้างอิงรวมถูกสร้างขึ้นที่ด้านบนของเพจ และเรียกรูทีนย่อยที่ตำแหน่งที่เหมาะสมในสคริปต์ ASP
＜% ตัวเลือกที่ชัดเจน
ชื่อจริงดิม
-
DimBirthDate
ชื่อ = จอห์น
-
วันเกิด = 1/1/1950
โทร writeTable()
-
＜ !-- #include file=inc2.asp -- >
/app2/include_2.asp ส่วน
พื้นฐาน = 5.57 มิลลิวินาที/เพจ
เวลาตอบสนอง = 6.08 มิลลิวินาที/หน้า
ส่วนต่าง=+0.51 มิลลิวินาที (เพิ่มขึ้น 9.2%)
สิ่งนี้มีผลกระทบต่อประสิทธิภาพมากกว่าการเรียกใช้ฟังก์ชัน ดังนั้น: ใช้ไฟล์รวมเมื่อมีการแชร์โค้ดระหว่างเพจเท่านั้น
มีการสร้างภาระงานเท่าใดเมื่อดำเนินการจัดการข้อผิดพลาด
การจัดการข้อผิดพลาดเป็นสิ่งจำเป็นสำหรับแอปพลิเคชันจริงทั้งหมด ในการทดสอบนี้ ตัวจัดการข้อผิดพลาดจะถูกเรียกโดยการเรียกใช้ฟังก์ชัน On Error Resume Next
＜% ตัวเลือกที่ชัดเจน
เมื่อเกิดข้อผิดพลาด ดำเนินการต่อต่อไป
ชื่อจริงดิม
-
/app2/error_1.asp ส่วน
พื้นฐาน = 5.57 มิลลิวินาที/เพจ
เวลาตอบสนอง = 5.67 มิลลิวินาที/หน้า
ส่วนต่าง = 0.10 มิลลิวินาที (เพิ่มขึ้น 1.8%)
อย่างที่คุณเห็น การจัดการข้อผิดพลาดมาพร้อมกับราคา เราสามารถแนะนำสิ่งต่อไปนี้: ใช้ตัวจัดการข้อผิดพลาดเฉพาะเมื่อมีบางอย่างเกิดขึ้นซึ่งอยู่นอกเหนือความสามารถในการทดสอบหรือควบคุมของคุณเท่านั้น ตัวอย่างพื้นฐานคือการใช้วัตถุ COM เพื่อเข้าถึงทรัพยากรอื่นๆ เช่นวัตถุ ADO หรือ FileSystem
การตั้งค่าตัวจัดการบริบทมีผลกระทบต่อประสิทธิภาพหรือไม่
เมื่อมีข้อผิดพลาดเกิดขึ้น การตั้งค่าตัวจัดการบริบทบนเพจจะทำให้สคริปต์สามารถย้อนกลับการดำเนินการได้ ซึ่งตั้งค่าโดยใช้คำสั่งการประมวลผลบนเพจ
＜ %@ ธุรกรรม = ต้องการ % ><
＜% ตัวเลือกที่ชัดเจน
ชื่อจริงดิม
-
/app2/transact1.asp ส่วน
พื้นฐาน = 5.57 มิลลิวินาที/เพจ
เวลาในการตอบสนอง = 13.39 มิลลิวินาที/หน้า
ส่วนต่าง = +7.82 มิลลิวินาที (เพิ่มขึ้น 140.4%)
อ่า! นี่เป็นผลลัพธ์ที่น่าทึ่งที่สุดอย่างแท้จริง ดังนั้นโปรดสังเกตกฎต่อไปนี้: ใช้บริบทการประมวลผลเฉพาะเมื่อมีการดำเนินการตั้งแต่สองรายการขึ้นไปเป็นหน่วยเดียว
สรุปแล้ว
สิ่งสำคัญในส่วนแรกของบทความนี้คือการสะสมสิ่งเล็กๆ น้อยๆ มากมาย เพื่อเน้นย้ำถึงปัญหานี้ ฉันจึงจัดทำการทดสอบครั้งสุดท้ายโดยทำทุกสิ่งที่เราเคยทดสอบก่อนหน้านี้ซึ่งดูไม่เป็นอันตราย แต่จริงๆ แล้วให้ผลเสีย ฉันรวมคำสั่ง Response.Write ไว้มากมาย ปิดบัฟเฟอร์ ตั้งค่าภาษาเริ่มต้น ลบการอ้างอิงตัวเลือกที่ชัดเจน และเตรียมใช้งานตัวจัดการข้อผิดพลาด
＜ %@ LANGUAGE=VBSCRIPT % >
-
เมื่อเกิดข้อผิดพลาด ดำเนินการต่อต่อไป
ชื่อ = จอห์น
-
วันเกิด = 1/1/1950
การตอบกลับเขียน(<html>)
ตอบกลับเขียน(<หัว>)
Response.Write(<หัวข้อ>การทดสอบการตอบสนอง</หัวข้อ>)
ตอบกลับเขียน(＜/หัว><)
ตอบกลับเขียน(<เนื้อหา>)
การตอบสนองเขียน(<h1>การทดสอบการตอบสนอง</h1>)
การตอบกลับเขียน(<ตาราง>)
Response.Write(＜ tr ＞＜ td ＞＜ b ＞ชื่อ:＜ /b ＞＜ /td ＞＜ td ＞ &_
ชื่อ & ＜ /td ＞＜ /tr ><)
-
Response.Write(＜ tr ＞＜ td ＞＜ b ＞วันเกิด:＜ /b ＞＜ /td ＞＜ td ＞ &_
วันเกิด & ＜ /td ＞＜ /tr ><)
Response.Write(＜/ตาราง><)
ตอบกลับเขียน(</body>)
ตอบกลับเขียน(</html>)
-
/app2/final_1.asp ส่วน
พื้นฐาน = 5.57 มิลลิวินาที/เพจ
เวลาตอบสนอง = 8.85 มิลลิวินาที/หน้า
ส่วนต่าง = +3.28 มิลลิวินาที (เพิ่มขึ้น 58.9%)
อาจฟังดูชัดเจน แต่สิ่งสำคัญกว่าคือต้องเข้าใจว่าโค้ดที่เราวางบนหน้าเว็บมีผลกระทบต่อประสิทธิภาพ การเปลี่ยนแปลงเล็กๆ น้อยๆ ในหน้าเว็บบางครั้งอาจเพิ่มเวลาตอบสนองได้อย่างมาก
สรุปกติกา
* หลีกเลี่ยงการใช้ ASP แบบอินไลน์มากเกินไป
* เชื่อมต่อคำสั่ง Response.Write ที่ต่อเนื่องกันเสมอให้เป็นคำสั่งเดียว
* ห้ามใช้ฟังก์ชัน wrapper รอบ Response.Write เพื่อผนวก CRLF
* หากต้องจัดรูปแบบเอาต์พุต HTML ให้ผนวก CRLF โดยตรงภายในคำสั่ง Response.Write
* เปิดใช้งานการบัฟเฟอร์ผ่านการตั้งค่าเซิร์ฟเวอร์เสมอ
* ตราบใดที่ใช้ในระดับปานกลาง คำอธิบายประกอบ ASP จะมีผลกระทบต่อประสิทธิภาพเพียงเล็กน้อยหรือไม่มีเลย
* ตั้งค่าการกำหนดค่าภาษาเริ่มต้นของเซิร์ฟเวอร์ให้ตรงกับภาษาที่ใช้บนเว็บไซต์
* อย่าตั้งค่าการประกาศภาษาเว้นแต่คุณจะใช้ภาษาที่ไม่ใช่ค่าเริ่มต้น
* ใช้ Option ชัดเจนใน VBScript เสมอ
* ปิดสถานะเซสชันที่ระดับเพจหรือแอปพลิเคชันเสมอเมื่อไม่จำเป็น
* ใช้รวมไฟล์เมื่อมีการแชร์โค้ดระหว่างเพจเท่านั้น
* บนเพจ หากจะใช้โค้ดมากกว่าหนึ่งครั้ง ให้ใส่โค้ดไว้ในพื้นที่ฟังก์ชัน
* เมื่อเหมาะสม ให้ย้ายการประกาศตัวแปรไปยังขอบเขตฟังก์ชัน
* ใช้ตัวจัดการข้อผิดพลาดเฉพาะเมื่อมีเงื่อนไขเกิดขึ้นซึ่งอยู่นอกเหนือความสามารถของการทดสอบหรือการควบคุมเท่านั้น
* ใช้การประมวลผลบริบทเฉพาะเมื่อมีการดำเนินการตั้งแต่สองรายการขึ้นไปเป็นหน่วยเดียว
เมื่อมองย้อนกลับไปในตอนนี้ มีคำถามหลายข้อที่สามารถใช้เป็นแนวทางทั่วไปได้:
* หลีกเลี่ยงความซ้ำซ้อน - อย่าตั้งค่าคุณสมบัติที่ตั้งค่าไว้เป็นค่าเริ่มต้นแล้ว
* จำกัดจำนวนการเรียกใช้ฟังก์ชัน
* ลดขอบเขตของโค้ด