Entity Framework ช้าเกินไป ตัวเลือกของฉันคืออะไร? [ปิด]

ฉันได้ทำตามมนต์ "Don't Optimize Prematurely" และเขียนโค้ดบริการ WCF ของฉันโดยใช้ Entity Framework

อย่างไรก็ตามฉันทำโปรไฟล์ประสิทธิภาพและ Entity Framework ช้าเกินไป (แอปของฉันประมวลผล 2 ข้อความในเวลาประมาณ 1.2 วินาทีโดยที่แอป (เดิม) ที่ฉันเขียนใหม่ทำ 5-6 ข้อความในเวลาเดียวกัน (แอปเดิมเรียก sprocs สำหรับการเข้าถึงฐานข้อมูล)

การทำโปรไฟล์ของฉันชี้ไปที่ Entity Framework โดยใช้เวลาส่วนใหญ่ต่อข้อความ

ตัวเลือกของฉันคืออะไร?

• มี ORM ที่ดีกว่านี้ไหม
  (สิ่งที่รองรับการอ่านและเขียนวัตถุตามปกติและทำได้เร็ว .. )

• มีวิธีทำให้ Entity Framework เร็วขึ้นหรือไม่?
  ( หมายเหตุ : เมื่อฉันพูดเร็วกว่าฉันหมายถึงในระยะยาวไม่ใช่การโทรครั้งแรก (การโทรครั้งแรกช้า (15 วินาทีสำหรับข้อความ) แต่นั่นไม่ใช่ปัญหาฉันแค่ต้องการให้มันเร็วเพื่อที่เหลือ ของข้อความ)

• ตัวเลือกที่ 3 ลึกลับที่จะช่วยให้ฉันใช้บริการได้เร็วขึ้น

หมายเหตุ:การโต้ตอบ DB ส่วนใหญ่ของฉันคือการสร้างและอัปเดต ฉันเลือกและลบน้อยมาก

คุณควรเริ่มต้นด้วยการสร้างโปรไฟล์คำสั่ง SQL ที่ออกโดย Entity Framework ขึ้นอยู่กับการกำหนดค่าของคุณ (POCO, เอนทิตีการติดตามตนเอง) มีพื้นที่มากมายสำหรับการปรับให้เหมาะสม คุณสามารถดีบักคำสั่ง SQL (ซึ่งไม่ควรแตกต่างกันระหว่างโหมดดีบักและโหมดรีลีส) โดยใช้ObjectSet<T>.ToTraceString()เมธอด หากคุณพบข้อความค้นหาที่ต้องการการเพิ่มประสิทธิภาพเพิ่มเติมคุณสามารถใช้การคาดการณ์บางอย่างเพื่อให้ข้อมูลเพิ่มเติมกับ EF เกี่ยวกับสิ่งที่คุณพยายามทำให้สำเร็จ

ตัวอย่าง:

Product product = db.Products.SingleOrDefault(p => p.Id == 10);
// executes SELECT * FROM Products WHERE Id = 10

ProductDto dto = new ProductDto();
foreach (Category category in product.Categories)
// executes SELECT * FROM Categories WHERE ProductId = 10
{
    dto.Categories.Add(new CategoryDto { Name = category.Name });
}

สามารถแทนที่ด้วย:

var query = from p in db.Products
            where p.Id == 10
            select new
            {
                p.Name,
                Categories = from c in p.Categories select c.Name
            };
ProductDto dto = new ProductDto();
foreach (var categoryName in query.Single().Categories)
// Executes SELECT p.Id, c.Name FROM Products as p, Categories as c WHERE p.Id = 10 AND p.Id = c.ProductId
{
    dto.Categories.Add(new CategoryDto { Name = categoryName });
}

ฉันแค่พิมพ์ออกมาจากหัวดังนั้นนี่ไม่ใช่วิธีดำเนินการอย่างแน่นอน แต่ EF จะทำการเพิ่มประสิทธิภาพที่ดีหากคุณบอกทุกอย่างที่คุณรู้เกี่ยวกับข้อความค้นหา (ในกรณีนี้เราจะต้องใช้หมวดหมู่ - ชื่อ) แต่นี่ไม่เหมือนกับการโหลดอย่างกระตือรือร้น (db.Products.Include ("Categories")) เนื่องจากการคาดการณ์สามารถลดปริมาณข้อมูลที่จะโหลดได้

ความจริงของเรื่องนี้ก็คือผลิตภัณฑ์เช่น Entity Framework มักจะทำงานช้าและไม่มีประสิทธิภาพเนื่องจากมีการเรียกใช้โค้ดมากขึ้น

ฉันยังพบว่ามันโง่ที่มีคนแนะนำว่าควรเพิ่มประสิทธิภาพการสืบค้น LINQ ดู SQL ที่สร้างขึ้นใช้ debuggers รวบรวมล่วงหน้าทำตามขั้นตอนเพิ่มเติมมากมาย ฯลฯ เช่นเสียเวลามาก ไม่มีใครว่า - ลดความซับซ้อน! ทุกคนต้องการที่จะรวบรวมสิ่งต่าง ๆ เพิ่มเติมโดยทำตามขั้นตอนให้มากขึ้น (เสียเวลา)

แนวทางสามัญสำนึกจะไม่ใช้ EF หรือ LINQ เลย ใช้ SQL ธรรมดา มันไม่มีอะไรผิดปกติ เพียงเพราะมีความคิดในหมู่โปรแกรมเมอร์และพวกเขารู้สึกอยากใช้ผลิตภัณฑ์ใหม่ทุกชิ้นที่มีอยู่ไม่ได้หมายความว่าจะดีหรือจะได้ผล โปรแกรมเมอร์ส่วนใหญ่คิดว่าถ้าพวกเขารวมโค้ดใหม่ทุกชิ้นที่ออกโดย บริษัท ขนาดใหญ่มันจะทำให้พวกเขาเป็นโปรแกรมเมอร์ที่ฉลาดขึ้น ไม่เป็นความจริงเลย การเขียนโปรแกรมแบบสมาร์ทส่วนใหญ่เกี่ยวกับการทำสิ่งต่างๆให้มากขึ้นโดยให้ปวดหัวน้อยลงไม่แน่นอนและใช้เวลาน้อยที่สุด จำไว้ - เวลา! นั่นคือองค์ประกอบที่สำคัญที่สุดดังนั้นพยายามหาวิธีที่จะไม่เสียมันไปกับการแก้ปัญหาในโค้ดที่ไม่ดี / ป่องที่เขียนขึ้นเพื่อให้สอดคล้องกับ 'รูปแบบ' ที่แปลก ๆ

ผ่อนคลายสนุกกับชีวิตหยุดพักจากการเขียนโค้ดและหยุดใช้คุณสมบัติพิเศษรหัสผลิตภัณฑ์ "รูปแบบ" ชีวิตนั้นสั้นและอายุการใช้งานของโค้ดของคุณก็สั้นลงและไม่ใช่วิทยาศาสตร์จรวดอย่างแน่นอน ลบเลเยอร์เช่น LINQ, EF และอื่น ๆ และโค้ดของคุณจะทำงานได้อย่างมีประสิทธิภาพจะปรับขนาดและใช่มันจะยังคงดูแลรักษาได้ง่าย สิ่งที่เป็นนามธรรมมากเกินไปเป็น 'แบบแผน' ที่ไม่ดี

และนั่นคือวิธีแก้ปัญหาของคุณ

คำแนะนำอย่างหนึ่งคือการใช้ LINQ กับ Entity Framework สำหรับคำสั่ง CRUD แบบบันทึกเดียวเท่านั้น

สำหรับการค้นหาที่เกี่ยวข้องมากขึ้นการค้นหารายงาน ฯลฯ เขียนขั้นตอนการจัดเก็บและเพิ่มเข้าไปในรูปแบบนิติบุคคล Framework ตามที่อธิบายไว้ใน MSDN

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

หากคุณกำลังดึงข้อมูลเพียงอย่างเดียวจะช่วยได้มากเมื่อคุณบอกให้ EF อย่าติดตามเอนทิตีที่ดึงข้อมูลมา ทำได้โดยใช้ MergeOption.NoTracking EF จะสร้างแบบสอบถามดำเนินการและยกเลิกการกำหนดค่าเริ่มต้นของผลลัพธ์ไปยังออบเจ็กต์ แต่จะไม่พยายามติดตามการเปลี่ยนแปลงเอนทิตีหรือสิ่งใด ๆ ในลักษณะนั้น หากแบบสอบถามนั้นเรียบง่าย (ใช้เวลาไม่นานในการรอฐานข้อมูลเพื่อส่งคืน) ฉันพบว่าการตั้งค่าเป็น NoTracking สามารถเพิ่มประสิทธิภาพการสืบค้นได้สองเท่า

ดูบทความ MSDN เกี่ยวกับ MergeOption enum:

การแก้ไขข้อมูลประจำตัวการจัดการสถานะและการติดตามการเปลี่ยนแปลง

ดูเหมือนจะเป็นบทความที่ดีเกี่ยวกับประสิทธิภาพของ EF:

ประสิทธิภาพและกรอบเอนทิตี

คุณบอกว่าคุณมีโปรไฟล์การสมัคร คุณมีประวัติออมด้วยหรือไม่? มีผู้สร้างโปรไฟล์ EF จาก Ayende ซึ่งจะเน้นจุดที่คุณสามารถเพิ่มประสิทธิภาพโค้ด EF ของคุณได้ คุณสามารถค้นหาได้ที่นี่:

http://efprof.com/

โปรดจำไว้ว่าคุณสามารถใช้แนวทาง SQL แบบเดิมควบคู่ไปกับ ORM ของคุณได้หากคุณต้องการเพิ่มประสิทธิภาพ

หากมี ORM ที่เร็วขึ้น / ดีขึ้น? ทั้งนี้ขึ้นอยู่กับรูปแบบวัตถุ / ข้อมูลของคุณคุณอาจจะพิจารณาใช้หนึ่งในไมโคร ORMs เช่นDapper , MassiveหรือPetaPoco

เว็บไซต์ Dapper เผยแพร่เกณฑ์มาตรฐานเชิงเปรียบเทียบที่จะทำให้คุณทราบว่าพวกเขาเปรียบเทียบกับ ORM อื่น ๆ อย่างไร แต่เป็นที่น่าสังเกตว่า micro-ORM ไม่รองรับชุดคุณลักษณะที่สมบูรณ์ของ ORM แบบเต็มเช่น EF และ NH

คุณอาจต้องการที่จะดูที่RavenDB นี้เป็นฐานข้อมูลที่ไม่สัมพันธ์ (จาก Ayende อีกครั้ง) ที่ช่วยให้คุณเก็บ POCOs โดยตรงกับไม่มีการทำแผนที่ที่จำเป็น RavenDB ได้รับการปรับให้เหมาะสมสำหรับการอ่านและทำให้ชีวิตของนักพัฒนาง่ายขึ้นมากโดยการลบความจำเป็นในการจัดการสคีมาและการแมปวัตถุของคุณกับสคีมานั้น อย่างไรก็ตามทราบว่านี้เป็นวิธีการที่แตกต่างกันอย่างมีนัยสำคัญกับการใช้วิธีการออมและเหล่านี้จะระบุไว้ในเว็บไซต์ของผลิตภัณฑ์

ฉันพบคำตอบโดย @Slauma ที่นี่มีประโยชน์มากสำหรับการเร่งความเร็ว ฉันใช้รูปแบบเดียวกันสำหรับทั้งส่วนแทรกและการอัปเดต - และประสิทธิภาพที่พุ่งสูงขึ้น

จากประสบการณ์ของฉันปัญหาไม่ได้อยู่ที่ EF แต่เป็นวิธีการของ ORM เอง

โดยทั่วไปแล้ว ORM ทั้งหมดจะประสบปัญหาN + 1 ที่ไม่ได้รับการปรับแต่งการสืบค้นและอื่น ๆ การคาดเดาที่ดีที่สุดของฉันคือการติดตามการสืบค้นที่ทำให้ประสิทธิภาพการทำงานลดลงและพยายามปรับแต่งเครื่องมือ ORM หรือเขียนส่วนนั้นใหม่ด้วย SPROC

นี่เป็นอ็อพชันที่ไม่ใช่เฟรมเวิร์กแบบธรรมดาที่โหลดที่ 10,000 / วินาทีโดยมี 30 ฟิลด์หรือมากกว่านั้น ทำงานบนแล็ปท็อปเครื่องเก่าซึ่งอาจเร็วกว่านั้นในสภาพแวดล้อมจริง

https://sourceforge.net/projects/dopersistence/?source=directory

ฉันพบปัญหานี้เช่นกัน ฉันเกลียดการทิ้ง EF เพราะมันทำงานได้ดี แต่มันก็ช้า ในกรณีส่วนใหญ่ฉันแค่ต้องการค้นหาบันทึกหรืออัปเดต / แทรก แม้แต่การดำเนินการง่ายๆเช่นนี้ก็ช้า ฉันดึงข้อมูล 1100 รายการจากตารางกลับมาเป็นรายการและการดำเนินการนั้นใช้เวลา 6 วินาทีด้วย EF สำหรับฉันสิ่งนี้นานเกินไปแม้แต่การประหยัดก็ใช้เวลานานเกินไป

ฉันลงเอยด้วยการสร้าง ORM ของตัวเอง ฉันดึงข้อมูล 1100 รายการเดียวกันจากฐานข้อมูลและ ORM ของฉันใช้เวลา 2 วินาทีเร็วกว่า EF มาก ทุกอย่างที่มี ORM ของฉันเกือบจะในทันที ข้อ จำกัด เพียงอย่างเดียวในตอนนี้คือใช้งานได้กับ MS SQL Server เท่านั้น แต่สามารถเปลี่ยนให้ทำงานร่วมกับผู้อื่นเช่น Oracle ได้ ฉันใช้ MS SQL Server สำหรับทุกอย่างในตอนนี้

หากคุณต้องการลอง ORM ของฉันที่นี่คือลิงค์และเว็บไซต์:

https://github.com/jdemeuse1204/OR-M-Data-Entities

หรือหากคุณต้องการใช้นักเก็ต:

PM> ติดตั้งแพ็คเกจหรือ -M_DataEntities

เอกสารอยู่ที่นั่นเช่นกัน

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

เรามีแอปพลิเคชันที่คล้ายกัน (Wcf -> EF -> ฐานข้อมูล) ที่ทำ 120 คำขอต่อวินาทีได้อย่างง่ายดายดังนั้นฉันมั่นใจว่า EF ไม่ใช่ปัญหาของคุณที่นี่ตามที่กล่าวไว้ฉันได้เห็นการปรับปรุงประสิทธิภาพครั้งใหญ่ด้วยการสืบค้นที่รวบรวม

ฉันใช้ EF, LINQ เป็น SQL และ dapper Dapper เร็วที่สุด ตัวอย่าง: ฉันต้องการ 1,000 ระเบียนหลักโดยแต่ละระเบียนย่อย 4 รายการ ฉันใช้ LINQ เป็น sql ใช้เวลาประมาณ 6 วินาที จากนั้นฉันเปลี่ยนไปใช้ dapper เรียกข้อมูลชุดบันทึก 2 ชุดจากขั้นตอนที่เก็บไว้เดียวและสำหรับแต่ละระเบียนเพิ่มระเบียนย่อย เวลารวม 1 วินาที

นอกจากนี้กระบวนงานที่เก็บไว้ยังใช้ฟังก์ชันค่าตารางที่มีการใช้ข้ามฉันพบว่าฟังก์ชันค่าสเกลาร์ช้ามาก

คำแนะนำของฉันคือใช้ EF หรือ LINQ กับ SQL และสำหรับบางสถานการณ์ให้เปลี่ยนเป็น dapper

Entity Framework ไม่ควรทำให้เกิดปัญหาคอขวดที่สำคัญ โอกาสที่จะมีสาเหตุอื่น ๆ คุณสามารถลองเปลี่ยน EF เป็น Linq2SQL ทั้งสองมีคุณสมบัติเปรียบเทียบและโค้ดควรแปลงได้ง่าย แต่ในหลาย ๆ กรณี Linq2SQL เร็วกว่า EF