10 วิธียอดนิยมในการปรับปรุงประสิทธิภาพของแอปพลิเคชัน ASP.Net
ผู้เขียน：Eve Cole
เวลาอัปเดต：2009-06-30 15:49:49
บทความนี้กล่าวถึง:
ตำนานที่เล่ากันทั่วไปเกี่ยวกับการปรับปรุงประสิทธิภาพของแอปพลิเคชัน asp.net เคล็ดลับที่เป็นประโยชน์ในการปรับปรุงประสิทธิภาพของแอปพลิเคชัน asp.net
คำแนะนำสำหรับฐานข้อมูลปฏิบัติการด้วยแอปพลิเคชัน Asp.net
แคชและการประมวลผลพื้นหลังใน Asp.net
ปัจจุบันนี้ การเขียนแอปพลิเคชันเว็บ ASP.NET กลายเป็นเรื่องง่าย และโปรแกรมเมอร์จำนวนมากไม่ต้องการใช้เวลาสร้างแอปพลิเคชันที่มีประสิทธิภาพดี บทความนี้จะกล่าวถึงวิธีสิบอันดับแรกในการปรับปรุงประสิทธิภาพของเว็บแอปพลิเคชัน ฉันจะไม่จำกัดการสนทนาของฉันอยู่เพียงแอปพลิเคชัน ASP.NET เนื่องจากเป็นเพียงส่วนย่อยของแอปพลิเคชันเว็บเท่านั้น บทความนี้ยังไม่สามารถให้คำแนะนำฉบับสมบูรณ์ในการปรับปรุงประสิทธิภาพการทำงานของเว็บแอปพลิเคชันได้ เนื่องจากจะต้องมีความยาวเท่ากับหนังสือ บทความนี้เป็นเพียงจุดเริ่มต้นที่ดีสำหรับการปรับปรุงประสิทธิภาพของแอปพลิเคชันเว็บ (เหลืออย่างเดียวคือต้องค่อยๆศึกษาด้วยตัวเอง)
นอกเวลางานฉันมักจะไปปีนผาก่อนทุกครั้งฉันจะทบทวนแผนที่เส้นทางปีนหน้าผาและอ่านคำแนะนำของนักปีนเขาที่ประสบความสำเร็จคนก่อนๆ เพราะเราต้องการประสบการณ์ความสำเร็จของพวกเขา ในทำนองเดียวกัน เมื่อคุณต้องการแก้ไขโปรแกรมที่มีปัญหาด้านประสิทธิภาพหรือพัฒนาเว็บไซต์ประสิทธิภาพสูง คุณยังต้องเรียนรู้วิธีเขียนเว็บแอปพลิเคชันประสิทธิภาพสูงด้วย
ประสบการณ์ส่วนตัวของฉันส่วนใหญ่มาจากการทำงานเป็นผู้จัดการโปรแกรมในกลุ่ม asp.net ของ Microsoft ใช้งานและจัดการเว็บไซต์ www.asp.net และช่วยเหลือในการพัฒนา Community Server (ซึ่งเป็นเวอร์ชันรวมและอัปเกรดของ asp.net Forums , .Text และซอฟต์แวร์ nGallery) ฉันคิดว่าประสบการณ์เหล่านี้สามารถช่วยฉันได้
คุณอาจนึกถึงการแบ่งแอปพลิเคชันของคุณออกเป็นเลเยอร์ลอจิคัลต่างๆ คุณอาจเคยได้ยินเกี่ยวกับสถาปัตยกรรมทางกายภาพสามระดับหรือสถาปัตยกรรม N-tier ซึ่งเป็นโมเดลสถาปัตยกรรมที่ใช้กันมากที่สุด โดยจะกำหนดฟังก์ชันโปรแกรมต่างๆ ให้กับฮาร์ดแวร์ต่างๆ เพื่อดำเนินการ ด้วยวิธีนี้ หากเราต้องการปรับปรุงประสิทธิภาพของแอปพลิเคชัน การเพิ่มฮาร์ดแวร์บางตัวก็สามารถบรรลุเป้าหมายได้ มีเหตุผลว่าวิธีนี้สามารถปรับปรุงประสิทธิภาพของแอปพลิเคชันได้ แต่เราควรหลีกเลี่ยงการใช้วิธีนี้ ดังนั้นเมื่อใดก็ตามที่เป็นไปได้ เราควรใส่เพจ ASP.NET และส่วนประกอบที่ใช้ในแอปพลิเคชัน
เนื่องจากการปรับใช้แบบกระจายและการใช้บริการเว็บหรือระยะไกล จะลดประสิทธิภาพของแอปพลิเคชันลง 20% หรือมากกว่า
ชั้นข้อมูลจะแตกต่างออกไปเล็กน้อย ควรปรับใช้แยกกันจะดีกว่าและใช้ฮาร์ดแวร์แยกต่างหากเพื่อเรียกใช้งาน อย่างไรก็ตาม ฐานข้อมูลยังคงเป็นคอขวดของประสิทธิภาพของแอปพลิเคชัน ดังนั้น เมื่อคุณต้องการเพิ่มประสิทธิภาพโปรแกรม สิ่งแรกที่ต้องคำนึงถึงคือการปรับชั้นข้อมูลให้เหมาะสม
ก่อนที่คุณจะแก้ไขพื้นที่แอปพลิเคชันของคุณที่ทำให้เกิดปัญหาด้านประสิทธิภาพ คุณจะต้องตรวจสอบให้แน่ใจว่าโปรแกรมที่เป็นสาเหตุของปัญหานั้นดูแน่นหนา เครื่องมือสร้างโปรไฟล์ประสิทธิภาพมีประโยชน์มากในการค้นหาว่าแอปพลิเคชันของคุณใช้เวลานานเท่าใด เหล่านี้เป็นสถานที่ที่เราไม่สามารถรู้สึกได้โดยสัญชาตญาณ
บทความนี้กล่าวถึงการปรับประสิทธิภาพให้เหมาะสมสองประเภท ประเภทหนึ่งคือการเพิ่มประสิทธิภาพครั้งใหญ่ (การเพิ่มประสิทธิภาพครั้งใหญ่) เช่น การใช้แคชของ asp.net และอีกประเภทหนึ่งคือการเพิ่มประสิทธิภาพเล็กน้อย (การเพิ่มประสิทธิภาพเล็กน้อย) การปรับปรุงประสิทธิภาพเล็กน้อยอาจมีประโยชน์มากในบางครั้ง คุณทำการเปลี่ยนแปลงโค้ดของคุณเล็กน้อยและเรียกมันครั้งละพันหรือหมื่นครั้ง ทำการเพิ่มประสิทธิภาพครั้งใหญ่แล้วคุณจะเห็นการปรับปรุงความเร็วของแอปพลิเคชันของคุณอย่างมาก การเพิ่มประสิทธิภาพประสิทธิภาพเล็กน้อยอาจปรับปรุงได้เพียงหนึ่งไมโครวินาทีต่อการร้องขอ แต่หากจำนวนคำขอต่อวันมีขนาดใหญ่ แอปพลิเคชันจะมีการปรับปรุงประสิทธิภาพอย่างมีนัยสำคัญ
ประสิทธิภาพของชั้นข้อมูล
เมื่อคุณต้องการเพิ่มประสิทธิภาพการทำงานของแอปพลิเคชัน คุณสามารถทำงานตามลำดับต่อไปนี้: รหัสของคุณจำเป็นต้องเข้าถึงฐานข้อมูลหรือไม่ หากเป็นเช่นนั้น ควรเข้าถึงฐานข้อมูลบ่อยแค่ไหน? ในทำนองเดียวกัน วิธีการทดสอบนี้สามารถใช้ในโค้ดโปรแกรมที่ใช้บริการเว็บหรือระยะไกลได้ บทความนี้จะไม่กล่าวถึงปัญหาการปรับโปรแกรมให้เหมาะสมโดยใช้บริการบนเว็บและระยะไกล
หากมีคำขอในโค้ดของคุณที่ต้องเข้าถึงฐานข้อมูล และคุณเห็นโค้ดที่ใช้ฟังก์ชันเดียวกันในที่อื่น คุณจะต้องปรับให้เหมาะสมก่อน แก้ไขและปรับปรุงและทดสอบต่อ เว้นแต่คุณจะมีปัญหาด้านประสิทธิภาพที่ใหญ่มาก เวลาของคุณจะถูกนำไปใช้ในการเพิ่มประสิทธิภาพการสืบค้น การเชื่อมต่อกับฐานข้อมูล การส่งคืนขนาดของชุดข้อมูล และเวลาที่ใช้ในการส่งคืนการสืบค้น
จากประสบการณ์สรุป เรามาดูประสบการณ์ 10 ประการที่สามารถช่วยคุณปรับปรุงประสิทธิภาพของแอปพลิเคชันของคุณได้ ฉันจะอธิบายตามลำดับจากประสบการณ์ที่ใหญ่ที่สุดไปหาน้อยที่สุดในแง่ของการปรับปรุงประสิทธิภาพ
1. ส่งคืนชุดข้อมูลหลายชุด
ตรวจสอบรหัสการเข้าถึงฐานข้อมูลของคุณเพื่อดูว่ามีคำขอใดๆ ที่ส่งคืนหลายครั้งหรือไม่ การเดินทางไปกลับแต่ละครั้งจะลดจำนวนคำขอต่อวินาทีที่แอปพลิเคชันของคุณสามารถตอบสนองได้ ด้วยการส่งคืนชุดผลลัพธ์หลายชุดในคำขอฐานข้อมูลเดียว คุณจะลดเวลาที่ใช้ในการสื่อสารกับฐานข้อมูล ทำให้ระบบของคุณสามารถปรับขนาดได้ และลดภาระงานบนเซิร์ฟเวอร์ฐานข้อมูลเพื่อตอบสนองต่อคำขอ
หากคุณใช้คำสั่ง SQL แบบไดนามิกเพื่อส่งคืนชุดข้อมูลหลายชุด ฉันขอแนะนำให้คุณใช้กระบวนงานที่เก็บไว้แทนคำสั่ง SQL แบบไดนามิก การเขียนตรรกะทางธุรกิจลงในขั้นตอนการจัดเก็บนั้นเป็นเรื่องที่ถกเถียงกันเล็กน้อยหรือไม่ แต่ฉันคิดว่าการเขียนตรรกะทางธุรกิจลงในขั้นตอนการจัดเก็บสามารถจำกัดขนาดของชุดผลลัพธ์ที่ส่งคืน ลดการรับส่งข้อมูลเครือข่าย และไม่จำเป็นต้องกรองข้อมูลที่ชั้นลอจิก ซึ่งเป็นสิ่งที่ดี
ใช้เมธอด ExecuteReader ของวัตถุ SqlCommand เพื่อส่งกลับออบเจ็กต์ทางธุรกิจที่พิมพ์อย่างยิ่ง และจากนั้น เรียกเมธอด NextResult เพื่อย้ายตัวชี้ชุดข้อมูลเพื่อค้นหาชุดข้อมูล ตัวอย่างที่ 1 สาธิตตัวอย่างการส่งคืนอ็อบเจ็กต์ ArrayList ที่พิมพ์อย่างรุนแรงหลายรายการ การส่งคืนเฉพาะข้อมูลที่คุณต้องการจากฐานข้อมูลสามารถลดการใช้หน่วยความจำของเซิร์ฟเวอร์ของคุณได้อย่างมาก
2. การเพจข้อมูล
งูเห่า. DataGrid ของ NET มีคุณสมบัติที่มีประโยชน์มาก: การเพจ หาก DataGrid อนุญาตให้มีการเพจ มันจะดาวน์โหลดเฉพาะข้อมูลของเพจบางเพจในช่วงเวลาหนึ่งเท่านั้น นอกจากนี้ยังมีแถบนำทางสำหรับเพจข้อมูล ซึ่งให้คุณเลือกที่จะเรียกดูเพจบางเพจ และดาวน์โหลดเพียงเพจเดียวของ ข้อมูลในแต่ละครั้ง
แต่มีข้อเสียเล็กน้อย นั่นคือ คุณต้องผูกข้อมูลทั้งหมดเข้ากับ DataGrid กล่าวอีกนัยหนึ่ง ชั้นข้อมูลของคุณจะต้องส่งคืนข้อมูลทั้งหมด จากนั้น DataGrid จะกรองข้อมูลที่จำเป็นสำหรับหน้าปัจจุบันออกและแสดงข้อมูลดังกล่าว หากมีชุดผลลัพธ์ 10,000 ระเบียนที่ต้องแบ่งหน้าโดยใช้ DataGrid โดยสมมติว่า DataGrid แสดงข้อมูลเพียง 25 ชิ้นต่อหน้า หมายความว่าข้อมูล 9,975 ชิ้นจะถูกยกเลิกในแต่ละคำขอ คำขอแต่ละรายการจะต้องส่งคืนชุดข้อมูลขนาดใหญ่ดังกล่าว ซึ่งมีผลกระทบอย่างมากต่อประสิทธิภาพของแอปพลิเคชัน
ทางออกที่ดีคือการเขียนขั้นตอนการจัดเก็บเพจจิ้ง ตัวอย่างที่ 2 คือขั้นตอนการจัดเก็บเพจจิ้งสำหรับตารางคำสั่งซื้อของฐานข้อมูล Northwind คุณจะต้องส่งผ่านหมายเลขหน้าปัจจุบันและจำนวนรายการที่แสดงในแต่ละหน้า และขั้นตอนการจัดเก็บจะส่งกลับผลลัพธ์ที่เกี่ยวข้อง
ที่ฝั่งเซิร์ฟเวอร์ ฉันเขียนตัวควบคุมการเพจเป็นพิเศษเพื่อจัดการเพจข้อมูล ในที่นี้ ฉันใช้วิธีแรกและส่งคืนชุดผลลัพธ์สองชุดในขั้นตอนการจัดเก็บ: จำนวนบันทึกข้อมูลทั้งหมดและชุดผลลัพธ์ที่ต้องการ
จำนวนบันทึกทั้งหมดที่ส่งคืนขึ้นอยู่กับการสืบค้นที่กำลังดำเนินการ ตัวอย่างเช่น เงื่อนไขสามารถจำกัดขนาดของชุดผลลัพธ์ที่ส่งคืน เนื่องจากต้องคำนวณจำนวนเพจทั้งหมดตามขนาดของเรกคอร์ดชุดข้อมูลในอินเทอร์เฟซการเพจ จึงต้องส่งคืนจำนวนเรกคอร์ดในชุดผลลัพธ์ ตัวอย่างเช่น ถ้ามีทั้งหมด 1,000,000 เรกคอร์ด ถ้าคุณใช้เงื่อนไข โดย คุณสามารถกรองให้ส่งคืนเพียง 1,000 เรกคอร์ดได้ ตรรกะการแบ่งหน้าของกระบวนงานที่เก็บไว้ควรทราบเพื่อส่งคืนข้อมูลที่จำเป็นต้องแสดง
3. พูลการเชื่อมต่อ
การใช้ TCP เพื่อเชื่อมต่อแอปพลิเคชันของคุณกับฐานข้อมูลมีราคาแพง (และใช้เวลานาน) นักพัฒนา Microsoft สามารถใช้พูลการเชื่อมต่อเพื่อใช้การเชื่อมต่อฐานข้อมูลซ้ำได้ แทนที่จะใช้ TCP เพื่อเชื่อมต่อกับฐานข้อมูลสำหรับแต่ละคำขอ พูลการเชื่อมต่อจะสร้างการเชื่อมต่อ TCP ใหม่เมื่อไม่มีการเชื่อมต่อที่ถูกต้องเท่านั้น เมื่อปิดการเชื่อมต่อ การเชื่อมต่อนั้นจะถูกวางไว้ในพูลและจะยังคงรักษาการเชื่อมต่อกับฐานข้อมูล ซึ่งจะช่วยลดจำนวนการเชื่อมต่อ TCP ไปยังฐานข้อมูล
แน่นอนคุณควรใส่ใจกับการเชื่อมต่อที่คุณลืมปิด คุณควรปิดทันทีหลังการใช้งานแต่ละครั้ง สิ่งที่ฉันต้องการเน้นคือ: ไม่ว่าใครจะพูดอะไรก็ตาม GC (ตัวรวบรวมขยะ) ในเฟรมเวิร์ก .net จะเรียกเมธอด Close หรือ Dispose ของออบเจ็กต์การเชื่อมต่อเพื่อปิดการเชื่อมต่อของคุณอย่างชัดเจนหลังจากที่คุณใช้ออบเจ็กต์การเชื่อมต่อเสร็จแล้ว อย่าคาดหวังว่า CLR จะปิดการเชื่อมต่อภายในเวลาที่คุณจินตนาการ แม้ว่าในที่สุด CLR จะทำลายวัตถุและปิดการเชื่อมต่อ แต่เราไม่แน่ใจว่าจะทำสิ่งเหล่านี้เมื่อใด
เมื่อต้องการใช้การปรับพูลการเชื่อมต่อให้เหมาะสม มีสองกฎ ขั้นแรก ให้เปิดการเชื่อมต่อ ประมวลผลข้อมูล แล้วปิดการเชื่อมต่อ หากคุณต้องเปิดหรือปิดการเชื่อมต่อหลายครั้งต่อการร้องขอ จะดีกว่าการเปิดการเชื่อมต่อด้านข้างตลอดเวลาและส่งต่อไปยังแต่ละวิธี ประการที่สอง ใช้สตริงการเชื่อมต่อเดียวกัน (หรือ ID ผู้ใช้เดียวกัน เมื่อคุณใช้การรับรองความถูกต้องแบบรวม) หากคุณไม่ได้ใช้สตริงการเชื่อมต่อเดียวกัน ตัวอย่างเช่น หากคุณใช้สตริงการเชื่อมต่อโดยอิงตามผู้ใช้ที่เข้าสู่ระบบ สิ่งนี้จะไม่ใช้ประโยชน์จากคุณลักษณะการปรับให้เหมาะสมของพูลการเชื่อมต่อ หากคุณกำลังใช้อาร์กิวเมนต์แบบรวม คุณจะไม่สามารถใช้ประโยชน์จากฟังก์ชันการปรับให้เหมาะสมที่สุดของพูลการเชื่อมต่อได้อย่างเต็มที่ เนื่องจากมีผู้ใช้จำนวนมาก .NET CLR มีตัวนับประสิทธิภาพข้อมูล ซึ่งมีประโยชน์มากเมื่อเราต้องการติดตามลักษณะประสิทธิภาพของโปรแกรม รวมถึงการติดตามพูลการเชื่อมต่อ
เมื่อใดก็ตามที่แอปพลิเคชันของคุณเชื่อมต่อกับทรัพยากรบนเครื่องอื่น เช่น ฐานข้อมูล คุณควรมุ่งเน้นไปที่การปรับเวลาที่ใช้ในการเชื่อมต่อกับทรัพยากรให้เหมาะสม เวลาที่ใช้ในการรับและส่งข้อมูล และจำนวนครั้งที่คุณย้อนกลับ . การเพิ่มประสิทธิภาพทุกกระบวนการในแอปพลิเคชันของคุณเป็นจุดเริ่มต้นในการปรับปรุงประสิทธิภาพของแอปพลิเคชันของคุณ
ชั้นแอปพลิเคชันประกอบด้วยตรรกะในการเชื่อมต่อกับชั้นข้อมูล ถ่ายโอนข้อมูลไปยังอินสแตนซ์ของคลาสที่เกี่ยวข้อง และการประมวลผลทางธุรกิจ ตัวอย่างเช่น ใน Community Server คุณต้องประกอบคอลเล็กชัน Forums หรือ Threads จากนั้นใช้ตรรกะทางธุรกิจ เช่น การอนุญาต ที่สำคัญกว่านั้น คุณต้องดำเนินการตรรกะการแคชที่นี่
4. เอเอสพี. NET แคช API
ก่อนที่จะเขียนแอปพลิเคชัน สิ่งแรกที่คุณต้องทำคือทำให้แอปพลิเคชันใช้ความสามารถในการแคชของ ASP.NET ให้เกิดประโยชน์สูงสุด
หากคอมโพเนนต์ของคุณจะถูกรันในแอปพลิเคชัน Asp.net คุณจะต้องอ้างอิง System.Web.dll ในโครงการของคุณเท่านั้น จากนั้นใช้คุณสมบัติ HttpRuntime.Cache เพื่อเข้าถึงแคช (สามารถเข้าถึงได้ผ่าน Page.Cache หรือ HttpContext.Cache)
มีกฎหลายข้อสำหรับการแคชข้อมูล ขั้นแรก ข้อมูลอาจถูกนำมาใช้บ่อยครั้งและข้อมูลนี้สามารถแคชได้ ประการที่สอง ความถี่ในการเข้าถึงข้อมูลสูงมาก หรือความถี่ในการเข้าถึงข้อมูลไม่สูง แต่วงจรการใช้งานยาวนานมาก วิธีที่ดีที่สุดคือแคชข้อมูลดังกล่าว ปัญหาที่สามคือปัญหาที่มักถูกละเลย บางครั้งเราแคชข้อมูลมากเกินไป โดยปกติแล้วในเครื่อง X86 หากข้อมูลที่คุณต้องการแคชเกิน 800M ข้อผิดพลาดหน่วยความจำล้นจะเกิดขึ้น ดังนั้นแคชจึงมีจำกัด กล่าวอีกนัยหนึ่ง คุณควรประมาณขนาดของชุดแคชและจำกัดขนาดของแคชที่ตั้งค่าให้น้อยกว่า 10 มิฉะนั้นอาจทำให้เกิดปัญหาได้ ใน Asp.net ถ้าแคชมีขนาดใหญ่เกินไป ข้อผิดพลาดหน่วยความจำล้นจะถูกรายงาน โดยเฉพาะอย่างยิ่งถ้าวัตถุชุดข้อมูลขนาดใหญ่ถูกแคชไว้
ต่อไปนี้เป็นกลไกการแคชที่สำคัญบางประการที่คุณต้องเข้าใจ ขั้นแรก แคชใช้หลักการ "ที่ใช้ล่าสุด" (อัลกอริธึมที่ใช้น้อยที่สุด) เมื่อมีแคชน้อย แคชจะล้างแคชที่ไม่มีประโยชน์โดยอัตโนมัติ ประการที่สองหลักการของ"การพึ่งพาตามเงื่อนไข" บังคับกำจัด (การพึ่งพาการหมดอายุ) เงื่อนไขสามารถเป็นเวลาคำหลักและไฟล์ เวลาเป็นเงื่อนไขที่ใช้บ่อยที่สุด มีการเพิ่มเงื่อนไขที่แข็งแกร่งกว่าใน asp.net2.0 ซึ่งเป็นเงื่อนไขของฐานข้อมูล เมื่อข้อมูลในฐานข้อมูลเปลี่ยนแปลง แคชจะถูกบังคับให้ล้าง หากต้องการเจาะลึกมากขึ้นเกี่ยวกับการขึ้นต่อกันแบบมีเงื่อนไขของฐานข้อมูล โปรดดูคอลัมน์ Cutting Edge ของ Dino Esposito ในนิตยสาร MSDN ฉบับเดือนกรกฎาคม พ.ศ. 2547 สถาปัตยกรรมแคชของ Asp.net แสดงในรูปด้านล่าง:
5. ขอแคชล่วงหน้า
ก่อนหน้านี้ ฉันได้กล่าวไว้ว่าแม้ว่าเราจะปรับปรุงประสิทธิภาพเพียงเล็กน้อยในบางที่ แต่เราก็สามารถได้รับการปรับปรุงประสิทธิภาพครั้งใหญ่ได้ ฉันชอบใช้การแคชล่วงหน้าเพื่อปรับปรุงประสิทธิภาพของโปรแกรม
แม้ว่า Cache API ได้รับการออกแบบมาเพื่อบันทึกข้อมูลในช่วงระยะเวลาหนึ่ง แต่แคชที่ร้องขอล่วงหน้าจะบันทึกเฉพาะเนื้อหาของคำขอบางรายการในช่วงระยะเวลาหนึ่งเท่านั้น หากความถี่ในการเข้าถึงคำขอบางรายการสูง และคำขอนี้จำเป็นต้องแยก ใช้ แก้ไข หรืออัปเดตข้อมูลเพียงครั้งเดียว จากนั้นคำขอสามารถแคชล่วงหน้าได้ ลองยกตัวอย่างเพื่อแสดง
ในแอปพลิเคชันฟอรัม CS การควบคุมเซิร์ฟเวอร์ของแต่ละเพจต้องใช้ข้อมูลที่ปรับแต่งเพื่อกำหนดสกิน เพื่อกำหนดสไตล์ชีตที่จะใช้และสิ่งส่วนตัวอื่น ๆ ข้อมูลบางส่วนที่นี่อาจจำเป็นต้องได้รับการบันทึกเป็นเวลานาน แต่บางครั้งอาจไม่เป็นเช่นนั้น ตัวอย่างเช่น ข้อมูลสกินของตัวควบคุมจำเป็นต้องใช้เพียงครั้งเดียวและสามารถใช้ได้ตลอดเวลา
หากต้องการใช้การแคชคำขอล่วงหน้า ให้ใช้คลาส HttpContext ของ Asp.net อินสแตนซ์ของคลาส HttpContext จะถูกสร้างขึ้นในทุกคำขอ และสามารถเข้าถึงได้ผ่านคุณสมบัติ HttpContext.Current ที่ใดก็ได้ในระหว่างการร้องขอ คลาส HttpContext มีคุณสมบัติการรวบรวมรายการ และวัตถุและข้อมูลทั้งหมดจะถูกเพิ่มในคอลเลกชันนี้และแคชในระหว่างการร้องขอ เช่นเดียวกับที่คุณใช้แคชเพื่อแคชข้อมูลที่เข้าถึงบ่อย คุณสามารถใช้ HttpContext.Items เพื่อแคชข้อมูลพื้นฐานที่ใช้ในแต่ละคำขอได้ ตรรกะเบื้องหลังนั้นง่ายมาก: เราเพิ่มข้อมูลลงใน HttpContext.Items แล้วอ่านข้อมูลจากข้อมูลนั้น
6. การประมวลผลเบื้องหลัง
ด้วยวิธีการข้างต้น แอปพลิเคชันของคุณควรทำงานเร็วมากใช่ไหม? แต่ในบางจุด คำขอในโปรแกรมอาจใช้เวลานานมาก เช่น การส่งอีเมล หรือการตรวจสอบความถูกต้องของข้อมูลที่ส่งมา เป็นต้น
เมื่อเรารวม asp.net Forums 1.0 เข้ากับ CS เราพบว่าการส่งโพสต์ใหม่จะช้ามาก ทุกครั้งที่มีการเพิ่มโพสต์ใหม่ แอปพลิเคชันจะต้องตรวจสอบก่อนว่าโพสต์นั้นซ้ำหรือไม่ จากนั้นกรองโดยใช้ตัวกรอง "badword" ตรวจสอบโค้ดไฟล์แนบรูปภาพ จัดทำดัชนีโพสต์ และเพิ่มลงในคิวที่เหมาะสม ตรวจสอบ ไฟล์แนบ และสุดท้าย ส่งอีเมลไปยังกล่องจดหมายของสมาชิก แน่นอนว่านี่เป็นงานจำนวนมาก
ผลลัพธ์คือใช้เวลามากในการจัดทำดัชนีและส่งอีเมล การจัดทำดัชนีโพสต์เป็นการดำเนินการที่ใช้เวลานาน และการส่งอีเมลไปยังสมาชิกจำเป็นต้องเชื่อมต่อกับบริการ SMTP จากนั้นจึงส่งอีเมลไปยังสมาชิกแต่ละราย เมื่อจำนวนสมาชิกเพิ่มขึ้น เวลาที่ใช้ในการส่งอีเมลก็จะนานขึ้น
ไม่จำเป็นต้องทริกเกอร์การจัดทำดัชนีและการส่งอีเมลในทุกคำขอ ตามหลักการแล้ว เราต้องการประมวลผลการดำเนินการเหล่านี้เป็นชุด โดยส่งอีเมลครั้งละ 25 ฉบับเท่านั้น หรือส่งอีเมลใหม่ทั้งหมดทุกๆ 5 นาที เราตัดสินใจใช้โค้ดเดียวกันกับแคชต้นแบบฐานข้อมูล แต่ล้มเหลว เราจึงต้องกลับไปใช้ VS.NET 2005
เราพบคลาส Timer ใต้เนมสเปซ System.Threading คลาสนี้มีประโยชน์มาก แต่มีเพียงไม่กี่คนที่รู้ และนักพัฒนาเว็บยังน้อยคนนักที่จะรู้ เมื่อเขาสร้างอินสแตนซ์ของคลาสนี้ คลาส Timer จะเรียกใช้ฟังก์ชันการเรียกกลับที่ระบุจากเธรดในเธรดพูลทุกครั้งที่ระบุ ซึ่งหมายความว่าแอปพลิเคชัน ASP.NET ของคุณสามารถทำงานได้แม้ว่าจะไม่มีการร้องขอก็ตาม นี่คือวิธีแก้ปัญหาที่จะต้องจัดการในภายหลัง คุณสามารถให้การจัดทำดัชนีและการส่งอีเมลทำงานอยู่เบื้องหลัง แทนที่จะต้องดำเนินการกับทุกคำขอ
มีปัญหาสองประการเกี่ยวกับเทคโนโลยีที่ทำงานอยู่เบื้องหลัง ปัญหาแรกคือเมื่อโดเมนแอปพลิเคชันของคุณถูกถอนการติดตั้ง อินสแตนซ์คลาส Timer จะหยุดทำงาน นั่นคือวิธีการโทรกลับจะไม่ถูกเรียก นอกจากนี้ เนื่องจากมีหลายเธรดที่ทำงานอยู่ในแต่ละกระบวนการของ CLR จึงเป็นเรื่องยากสำหรับคุณที่จะรับเธรดเพื่อให้ Timer ดำเนินการ หรือจะสามารถดำเนินการได้ แต่จะล่าช้า เลเยอร์ Asp.net ควรใช้เทคนิคนี้น้อยที่สุดเท่าที่จะเป็นไปได้เพื่อลดจำนวนเธรดในกระบวนการ หรืออนุญาตให้ร้องขอเฉพาะส่วนเล็กๆ ของเธรดเท่านั้น แน่นอนว่าคุณสามารถใช้มันได้ก็ต่อเมื่อคุณมีงานอะซิงโครนัสจำนวนมากเท่านั้น
มีพื้นที่ไม่เพียงพอที่จะโพสต์โค้ดที่นี่ คุณสามารถดาวน์โหลดโปรแกรมตัวอย่างได้จาก http://www.rob-howard.net/ โปรดดาวน์โหลดโปรแกรมตัวอย่าง Blackbelt TechEd 2004
7. แคชเอาต์พุตหน้าและบริการพร็อกซี
Asp.net เป็นเลเยอร์อินเทอร์เฟซของคุณ (หรือควรจะเป็น) ประกอบด้วยเพจ การควบคุมผู้ใช้ การควบคุมเซิร์ฟเวอร์ (HttpHandlers และ HttpModules) และเนื้อหาที่สร้างขึ้น หากคุณมีเพจ Asp.net ที่แสดงผล html, xml, imgae หรือข้อมูลอื่นๆ และคุณใช้โค้ดเพื่อสร้างเนื้อหาเอาต์พุตเดียวกันสำหรับแต่ละคำขอ คุณจะต้องพิจารณาใช้การแคชเอาต์พุตเพจ
คุณสามารถทำได้โดยคัดลอกบรรทัดโค้ดต่อไปนี้ลงในเพจของคุณ:
<%@ PageOutputCache VaryByParams=”none” ระยะเวลา=”60” %>
คุณสามารถใช้เพจที่สร้างขึ้นในคำขอแรกเพื่อส่งออกเนื้อหาแคช และสร้างเนื้อหาของเพจใหม่หลังจากผ่านไป 60 วินาที เทคโนโลยีนี้ถูกนำมาใช้จริงโดยใช้ Cache API ระดับต่ำบางตัว มีพารามิเตอร์หลายตัวที่สามารถกำหนดค่าสำหรับการแคชเอาต์พุตของเพจได้ เช่น พารามิเตอร์ VaryByParams ที่กล่าวถึงข้างต้น พารามิเตอร์นี้บ่งชี้ว่าเมื่อใดที่จะทริกเกอร์เงื่อนไขเอาต์พุตใหม่ คุณยังสามารถระบุให้แคชเอาต์พุตในโหมดคำขอ Http Get หรือ Http Post ตัวอย่างเช่น เมื่อเราตั้งค่าพารามิเตอร์นี้เป็น VaryByParams="Report" ผลลัพธ์ที่ร้องขอโดย default.aspx?Report=1 หรือ default.aspx?Report=2 จะถูกแคช ค่าของพารามิเตอร์สามารถเป็นได้หลายพารามิเตอร์โดยคั่นด้วยเครื่องหมายอัฒภาค
หลายๆ คนไม่ทราบว่าเมื่อใช้แคชเอาต์พุตเพจ ASP.NET จะสร้างชุดส่วนหัว HTTP (ส่วนหัว HTTP) และบันทึกไว้ในเซิร์ฟเวอร์แคชดาวน์สตรีม ข้อมูลนี้สามารถนำไปใช้เพื่อความปลอดภัยทางอินเทอร์เน็ตของ Microsoft และเพื่อเพิ่มความเร็ว ความเร็วในการตอบสนองของเซิร์ฟเวอร์ เมื่อรีเซ็ตส่วนหัวแคช HTTP เนื้อหาที่ร้องขอจะถูกแคชไว้ในทรัพยากรเครือข่าย เมื่อไคลเอนต์ร้องขอเนื้อหาอีกครั้ง เนื้อหานั้นจะไม่ได้รับเนื้อหาจากเซิร์ฟเวอร์ต้นทางอีกต่อไป แต่จะรับเนื้อหาจากแคชโดยตรง
แม้ว่าการใช้แคชผลลัพธ์ของเพจจะไม่ปรับปรุงประสิทธิภาพของแอปพลิเคชันของคุณ แต่จะลดจำนวนครั้งที่เนื้อหาเพจที่แคชไว้ถูกโหลดจากเซิร์ฟเวอร์ แน่นอนว่านี่จำกัดเฉพาะหน้าแคชที่ผู้ใช้ที่ไม่ระบุชื่อเข้าถึงได้ เนื่องจากเมื่อเพจถูกแคชแล้ว การดำเนินการให้สิทธิ์จะไม่สามารถดำเนินการได้อีกต่อไป
8. ใช้เคอร์เนลแคชของ IIS6.0
หากแอปพลิเคชันของคุณไม่ได้ทำงานใน IIS 6.0 (Windows Server 2003) แสดงว่าคุณสูญเสียวิธีการปรับปรุงประสิทธิภาพของแอปพลิเคชันที่ยอดเยี่ยมไปบางส่วนแล้ว ในวิธีที่เจ็ด ฉันได้พูดคุยเกี่ยวกับวิธีใช้การแคชเอาต์พุตหน้าเพื่อปรับปรุงประสิทธิภาพของแอปพลิเคชัน ใน IIS5.0 เมื่อมีการร้องขอไปยัง IIS IIS จะถ่ายโอนไปยัง asp.net เมื่อใช้แคชเอาต์พุตเพจ HttpHandler ใน ASP.NET จะได้รับคำขอ และ HttpHandler จะถ่ายโอนเนื้อหาจากแคช . นำออกแล้วส่งคืน.
หากคุณใช้ IIS6.0 จะมีฟีเจอร์ที่ดีมากที่เรียกว่า Kernel Caching และคุณไม่จำเป็นต้องแก้ไขโค้ดใดๆ ในโปรแกรม asp.net เมื่อ asp.net ได้รับคำขอแคช Kernel Cache ของ IIS จะได้รับสำเนาคำขอจากแคช เมื่อคำขอมาจากเครือข่าย เลเยอร์เคอร์เนลจะได้รับคำขอ หากคำขอถูกแคชไว้ ก็จะส่งคืนข้อมูลที่แคชไว้โดยตรง และคุณก็ดำเนินการเสร็จสิ้น ซึ่งหมายความว่าเมื่อคุณใช้ IIS Kernel Caching เพื่อแคชเอาต์พุตเพจ คุณจะได้รับการปรับปรุงประสิทธิภาพการทำงานที่น่าทึ่ง เมื่อพัฒนา asp.net สำหรับ VS.NET 2005 ฉันเป็นผู้จัดการโปรแกรมที่รับผิดชอบด้านประสิทธิภาพของ asp.net โดยเฉพาะ โปรแกรมเมอร์ของฉันใช้วิธีนี้ ฉันดูข้อมูลรายงานรายวันทั้งหมดและพบผลลัพธ์ของการใช้แคชโมเดลเคอร์เนล เร็วที่สุด คุณลักษณะทั่วไปคือคำขอและการตอบกลับของเครือข่ายมีขนาดใหญ่ แต่ IIS ใช้ทรัพยากร CPU เพียง 5% เท่านั้น นี่มันน่าทึ่งมาก มีเหตุผลหลายประการสำหรับคุณที่จะใช้ IIS 6.0 แต่การใช้เคอร์เนลแคชเป็นเหตุผลที่ดีที่สุด
9. บีบอัดข้อมูลด้วย Gzip
เว้นแต่ว่าการใช้งาน CPU ของคุณสูงเกินไป คุณจำเป็นต้องใช้เทคนิคเพื่อปรับปรุงประสิทธิภาพของเซิร์ฟเวอร์ การใช้ gzip เพื่อบีบอัดข้อมูลสามารถลดปริมาณข้อมูลที่คุณส่งไปยังเซิร์ฟเวอร์ ปรับปรุงความเร็วการทำงานของเพจ และยังลดการรับส่งข้อมูลเครือข่ายอีกด้วย วิธีบีบอัดข้อมูลให้ดีขึ้นนั้นขึ้นอยู่กับข้อมูลที่คุณต้องการส่ง และเบราว์เซอร์ของไคลเอนต์รองรับหรือไม่ (IIS ส่งข้อมูลที่บีบอัด gzip ไปยังไคลเอนต์ และไคลเอนต์ต้องรองรับ gzip เพื่อแยกวิเคราะห์ IE6.0 และ Firefox) ด้วยวิธีนี้ เซิร์ฟเวอร์ของคุณจะสามารถตอบสนองต่อคำขอได้มากขึ้นต่อวินาที ในทำนองเดียวกัน คุณยังลดปริมาณข้อมูลที่ส่งไปในการตอบกลับ และคุณสามารถส่งคำขอเพิ่มเติมได้
ข่าวดี การบีบอัด gzip ได้รับการรวมเข้ากับ IIS6.0 แล้ว ซึ่งดีกว่า gzip ใน IIS5.0 ขออภัย หากต้องการเปิดใช้งานการบีบอัด gzip ใน IIS 6.0 คุณไม่สามารถตั้งค่าได้ในกล่องโต้ตอบคุณสมบัติของ IIS 6.0 ทีมพัฒนา IIS พัฒนาฟังก์ชันการบีบอัด gzip แต่พวกเขาลืมทำให้ผู้ดูแลระบบเปิดใช้งานได้ง่ายในหน้าต่างผู้ดูแลระบบ หากต้องการเปิดใช้งานการบีบอัด gzip คุณสามารถแก้ไขการกำหนดค่าได้ในไฟล์การกำหนดค่า IIS6.0 xml เท่านั้น
นอกจากการอ่านบทความนี้แล้ว ฉันต้องอ่านบทความ <<IIS6 Compression>> ที่เขียนโดย Brad Wilson ( http://www.dotnetdevs.com/articles/IIS6compression.aspx ) นอกจากนี้ยังมีบทความแนะนำความรู้พื้นฐานอีกด้วย ของการบีบอัด aspx เปิดใช้งานการบีบอัด ASPX ใน IIS แต่โปรดทราบว่าการบีบอัดแบบไดนามิกและการแคชเคอร์เนลนั้นไม่เกิดร่วมกันใน IIS6
10. ViewState ของการควบคุมเซิร์ฟเวอร์
ViewState เป็นคุณสมบัติใน asp.net ที่ใช้ในการบันทึกค่าสถานะที่ใช้ในการสร้างเพจในฟิลด์ที่ซ่อนอยู่ เมื่อเพจถูกโพสต์กลับไปยังเซิร์ฟเวอร์ เซิร์ฟเวอร์จะแยกวิเคราะห์ ตรวจสอบ และใช้ข้อมูลใน ViewState เพื่อเรียกคืนแผนผังการควบคุมของเพจ ViewState เป็นคุณสมบัติที่มีประโยชน์มากที่สามารถคงสถานะไคลเอนต์ได้โดยไม่ต้องใช้คุกกี้หรือหน่วยความจำเซิร์ฟเวอร์ การควบคุมเซิร์ฟเวอร์ส่วนใหญ่ใช้ ViewState เพื่อคงค่าสถานะขององค์ประกอบที่โต้ตอบกับผู้ใช้บนเพจ ตัวอย่างเช่น หากต้องการบันทึกหมายเลขหน้าของหน้าปัจจุบันสำหรับเพจ
การใช้ ViewState จะทำให้เกิดผลเสียบางประการ ขั้นแรก เพิ่มเวลาตอบสนองและคำขอของเซิร์ฟเวอร์ ประการที่สอง แต่ละ postback จะเพิ่มเวลาในการซีเรียลไลซ์และดีซีเรียลไลซ์ข้อมูล สุดท้ายก็ยังใช้หน่วยความจำบนเซิร์ฟเวอร์มากขึ้นด้วย
การควบคุมเซิร์ฟเวอร์จำนวนมากมักจะใช้ ViewState เช่น DataGrid ที่รู้จักกันดี และบางครั้งก็ไม่จำเป็นต้องใช้ ViewState ถูกเปิดใช้งานตามค่าเริ่มต้น หากคุณไม่ต้องการใช้ ViewState คุณสามารถปิดได้ที่ระดับการควบคุมหรือเพจ ในการควบคุม คุณจะต้องตั้งค่าคุณสมบัติ EnableViewState เป็น False คุณยังสามารถตั้งค่าในเพจเพื่อขยายขอบเขตไปยังทั้งเพจได้:
<%@ หน้า EnableViewState=”false” %>
หากเพจไม่ต้องการ postback หรือเพจนั้นแสดงผลพร้อมการควบคุมในแต่ละครั้งที่มีการร้องขอ คุณควรปิด ViewState ในระดับเพจ
สรุป
ฉันเพียงให้คำแนะนำเล็กๆ น้อยๆ ที่ฉันคิดว่าจะช่วยปรับปรุงการเขียนแอปพลิเคชัน ASP.NET ที่มีประสิทธิภาพสูง เคล็ดลับในการปรับปรุงประสิทธิภาพ ASP.NET ที่กล่าวถึงในบทความนี้เป็นเพียงจุดเริ่มต้น สำหรับข้อมูลเพิ่มเติม โปรดดูที่ "การปรับปรุง ASP" หนังสือ "ประสิทธิภาพ" NET คุณจะพบเทคนิคที่เป็นประโยชน์มากที่สุดสำหรับโครงการของคุณผ่านการฝึกฝนของคุณเองเท่านั้น อย่างไรก็ตาม เคล็ดลับเหล่านี้สามารถใช้เป็นแนวทางในการพัฒนาของคุณได้ ในการพัฒนาซอฟต์แวร์ สิ่งเหล่านี้ไม่มีประโยชน์เลย เพราะแต่ละโครงการมีความแตกต่างกัน
