จัดการกับความสามารถในการปรับขนาด ประสิทธิภาพในแอปพลิเคชันเว็บ .net

มีวิธีอื่นไหม ใช่ - อย่ากระจายวัตถุของคุณ แนวทางที่ปรับขนาดได้มากที่สุดคืออย่ากระจายอ็อบเจ็กต์ของคุณออกจากกัน ถามตัวเองว่าทำไมคุณถึงต้องการปรับใช้โค้ดรสชาติหนึ่งกับ "เซิร์ฟเวอร์แอป" ในขณะที่โค้ดอีกรสชาติหนึ่งไปที่ "เว็บเซิร์ฟเวอร์" การสื่อสารที่เกิดขึ้นระหว่างสองชั้นนั้น หากมีการกระจายออกไป จะมีราคาแพงกว่าการโทรในท้องถิ่นมาก (ฯลฯ)

ด้วยเซิร์ฟเวอร์ 64 บิตในปัจจุบัน พร้อมด้วยหน่วยความจำทั้งหมด และ CPU ที่ร้อนแรง และด้วยการจัดการหน่วยความจำที่เหนือกว่าของ ASP.NET ทำไมไม่ลองนำตรรกะทางธุรกิจและ DAL ของคุณไปไว้ในเครื่องทางกายภาพเดียวกันกับไฟล์ ASPX ดูล่ะ ทำไมจะไม่ล่ะ?

หากคุณต้องการขยายขนาด ให้เพิ่มเซิร์ฟเวอร์เพิ่มเติม เรียบง่าย.

แน่นอนว่ามีเหตุผลที่ดีที่จะเผยแพร่ เหตุผลที่ดีที่พบบ่อยที่สุดเกี่ยวข้องกับโดเมนการเป็นเจ้าของ ในหลายแกน: การจัดการความปลอดภัย หรือแม้แต่งบประมาณและการควบคุม กล่าวอีกนัยหนึ่ง ในกรณีหลัง หากทีมมีหน้าที่รับผิดชอบในการรันตรรกะทางธุรกิจ และทีมที่แยกจากกันมีหน้าที่รับผิดชอบในการสร้างและรันเว็บเลเยอร์ ดังนั้นจึงอาจสมเหตุสมผลที่จะแจกจ่ายทั้งสองสิ่งนี้เพื่อให้ฝ่ายบริหารมีความเป็นอิสระ เหตุผลดีๆ ส่วนใหญ่ในการเผยแพร่รหัสคอมพิวเตอร์มีต้นกำเนิดมาจากโครงสร้างขององค์กรมนุษย์ที่ใช้หรือพัฒนารหัส

ไม่มีเหตุผลทางเทคนิคที่ดีว่าทำไมหน้าเว็บไม่ควรทำงานบน CPU เดียวกัน โดยแชร์ CLR VM และฮีปหน่วยความจำเดียวกันกับเลเยอร์การเข้าถึงฐานข้อมูล

ไม่ว่าคุณจะทำอะไรกับการกระจาย มันไม่ฉลาดเลยที่จะออกแบบระบบของคุณด้วยอินเทอร์เฟซที่ไม่เป็นทางการซึ่งกำหนดการเชื่อมต่อระหว่างเลเยอร์ หากคุณคงอินเทอร์เฟซที่เป็นทางการไว้ ก็ไม่น่าจะมีปัญหาสำหรับคุณในการวัดประสิทธิภาพและประสิทธิภาพของแนวทางแบบกระจายเทียบกับแนวทางแบบวางร่วม

คุณต้องการเซิร์ฟเวอร์แอปจริง ๆ หรือไม่? คุณกำลังพูดถึงเรื่องใหญ่แค่ไหน? ตัวอย่างเช่น Stackoverflow.com มี ~ 50,000 รายการที่ไม่ซ้ำกันต่อวันและไม่มีเซิร์ฟเวอร์แอป ดังนั้นฉันคิดว่าคุณกำลังพูดถึงเรื่องใหญ่กว่านั้นมากใช่ไหม ปัญหาคอขวดด้านประสิทธิภาพส่วนใหญ่มาจากปัญหาฐานข้อมูล ดังนั้นฉันจะเน้นไปที่เรื่องนั้น

ฉันขอแนะนำให้คุณดูแนวทางของกลุ่มรูปแบบและแนวทางปฏิบัติสำหรับประสิทธิภาพ โดยเฉพาะชื่อ บทที่ 6 - การปรับปรุงประสิทธิภาพของ ASP.NET ของแนวทาง ฉันเห็นด้วยกับ Cheeso ว่าคุณควรพิจารณาอย่างจริงจังว่าอย่าแยกเลเยอร์แอปพลิเคชันและเลเยอร์ UI ของคุณออกทางกายภาพหากทำได้ แนวทาง P&P มีหมายเหตุดังต่อไปนี้:

หลีกเลี่ยงการข้ามกระบวนการที่ไม่จำเป็น

แม้ว่ากระบวนการฮอปส์จะไม่แพงเท่ากับฮ็อปของเครื่องจักร แต่คุณควรหลีกเลี่ยงการฮอปกระบวนการหากเป็นไปได้ การกระโดดข้ามกระบวนการทำให้เกิดค่าใช้จ่ายเพิ่มเติมเนื่องจากต้องใช้การสื่อสารระหว่างกระบวนการ (IPC) และการจัดเรียง ตัวอย่างเช่น หากโซลูชันของคุณใช้บริการ Enterprise ให้ใช้แอปพลิเคชันไลบรารีหากเป็นไปได้ เว้นแต่คุณจะต้องวางแอปพลิเคชัน Enterprise Services ไว้ที่ระดับกลางระยะไกล

ทำความเข้าใจผลกระทบด้านประสิทธิภาพของระดับกลางระยะไกล

หากเป็นไปได้ ให้หลีกเลี่ยงค่าใช้จ่ายด้านการสื่อสารระหว่างกระบวนการและระหว่างคอมพิวเตอร์ เว้นแต่ข้อกำหนดทางธุรกิจของคุณจะกำหนดการใช้ระดับกลางระยะไกล ให้เก็บการนำเสนอ ธุรกิจ และตรรกะการเข้าถึงข้อมูลของคุณไว้บนเว็บเซิร์ฟเวอร์ ปรับใช้แอสเซมบลีการเข้าถึงธุรกิจและข้อมูลของคุณไปยังไดเร็กทอรี Bin ของแอปพลิเคชันของคุณ อย่างไรก็ตาม คุณอาจต้องใช้ระดับกลางระยะไกลด้วยเหตุผลใดๆ ต่อไปนี้:

• คุณต้องการแบ่งปันตรรกะทางธุรกิจของคุณระหว่างเว็บแอปพลิเคชันที่เชื่อมต่อกับอินเทอร์เน็ตและแอปพลิเคชันภายในองค์กรอื่นๆ
• ข้อกำหนดการขยายขนาดและความทนทานต่อข้อผิดพลาดของคุณจะกำหนดการใช้คลัสเตอร์ระดับกลางหรือเซิร์ฟเวอร์ที่มีการปรับสมดุลโหลด
• นโยบายความปลอดภัยขององค์กรของคุณกำหนดว่าคุณไม่สามารถใส่ตรรกะทางธุรกิจบนเว็บเซิร์ฟเวอร์ของคุณได้

หากคุณจำเป็นต้องแยกตรรกะของแอปพลิเคชันออกอย่างแน่นอน คุณสามารถใช้ WCF เป็นกลไกการขนส่งได้ ฉันไม่แน่ใจว่ามันเทียบได้กับการทำงานระยะไกลอย่างไรในเรื่องประสิทธิภาพ อย่างไรก็ตาม ดูเหมือนว่าฉันจะจำได้ว่านี่คือแนวทางที่ Microsoft กำลังผลักดัน

Clemens Vasters (หัวหน้าฝ่ายเทคนิคสำหรับ Microsoft .NET Service Bus) พูดถึง WCF และระยะไกลใน คำตอบนี้ในฟอรัม MSDN

เรียนรู้การเขียนแบบอะซิงโครนัส
สำรวจรันไทม์ CCR เป็นตัวอย่าง

แต่ละเธรดที่ถูกบล็อกเพื่อรอการตอบสนองของ IO จะมี หนึ่งเธรดน้อยลงสำหรับระบบของคุณ

ปิด 'การบันทึกในอุดมคติ' ปล่อยให้สามารถเปิดใหม่อีกครั้งผ่านคอนโซลผู้ดูแลระบบ แต่การตัดไม้มักเป็นคอขวดที่ซ่อนอยู่

แคช แคช แคช!

หากการรับข้อมูลครั้งแรกมีราคาแพง อย่าจ่ายเงินในครั้งที่สอง!

หลีกเลี่ยงสถานะเซสชันของ ASP.net - สิ่งนี้อาจขยายตัวอย่างมากและทำให้การตอบสนองของเพจช้าลงอย่างมาก

แก้ไขส่วนหัว http เพื่อระบุแคชเบราว์เซอร์แบบสั้น (5 วินาที - 20 วินาที) (ขึ้นอยู่กับลักษณะของเนื้อหา)

ใช้ GZIP ในขณะที่คุณอยู่ที่นั่น!

และใช้ RAM จำนวนมาก

นี่คือเคล็ดลับของฉัน

1) ย้ายไฟล์คงที่ทั้งหมดของคุณ - รูปภาพ , css, js ไปยังโหลดบาลานเซอร์เช่น nginx วิธีนี้จะช่วยลดภาระบนเซิร์ฟเวอร์ IIS ได้อย่างมาก และจะมีทรัพยากรว่างเพียงพอที่จะตอบสนองคำขอหลัก

2)คิดถึงการแคชและหลีกเลี่ยงการเข้าถึงฐานข้อมูลโดยสิ้นเชิง

3)พยายามนำหลักการ REST ไปใช้ให้ไกลที่สุด

4) รักษาสถานะเซสชันให้เหลือน้อยที่สุด - หากเป็นไปได้ให้หลีกเลี่ยงโดยสิ้นเชิง

บทความเหล่านี้มีประสิทธิภาพที่ดีและสามารถปรับขยายได้จาก Omar Al Zabir.
10 ASP.NET Performance and Scalability Secrets
และ
พร้อมใช้งาน 99.99% ASP.NET และ SQL Server SaaS Production Architecture
(โปรดดูหนังสือของเขา การสร้างพอร์ทัล Web 2.0 ด้วย ASP.NET 3.5)