इकाई फ्रेमवर्क - पहली क्वेरी धीमी

Question

शीर्षक के अनुसार मुझे एंटिटी फ्रेमवर्क का उपयोग कर SQL सर्वर डेटाबेस के विरुद्ध पहली क्वेरी में कोई समस्या है।

मैंने विभिन्न साइटों पर एक उत्तर खोजने की कोशिश की है लेकिन वास्तव में इसका कोई समाधान नहीं है।

मैं डेटाबेस से बहुत सारी पंक्तियां लोड कर रहा हूं जिसमें दो 0-कई रिश्ते शामिल हैं।

परीक्षण स्टूडियो 2010 में एंटीटी फ्रेमवर्क 4.0 मॉडल और पीओसीओ जनरेटर का उपयोग करके परीक्षण किया गया था (सामान्य संस्थाओं और पीओसीओ वस्तुओं के बीच समय में बहुत अंतर नहीं है)। मैंने विचारों को पूर्व-संकलित करने के लिए टी 4 व्यू टेम्पलेट का भी उपयोग किया।

डेटाबेस SQL ​​सर्वर 2008

पर था क्या मैं सच में जानना चाहते हैं क्यों पहली क्वेरी सू ज्यादा किसी भी माध्यमिक प्रश्नों की तुलना में धीमी है।

मैं यह भी जानना चाहता हूं कि पहली क्वेरी की गति को उस बिंदु पर बढ़ाने के लिए कुछ किया जा सकता है जहां यह स्वीकार्य सीमाओं के भीतर है।

यह एक बड़ा प्रश्न है और हम अन्य प्रश्नों कि भी बड़ा कर रहे हैं मिल सकता है और यह समझा जा सकता है कि वे थोड़ा धीमा हो सकता है लेकिन 30 सेकंड रास्ता बहुत धीमी गति से उपयोगकर्ता जब डेटासेट एक ही डेटा प्राप्त कर सकते हैं विशेष रूप से के लिए प्रतीक्षा करने के लिए है बहुत तेज़

मैंने कुछ समय परीक्षण किया है और यह पता लगाने के लिए कि समस्या कहां है और मैं यह देखकर थोड़ा आश्चर्यचकित हुआ कि ऐसा लगता है कि यह SQL सर्वर है जो पहली क्वेरी पर धीमा है।

नेट परीक्षण आवेदन:

• प्रथम प्रश्न: 29,6 सेकंड
• दूसरा प्रश्न: 3,2 सेकंड

एसक्यूएल प्रोफाइलर

समय इस प्रकार था:

• पहला प्रश्न ery: 27 सेकंड
• दूसरा प्रश्न: 3,2 सेकंड

एसक्यूएल सर्वर क्वेरी विंडो

• प्रथम प्रश्न: 8 सेकंड
• दूसरा प्रश्न: 4 सेकंड

समय आवेदन में Stopwatch कक्षा के साथ मापा गया था। क्वेरी को निष्पादित करने के लिए केवल क्वेरी को मापा गया था और .ToList() का उपयोग किया गया था।

SQL सर्वर प्रोफाइलर में समय एक ही प्रश्न के लिए है जो एप्लिकेशन में निष्पादित किया गया था जो दिखाता है कि एप्लिकेशन केवल वस्तुओं में डेटा भरने के लिए लगभग 2,6 सेकंड का उपयोग करता है।

अंतिम 27 सेकंड SQL सर्वर पर क्वेरी निष्पादित करने के लिए उपयोग किया जाता है।

द्वितीयक क्वेरी को देखते हुए समय दोनों एप्लिकेशन और SQL सर्वर के लिए समान होते हैं लेकिन क्वेरी को निष्पादित करना इस समय बहुत तेज है।

मैं समझ सकता हूं कि एप्लिकेशन किसी भी समय क्यों उपयोग नहीं करता है क्योंकि ऐसी कोई नई पंक्तियां नहीं हैं जिन्हें ऑब्जेक्ट्स में परिवर्तित करने की आवश्यकता है, लेकिन क्वेरी इतनी तेज क्यों है, मुझे निष्पादन योजनाओं के कारण कुछ सेकंड की उम्मीद होगी लेकिन 24 सेकंड नहीं

बस उद्देश्य के उद्देश्य के लिए मैंने एसक्यूएल की प्रतिलिपि बनाई है कि इकाई फ्रेमवर्क एक अलग कनेक्शन विंडो के साथ एक नई क्वेरी विंडो उत्पन्न करता है और खोलता है और इसमें क्वेरी निष्पादित करता है।

जैसा कि आप देख सकते हैं कि पहली क्वेरी के लिए 8 सेकंड और दूसरे के लिए 4 सेकंड लगते हैं।

मुझे उम्मीद है कि किसी के पास कुछ सुझाव होंगे।

ps। मैं पाठ :)

संपादित 19-10-2010 की दीवार के लिए माफी माँगता:
मैं कल का समर्थन करने के कि पंक्तियों एक अनुक्रमिक तरीके से लौटाए जा रहे लगता है कि एक परीक्षण किया था। मतलब यह है कि जब डेटाबेस से एक पंक्ति वापस आती है तो इसे तुरंत भौतिक बनाया जाता है (यदि यह संदर्भ में पहले से मौजूद नहीं है) तो अगली पंक्ति लौटा दी जाती है और इसी तरह।

यही कारण है कि ऐसा लगता है कि क्वेरी डेटाबेस सर्वर पर बहुत समय ले रही है क्योंकि भौतिकरण समय SQL सर्वर प्रोफाइलर समय में शामिल है।

मुझे यह विश्वास नहीं है कि यह हार्डडिस्क से SQL सर्वर पढ़ने का मामला है। EF में "पहली क्वेरी" होने पर हर बार धीमी क्वेरी होती है।

पूर्व।

1. भागो एफई के साथ पहली बार क्वेरी, एसक्यूएल बयान धीमी किसी भी माध्यमिक क्वेरी
2. निपटान संदर्भ/भंडार
3. एक नया संदर्भ
4. भागो पहले की तरह ही क्वेरी (बनाएं उसके बाद फिर से पहला है क्वेरी धीमी है और एसक्यूएल कथन भी है)

यह लगभग ईएफ की तरह पहली क्वेरी के साथ कुछ विकल्प भेजता है जो सर्वर को धीमा कर देता है।

क्वेरी संकलन के लिए, जैसा कि मुझे याद है कि क्वेरी पहली बार संकलित की जाती है जिसका उपयोग किया जाता है जिसका अर्थ है कि पहली क्वेरी को निष्पादित करने में और अधिक समय लगेगा।

माध्यमिक प्रश्न तेजी से होंगे लेकिन माध्यमिक प्रश्नों की गति समस्या नहीं है।

मैंने एक परीक्षण भी किया जहां मैंने एक संकलित क्वेरी को स्थैतिक के रूप में बनाया ताकि इसे बनाए गए सभी संदर्भों के लिए संकलित किया जा सके।

मैंने फिर एक संदर्भ बनाया, क्वेरी चलाई, संदर्भ को नष्ट कर दिया और एक नया बनाया और एक बार फिर एक ही प्रश्न चलाया।

अंतर इतना बड़ा नहीं था, केवल कुछ सेकंड और पहली बार मैंने क्वेरी चलाई, इसे तब तक ले लिया जब तक इसे पूर्व-संकलित किए बिना।

दृश्य उत्पादन के लिए, हम पहले ही टी 4 टेम्पलेट का उपयोग करके इसे लागू कर चुके हैं।

जवाब वास्तव में है कि एफई ही काम करता है आप कुछ भी लेकिन सबसे सरल प्रश्नों कि डेटा का केवल एक अपेक्षाकृत छोटी मात्रा वापसी नहीं करते, तो है?

Answer 1

अच्छी तरह से, बहुत सारे चीजों की एक SQL सर्वर क्वेरी पहली बार धीमी गति से चल सकती है। उनमें से ज्यादातर को कई सेकंड नहीं लेते हैं, हालांकि।

... हार्ड ड्राइव यादृच्छिक अभिगम के अलावा। पहली बार जब आप क्वेरी चलाते हैं, तो SQL सर्वर को हार्ड डिस्क संग्रहण से डेटाबेस पेजों को पढ़ना पड़ सकता है। अगली बार जब आप क्वेरी चलाते हैं तो उन पृष्ठों की स्मृति में संभावना है।

इकाई की रूपरेखा, पहली बार जब आप एक प्रश्न यह SQL में संकलित किया जाना चाहिए चलाने के बारे में। अंत उपयोगकर्ता को इसके लिए प्रतीक्षा करने से पहले, आप समय से पहले इस काम को करने के लिए एंटीटी फ्रेमवर्क क्वेरीज को पूर्व-संकलित करने के लिए CompiledQuery प्रकार का उपयोग कर सकते हैं।

एक बहुत बड़े मॉडल पर, पीढ़ी को कुछ समय भी देखें। इसके बजाय आप समय संकलित करने के लिए इसे स्थानांतरित कर सकते हैं। ऐसी युक्तियों के लिए this article देखें।

Answer 2

हम एफई 5.0 में एक ही मुद्दा था और आज के रूप में एक सतही गूगल खोज एक पर्याप्त गति-अप प्रकट नहीं करता।

इस लिंक के अनुसार http://msdn.microsoft.com/en-us/library/cc853327(v=vs.100).aspx "लोडिंग मेटाडाटा" में मामूली समय लागत होती है लेकिन प्रति ऐपडोमेन में केवल एक बार होने की आवश्यकता होती है। मुझे मेटा-डेटा लोड करने के लिए चाल जैसे प्री-संकलन नहीं मिला है।

वैकल्पिक हल हम क्रियान्वित किया है एक अलग थ्रेड जब आवेदन की शुरूआत में प्रसंग पर एक छोटी सी क्वेरी करना है। यह मेटा-डेटा लोड करता है, इसमें अभी भी काफी समय लगता है (हमारे मामले में 18-19 सेकेंड), लेकिन ऐप लोड के दौरान उत्तरदायी है। इसके अलावा पहले वास्तविक भार में अधिक समय नहीं लगता है।

कृपया ध्यान दें कि हमारे संदर्भ में यह संभव है उपयोगकर्ता आवेदन में 18-19 सेकंड खर्च करने के लिए एक एफई कॉल उनके कार्यों के जवाब में किए जाने के लिए की आवश्यकता होगी से पहले। जाहिर है कि यदि आपके आवेदन में यह संभव नहीं है तो यह काम लगभग गति वृद्धि प्रदान नहीं कर सकता है।

Answer 3

हमारे पास एक ही समस्या है। यह केवल कोड के पहले दृष्टिकोण के साथ है। हमारे पास लगभग 1500 पीओसीओ (+1500 पीओसीओ मैपिंग फाइलें हैं)। बस संकलन में लगभग 1-2 मिनट लगते हैं। Context.table.Add() विधि में लगभग 3-4 मिनट लगते हैं लेकिन पहली वस्तु के लिए। यह किसी भी समाधान के साथ एक बुरा मजाक की तरह है। वे 3-4 मिनट शायद किसी प्रकार का ईएफ "पोको परिवर्तन" है। एक सीपीयू कोर 100% चलाता है और एसक्यूएल प्रोफाइलर में कुछ भी नहीं चल रहा है।

ही 1500 तालिकाओं के लिए डाटाबेस पहले दृष्टिकोण (edmx xml फ़ाइल पैदा करने) का उपयोग करना सामान्य रूप से काम करता है। यह अपेक्षा के अनुसार तेज़ है।

अब तक कोई समाधान नहीं है। शायद ईएफ 6 इसे हल करेगा।

Answer 4

मुझे एक ही समस्या थी। और मैंने उस मुद्दे को हल करने के लिए एक चाल का इस्तेमाल किया। चूंकि एंटिटी फ्रेमवर्क को पहली बार एक्सेस करते समय थोड़ा और समय लगता है और फिर यह परिणाम के कुछ समय पहले परिणाम को कैश करता है (एसक्यूएल सर्वर भी परिणाम को अलग से कैश करता है)। इसलिए मैंने अपने एप्लिकेशन पर एंटिटी फ्रेमवर्क को असीमित रूप से शुरू किया। यह मेरे लिए काम किया। और मेरा आवेदन चिकना हो गया।

Global.asax पेज

protected void Application_Start() 
    { 

     Start(() => 
     { 
      using (EF.DMEntities context = new EF.DMEntities()) 
      { 
       context.DMUsers.FirstOrDefault(); 
      } 
     }); 
    } 
    private void Start(Action a) 
    { 
     a.BeginInvoke(null, null); 
    } 

Answer 5

मैं सिर्फ अपनी खोज पर इस पोस्ट भर में ठोकर खाई एफई स्टार्टअप समय में सुधार होगा।चूंकि इसमें वास्तव में कोई जवाब नहीं है, इसलिए मैं अपने निष्कर्ष जोड़ूंगा ताकि अन्य लोग इसका लाभ उठा सकें यदि वे इस पोस्ट में भी ठोकर खाएंगे।

कृपया ध्यान दें कि मैं एफई 6 का उपयोग कर रहा है, और समाधान एफई 6.

के लिए लागू है डेविड रोथ एक article है कि समस्या को संबोधित किया।

माइकल Eliasson एक ऐसी ही सवाल करने के लिए अपने answer में बहुत अच्छी तरह से यह संक्षेप:

1. एक कैश्ड db मॉडल की दुकान का उपयोग
2. उत्पन्न पूर्व संकलित विचारों
3. n का उपयोग entityframework के पूर्व संकलित संस्करण उत्पन्न