कैनवास ऐप की सामान्य प्रदर्शन समस्याएँ और उनके समाधान

आप विभिन्न प्रकार के डेटा स्रोतों का उपयोग करके कैनवास ऐप्स बना सकते हैं. व्यवसाय की जरूरतों और परिदृश्यों के आधार पर डेटा स्रोत और कनेक्टर चुनें, जिनके लिए आप ऐप डिज़ाइन कर रहे हैं. एंटरप्राइज़ ऐप्स के लिए, Microsoft Dataverse अनुशंसित डेटा स्रोत है क्योंकि यह कई प्रदर्शन लाभ प्रदान करता है। कम लेन-देन वाले ऐप के लिए, आप अपने परिवेश में किसी भी अन्य उपलब्ध डेटा स्रोतों के साथ कार्य कर सकते हैं.

किसी ऐप के प्रदर्शन संबंधी विचारों के लिए, उन यूज़र की संख्या के बारे में सोचें जो ऐप का उपयोग तब करेंगे जब इसे प्रकाशित किया गया हो; बनाने, पुनर्प्राप्त करने, अपडेट करने और हटाने (CRUD) लेन-देन की मात्रा; डेटा इंटरैक्शन का प्रकार; भौगोलिक पहुंच; और यूज़र के पास जिस तरह के डिवाइस हैं.

इस आलेख में, आप उन कुछ सबसे सामान्य प्रदर्शन समस्याओं के बारे में जानेंगे, जिनके कारण कैनवास ऐप धीरे चल सकता है और उन्हें हल करने के तरीके के बारे में जानेंगे. यह जानकारी आपको अपनी व्यवसाय योजना और विकास को ध्यान में रखते हुए ऐप के प्रदर्शन को बेहतर बनाने में मदद करेगी.

हम प्रदर्शन संबंधी कुछ सामान्य समस्याओं के साथ शुरू करेंगे जो कनेक्टर के उपयोग के बावजूद होती हैं. बाद के अनुभागों में, आप विभिन्न कनेक्टर्स के लिए विशिष्ट प्रदर्शन समस्याओं और समाधानों के बारे में जानेंगे.

शुरू करने से पहले, यह सुनिश्चित कर लें कि आप कैनवास ऐप निष्पादन चरण और डेटा कॉल प्रवाह को समझते हैं. इसके अलावा, सामान्य नुकसान के बारे में जानने के लिए जिसे आप कैनवास ऐप्स को डिज़ाइन या अपडेट करते समय टाल सकते हैं के लिए कैनवास ऐप के लिए धीमे प्रदर्शन के सामान्य स्रोत पढ़ें.

विभिन्न प्लेटफ़ॉर्म पर बड़े डेटा सेट धीरे-धीरे लोड हो रहे हैं

किसी ऐप का प्रदर्शन विभिन्न प्लेटफ़ॉर्म जैसे iOS या पर डेटा के बड़े सेट लोड करते समय भिन्न हो सकता है। Android यह भिन्नता प्रत्येक प्लेटफ़ॉर्म पर भिन्न नेटवर्क अनुरोध सीमाओं के कारण होती है. उदाहरण के लिए, प्लेटफ़ॉर्म के आधार पर अनुमत समवर्ती नेटवर्क अनुरोधों की संख्या अलग-अलग हो सकती है. यह अंतर बड़े डेटा सेट के लिए डेटा लोड समय पर एक बड़ा प्रभाव डाल सकता है.

हम सिफारिश करते हैं कि आप केवल उस डेटा को लोड करें जिसे आपको स्क्रीन पर तुरंत प्रदर्शित करने की आवश्यकता है. अन्य डेटा के लिए, अपने डेटा को पृष्ठांकन और कैश करें. अधिक जानकारी: सुझाव और कैनवस ऐप के प्रदर्शन को बेहतर बनाने के लिए सर्वोत्तम अभ्यास

बहुत से स्तंभ पुनर्प्राप्त किए गए

हम सिफारिश करते हैं कि आप केवल उन कॉलम का चयन करें जो ऐप के लिए आवश्यक हैं. डेटा स्रोत से अधिक (या सभी) कॉलम जोड़ने से कॉलम में सारा डेटा डाउनलोड होता है. इस क्रिया के परिणामस्वरूप नेटवर्क ओवरहेड कॉल की अधिक संख्या हो जाती है, जिससे क्लाइंट डिवाइस में उच्च मेमोरी का उपयोग होता है. यह समस्या मोबाइल डिवाइस वाले उपयोगकर्ताओं को तब और ज्यादा प्रभावित कर सकती है, जब नेटवर्क बैंडविड्थ सीमित हो या डिवाइस की सीमित मेमोरी हो या लीगेसी प्रोसेसर हो.

उदाहरण के लिए, यदि आप अपने ऐप के लिए डेटा स्रोत के रूप में Dataverse का उपयोग करते हैं, तो स्पष्ट स्तंभ चयन को सक्षम करना सुनिश्चित करें. यह सुविधा Power Apps को केवल ऐप में उपयोग किए जाने वाले कॉलम के लिए डेटा रिट्राइव्ल को प्रतिबंधित करने देती है.

कैनवास ऐप पर स्पष्ट कॉलम चयन सुविधा चालू करने के लिए, सेटिंग्स > आगामी सुविधाएं > पूर्वावलोकन पर जाएं, और फिर स्पष्ट कॉलम चयन टॉगल चालू करें.

असमर्थित या लीगेसी ब्राउज़र

वे यूज़र जो असमर्थित या लीगेसी ब्राउज़र का उपयोग करते हैं, उन्हें प्रदर्शन संबंधी समस्याओं का अनुभव करना पड़ सकता है. सुनिश्चित करें कि कैनवस ऐप चलाने के लिए यूज़र केवल समर्थित ब्राउज़र का उपयोग करते हैं.

भौगोलिक दूरी के कारण धीमा प्रदर्शन

परिवेश की भौगोलिक स्थिति और यूज़र से डेटा स्रोत की दूरी प्रदर्शन को प्रभावित कर सकती है.

हम सिफारिश करते हैं कि आपका परिवेश यूज़र के करीब स्थित हो. हालांकि Power Apps सामग्री के लिए Azure सामग्री वितरण नेटवर्क का उपयोग करता है, फिर भी डेटा कॉल, डेटा स्रोत से डेटा प्राप्त करते हैं. अन्य भौगोलिक स्थिति में स्थित डेटा स्रोत, ऐप के प्रदर्शन पर प्रतिकूल प्रभाव डाल सकता है.

अत्यधिक भौगोलिक दूरी विभिन्न तरीकों से प्रदर्शन को प्रभावित करती है, जैसे विलंबता, कम प्रवाह क्षमता, कम बैंडविड्थ या पैकेट को खोना.

अनुमतिसूची कॉन्फ़िगर नहीं की गई है

सुनिश्चित करें कि आवश्यक सेवा URL को ब्लॉक नहीं किया गया है या उन्हें आपके फ़ायरवॉल की अनुमतिसूची में जोड़ा गया है. Power Apps के लिए अनुमत आवश्यक सभी सेवा URL की पूरी सूची के लिए, आवश्यक सेवाएँ पर जाएँ.

गैर-प्रत्यायोजनीय फ़ंक्शन का उपयोग और गैर-प्रत्यायोजनीय क्वेरी के लिए अनुचित डेटा पंक्ति सीमा

प्रत्यायोजनीय फ़ंक्शन डेटा स्रोत पर डेटा के संस्करण को दर्शाते हैं, जो क्लाइंट-साइड पर ओवरहेड को न्यूनतम करते हैं. प्रत्यायोजन के संभव न होने पर, आप गैर-प्रत्यायोजनीय क्वेरी के लिए डेटा पंक्ति सीमा को सीमित कर सकते हैं, ताकि सर्वर-आधारित कनेक्शन से लौटी गई पंक्तियों की संख्या इष्टतम बनी रहे.

गैर-प्रत्यायोजनीय फ़ंक्शन का उपयोग और गैर-प्रत्यायोजनीय क्वेरी के लिए अनुचित डेटा पंक्ति सीमा, डेटा स्थानांतरण पर अतिरिक्त ओवरहेड जोड़ते हैं. इस ओवरहेड के परिणामस्वरूप क्लाइंट-साइड पर JS हीप में प्राप्त डेटा पर फेर-बदल होता है. जब भी उपलब्ध हो, ऐप के लिए डेलीगेबल फ़ंक्शन का उपयोग करना सुनिश्चित करें और गैर-डेलीगेबल क्वेरी के लिए सबसे अच्छी डेटा पंक्ति सीमा का उपयोग करें.

अधिक जानकारी: प्रत्यायोजन, प्रत्यायोजन ओवरव्यू का उपयोग करें

OnStart इवेंट को ट्यूनिंग की आवश्यकता होती है

OnStart ईवेंट तब चलता है, जब ऐप्लिकेशन लोड हो रहा होता है. ऐप के OnStart परिसंपत्ति में फ़ंक्शन का उपयोग करके बड़ी मात्रा में डेटा कॉल करने से ऐप धीरे-धीरे लोड होगा. एक स्क्रीन जो नियंत्रण और अन्य स्क्रीन पर परिभाषित मानों पर बहुत अधिक निर्भर है, धीमी स्क्रीन नेविगेशन से प्रभावित होगी.

निम्नलिखित अनुभागों में इन स्थितियों में अनुभव की जाने वाली कुछ सबसे आम समस्याओं का वर्णन किया गया है.

OnStart इवेंट में उच्च संख्या में कॉल के कारण ऐप धीरे-धीरे शुरू होता है

एंटरप्राइज़ में, केंद्रीय डेटा स्रोत पर डेटा कॉल की मात्रा, सर्वर में बाधाएँ या संसाधन प्रतिस्‍पर्धा पैदा कर सकती है.

कैश मेकेनिज़्म का उपयोग डेटा कॉल अनुकूलित करने मे करें. एक एकल ऐप कई उपयोगकर्ताओं द्वारा उपयोग किया जा सकता है, जिसके परिणामस्वरूप प्रति उपयोगकर्ता कई डेटा कॉल होते हैं, जो सर्वर के एंडपॉइंट्स तक पहुंचते हैं. ये डेटा कॉल एक ऐसा स्थान हो सकता है, जहां बाधाएँ या थ्रॉटलिंग हो सकती है.

भारी स्क्रिप्ट की वजह से OnStart इवेंट पर लेटेंसी

OnStart इवेंट पर भारी स्क्रिप्ट, कैनवास ऐप को डिज़ाइन करते समय सबसे आम गलतियों में से एक है. आपको केवल ऐप को शुरू करने के लिए आवश्यक डेटा प्राप्त करना चाहिए.

OnStart इवेंट में सूत्र अनुकूलित करें. उदाहरण के लिए, आप इसके बजाय कुछ फ़ंक्शन को OnVisible परिसंपत्ति में स्थानांतरित कर सकते हैं. इस तरह से आप ऐप को जल्दी से शुरू कर सकते हैं, और ऐप के खुलने पर अन्य चरण भी जारी रह सकते हैं.

अधिक जानकारी: OnStart परिसंपत्ति को कस्टमाइज़ करें

युक्ति

हम App.StartScreen संपत्ति का उपयोग करने की सलाह देते हैं क्योंकि यह ऐप लॉन्च को आसान बनाता है और ऐप के प्रदर्शन को बढ़ाता है.

क्लाइंट-साइड पर मेमोरी का दबाव

कैनवास ऐप की मेमोरी उपयोग की जांच करना महत्वपूर्ण है क्योंकि अधिकांश समय, ऐप मोबाइल डिवाइसों पर चलता है. हीप में मेमोरी अपवाद, उस कैनवास ऐप के पीछे सबसे अधिक संभावित कारण हैं, जो कुछ डिवाइस पर क्रैश या फ़्रीज़ ("हैंग") हो जाता है.

जोड़ने, जुड़ने, फिल्टर करने, छांटने या समूह बनाने के लिए क्लाइंट की तरफ चलने वाली भारी स्क्रिप्ट की वजह से JavaScript (JS) ढेर की सीमा तक पहुंच सकता है. ज्यादातर मामलों में, क्लाइंट में हीप पर आउट-ऑफ़-मेमोरी अपवाद के कारण ऐप क्रैश या हैंग हो सकता है.

Dataverse या SQL Server जैसे स्रोतों से डेटा का उपयोग करते समय, आप यह सुनिश्चित करने के लिए कि जॉइनिंग, फ़िल्टरिंग, ग्रुपिंग या सॉर्टिंग क्लाइंट-साइड की बजाए सर्वर-साइड पर हो, दृश्य ऑब्जेक्ट का उपयोग कर सकते हैं. यह दृष्टिकोण ऐसी क्रियाओं के लिए स्क्रिप्टिंग के क्लाइंट ओवरहेड को कम करता है.

यदि क्लाइंट-हैवी ऑपरेशन जैसे JOIN या ग्रुप बाय क्लाइंट साइट पर एक डेटासेट के साथ होता है, जिसमें 2,000 रिकॉर्ड या अधिक हैं, तो ढेर में वस्तु बढ़ जाएंगी, जिसके परिणामस्वरूप मेमोरी की सीमाएं पार हो जाएंगी.

अधिकांश ब्राउज़रों के लिए डेवलपर उपकरण के चलते आप मेमोरी को प्रोफ़ाइल कर सकते हैं. यह आपको ढेर का आकार, दस्तावेजों, नोड्स और सुनने वालों की कल्पना करने में मदद करता है. ब्राउज़र का उपयोग करके ऐप के प्रदर्शन को प्रोफ़ाइल करें, जैसा कि Microsoft Edge (क्रोमियम) डेवलपर टूल ओवरव्यू में वर्णित किया गया है. उन परिदृश्यों की जांच करें जो JS ढेर की मेमोरी सीमा से अधिक हैं. अधिक जानकारी: मेमोरी की समस्याओं को ठीक करें

SQL Server कनेक्टर के लिए प्रदर्शन विचार

आप SQL सर्वर को ऑन-प्रिमाइसेस या Azure SQL डेटाबेस से कनेक्ट करने के लिए Power Apps के लिए SQL Server कनेक्टर का उपयोग कर सकते हैं. यह अनुभाग एक कैनवास ऐप के लिए इस कनेक्टर का उपयोग करने के लिए सामान्य प्रदर्शन से संबंधित समस्याओं और समाधानों का वर्णन करता है. अधिक जानकारी: Power Apps से SQL सर्वर से कनेक्ट करें, Azure SQL डेटाबेस से एक कैनवास ऐप बनाएं

नोट

हालांकि यह अनुभाग प्रदर्शन की समस्याओं और समाधानों के लिए SQL सर्वर कनेक्टर का संदर्भ देता है, लेकिन अधिकांश सिफारिशें किसी भी डेटाबेस प्रकार—जैसे कि MySQL या PostgreSQL—को डेटा स्रोत के रूप में उपयोग करने पर भी लागू होती हैं.

आइए कैनवास ऐप के लिए SQL Server कनेक्टर के लिए सामान्य प्रदर्शन समस्याओं और उनके समाधानों पर एक नज़र डालें.

N+1 क्वेरी

सर्वर से बहुत अधिक अनुरोध उत्पन्न करने वाली गैलरी N+1 पूछताछ की समस्याओं का कारण बनती हैं. N+1 पूछताछ समस्या गैलरी नियंत्रण का उपयोग करने के साथ सबसे अधिक बार अनुभव की जाने वाली समस्याओं में से एक है.

समस्या से बचने के लिए, SQL बैक एंड में वस्तुएं देखें का उपयोग करें या यूजर इंटरफेस परिदृश्यों को बदलें.

इंडेक्स की तलाश के बजाय टेबल स्कैन करें

यदि एप्लिकेशन द्वारा उपयोग किए जाने वाले फ़ंक्शन डेटाबेस में उन क्वेरी को धीमा कर सकते हैं जो इंडेक्स की तलाश के बजाय टेबल स्कैन में परिणाम देते हैं. अधिक जानकारी: संकेत, तालिका स्कैन और इंडेक्स खोज

ऐसी समस्याओं को हल करने के लिए, सूत्र में IN के बजाए StartsWith का उपयोग करें. SQL डेटा स्रोत के साथ, StartsWith ऑपरेटर एक इंडेक्स तलाश में परिणाम देता है, लेकिन इन ऑपरेटर एक इंडेक्स या टेबल स्कैन में परिणाम देता है.

धीमी क्वेरी

आप धीमी क्वेरी को प्रोफ़ाइल और ट्यून और SQL डेटाबेस पर इंडेक्स कर सकते हैं. उदाहरण के लिए, यदि किसी निश्चित कॉलम पर एक फॉर्मूला अवरोही (DESC) आदेश के साथ डेटा प्राप्त करता है, तो उस सॉर्टिंग कॉलम में अवरोही क्रम के साथ एक इंडेक्स होना चाहिए. इंडेक्स कुंजी डिफ़ॉल्ट रूप से आरोही (ASC) क्रम बनाती है.

आप डेटा अनुरोधों का URL पता भी देख सकते हैं. उदाहरण के लिए, निम्न डेटा स्निपेट (आंशिक OData कॉल) से अनुरोध करता है कि वह SQL से अवरोही क्रम में मान और ID के अनुसार ऑर्डर से 500 रिकॉर्ड मैचिंग स्तंभ देने को कहे.

Items? \$filter=Column eq 'Value' & Orderby = ID desc & top 500

यह समान अनुरोध स्थितियों को कवर करने के लिए इंडेक्स आवश्यकताओं को समझने में मदद करता है. इस उदाहरण में, अगर ID कॉलम में अवरोही क्रम के साथ इंडेक्स है, तो क्वेरी को अधिक तेज़ी से किया जाएगा.

यह देखने के लिए कि कोई तालिका या इंडेक्स स्कैन मौजूद है या नहीं, धीमी क्वेरी की निष्पादन योजना की जाँच करें. निष्पादन योजना में मुख्य लुकअप की किसी भी अत्यधिक लागत को मॉनीटर करें.

और जानकारी:

• प्रदर्शन को मॉनीटर और ट्यून करें
• क्वेरी स्टोर का उपयोग करके प्रदर्शन की निगरानी
• विस्तारित इवेंट का अवलोकन

डेटाबेस संसाधन प्रतिस्‍पर्धा

सुनिश्चित करें कि डेटा स्रोत—SQL डेटाबेस—में कोई संसाधन प्रतिस्‍पर्धा नहीं है, जैसे प्रोसेसर बाधा, I/O प्रतिस्‍पर्धा, मेमोरी दबाव या tempDB प्रतिस्‍पर्धा. लॉक्स, प्रतीक्षा, डेडलॉक और क्वेरी टाइमआउट की भी जाँच करें.

युक्ति

संभावित क्वेरी प्रदर्शन समस्याओं, सुझावित समाधानों के बारे में जानकारी पाने और पहचानी गई समस्याओं को स्वचालित रूप से ठीक करने के लिए स्वचालित ट्यूनिंग का उपयोग करें.

मोटा क्लाइंट या अत्यधिक अनुरोध

क्लाइंट-साइड पर इसके अनुसार समूहीकृत करें, इसके अनुसार फ़िल्टर करें या शामिल हों कार्रवाइयाँ चलाने वाला ऐप, क्लाइंट डिवाइस से प्रोसेसर और मेमोरी संसाधनों का उपयोग करता है. डेटा के आकार के आधार पर, ये कार्रवाइयाँ क्लाइंट-साइड पर अधिक स्क्रिप्टिंग समय ले सकती हैं, जिससे क्लाइंट पर JS हीप आकार में वृद्धि हो सकती है. ऑन-प्रिमाइसेस डेटा स्रोत के लिए यह समस्या बढ़ जाती है, क्योंकि प्रत्येक लुकअप डेटा कॉल डेटा गेटवे के माध्यम से डेटा स्रोत पर जाती है.

ऐसी स्थितियों में, ग्रुप बाय, फ़िल्टर बाय, या जॉइन संचालन के लिए SQL डेटाबेस में व्यू ऑब्जेक्ट का उपयोग करें। दृश्य चयनात्मक स्तंभों का उपयोग कर सकते हैं, और NVARCHAR(MAX), VARCHAR(MAX), and VARBINARY(MAX) जैसे बड़े डेटा प्रकार वाले अनावश्यक स्तंभों को निकाल सकते हैं.

युक्ति

यह दृष्टिकोण N+1 क्वेरी समस्या का हल करने में भी मदद करता है.

क्लाइंट को हस्तांतरित डेटा का आकार

डिफ़ॉल्ट रूप से, कैनवस ऐप उपलब्ध डेटाबेस ऑब्जेक्ट से तालिकाओं या दृश्यों का उपयोग करके डेटा को दिखाता है. तालिका से सभी स्तंभों को पुनर्प्राप्त करने के परिणामस्वरूप धीमी प्रतिक्रिया हो सकती है, विशेष रूप तब, जब NVARCHAR(MAX) जैसे बड़े डेटा प्रकारों का उपयोग किया जा रहा हो.

क्लाइंट को बड़ी मात्रा में डेटा स्थानांतरित करने में समय लगता है. इस ट्रांसफर के परिणामस्वरूप अधिक स्क्रिप्टिंग समय भी होता है जब क्लाइंट की तरफ JS ढेर में बड़ी मात्रा में डेटा होते हैं, जैसा कि इस आलेख में पहले बताया गया है.

ग्राहक को ट्रांसफर किए जा रहे डेटा के आकार को कम करने के लिए, ऐप के लिए आवश्यक विशिष्ट कॉलम के साथ व्यू का उपयोग करें और सुनिश्चित करें कि स्पष्ट कॉलम चयन सक्षम है, जैसा कि इस आलेख में पहले वर्णित है.

SQL Server on-premises के लिए विशिष्ट विचार

ऑन-प्रिमाइसेस डेटा गेटवे के साथ SQL सर्वर कनेक्टर का उपयोग करते हुए कैनवास ऐप का प्रदर्शन विभिन्न तरीकों से प्रभावित हो सकता है. यह अनुभाग उन सामान्य प्रदर्शन समस्याओं और उनके समाधानों को सूचीबद्ध करता है, जो ऑन-प्रिमाइसेस डेटाबेस स्रोत का उपयोग करने से संबंधित हैं.

अस्वस्थ ऑन-प्रिमाइसेस डेटा गेटवे

ऑन-प्रिमाइसेस डेटा गेटवे के लिए संगठन कई नोड्स को परिभाषित कर सकते हैं. यहां तक कि यदि नोड्स में से एक भी पहुंच से बाहर है, तो अस्वस्थ नोड तक डेटा अनुरोध एक स्वीकार्य समय सीमा के भीतर परिणाम नहीं लौटाएगा, या वे थोड़ी देर इंतजार करने के बाद "अनरिचेबल" त्रुटि संदेश का कारण बन सकते हैं.

सुनिश्चित करें कि सभी ऑन-प्रिमाइसेस डेटा गेटवे नोड्स स्वस्थ हैं और नोड्स और SQL आवृत्ति के बीच एक न्यूनतम नेटवर्क लेटेंसी के साथ कॉन्फ़िगर किए गए हैं.

ऑन-प्रिमाइसेस डेटा गेटवे का स्थान

डेटा गेटवे को OData अनुरोधों की व्याख्या करने के लिए ऑन-प्रिमाइसेस डेटा स्रोतों के लिए नेटवर्क कॉल की आवश्यकता होती है. उदाहरण के लिए, डेटा गेटवे को OData अनुरोधों को SQL डेटा हेरफेर भाषा (DML) कथनों में अनुवाद करने के लिए डेटा टेबल स्कीमा को समझने की आवश्यकता है. जब डेटा गेटवे को डेटा गेटवे और SQL इंस्टेंस के बीच उच्च नेटवर्क विलंबता के साथ एक अलग स्थान पर कॉन्फ़िगर किया जाता है, तो अतिरिक्त ओवरहेड जोड़ा जाता है।

एंटरप्राइज़ परिवेश में, भारी डेटा अनुरोध की अपेक्षा किए जाने पर एक स्केलेबल डेटा गेटवे क्लस्टर रखने की अनुशंसा की जाती है. जाँचें कि डेटा गेटवे नोड्स और SQL आवृत्ति के बीच कितने कनेक्शन स्थापित हैं.

ऑन-प्रिमाइसेस डेटा गेटवे या SQL इंस्टेंस में समवर्ती कनेक्शन की जांच करके, आपका संगठन उस बिंदु की पहचान कर सकता है जहां डेटा गेटवे को छोटा करने की आवश्यकता है, और इसे कितने नोड्स के साथ किया जाना चाहिए.

डेटा गेटवे स्केलेबिलिटी

यदि आप ऑन-प्रिमाइसेस डेटा गेटवे से बड़ी मात्रा में डेटा एक्सेस करने की अपेक्षा करते हैं, तो ऑन-प्रिमाइसेस डेटा गेटवे का सिर्फ एक नोड अनुरोधों की इतनी बड़ी मात्रा को संभालने में बाधा बन सकता है.

ऑन-प्रिमाइसेस डेटा गेटवे का एक नोड 200 या उससे कम समवर्ती कनेक्शन से निपटने के लिए पर्याप्त हो सकता है. हालाँकि, यदि ये सभी समवर्ती कनेक्शन सक्रिय रूप से क्वेरी को निष्पादित कर रहे हैं, तो अन्य अनुरोध उपलब्ध कनेक्शन की प्रतीक्षा करेंगे.

यह सुनिश्चित करने के बारे में जानकारी के लिए कि आपका ऑन-प्रिमाइसेस डेटा गेटवे स्केल डेटा और अनुरोधों की मात्रा के अनुसार है, ऑन-प्रिमाइसेस डेटा गेटवे प्रदर्शन की निगरानी और ऑप्टिमाइज़ करें पर जाएं.

Azure SQL डेटाबेस के लिए विशिष्ट विचार

कैनवास ऐप SQL Server कनेक्टर का उपयोग करके Azure SQL डेटाबेस से कनेक्ट कर सकते हैं. Azure SQL डेटाबेस का उपयोग करते समय प्रदर्शन समस्याओं का एक सामान्य कारण आपकी व्यावसायिक आवश्यकताओं के लिए गलत स्तर का चयन करना है.

Azure SQL डेटाबेस अलग-अलग सेवा टियर में उपलब्ध है, जिसमें विभिन्न व्यावसायिक आवश्यकताओं के मिलान के लिए अलग-अलग क्षमताएं हैं. टियर के बारे में अधिक जानकारी के लिए, Azure SQL डेटाबेस दस्तावेज़ पर जाएँ.

भारी डेटा अनुरोधों के साथ, आपके द्वारा चयनित टियर पर संसाधन सीमा मान तक पहुंचते ही थ्रॉटल हो सकते हैं. इस तरह के थ्रॉटलिंग, क्वेरी के अगले सेट के प्रदर्शन से समझौता करती हैं.

Azure SQL डेटाबेस के सेवा टियर की जाँच करें. एक निचले टियर पर कुछ सीमाएं और बाधाएं होंगी. प्रदर्शन के दृष्टिकोण से, CPU, I/O थ्रूपुट और लेटेंसी महत्वपूर्ण हैं. इसलिए, हम सिफारिश करते हैं कि आप समय-समय पर SQL डेटाबेस के प्रदर्शन की जांच करें और जांच करें कि संसाधन उपयोग सीमा से अधिक तो नहीं हैं. उदाहरण के लिए, ऑन-प्रिमाइसेस SQL Server सामान्य रूप से CPU उपयोग के थ्रेशोल्ड को लगभग 75 प्रतिशत पर सेट करता है.

SharePoint कनेक्टर के लिए प्रदर्शन विचार

Microsoft Lists से डेटा का उपयोग करके ऐप्स बनाने के लिए आप SharePoint कनेक्टर का उपयोग कर सकते हैं. आप सीधे सूची दृश्य से कैनवास ऐप भी बना सकते हैं. आइए कैनवास ऐप के साथ SharePoint डेटा स्रोत का उपयोग करते समय सामान्य प्रदर्शन समस्याओं और उनके समाधानों पर एक नज़र डालें.

बहुत सारे डायनेमिक लुकअप स्तंभ

SharePoint विभिन्न डेटा प्रकारों का समर्थन करता हैजिसमें व्यक्ति, समूह, और परिकलित जैसे डायनेमिक लुकअप शामिल हैं. यदि सूची बहुत अधिक डायनेमिक स्तंभों को परिभाषित करती है, तो कैनवास ऐप को चलाने वाले क्लाइंट को डेटा लौटाने से पहले SharePoint के अंतर्गत इन डायनेमिक स्तंभों में फेर बदल करने में अधिक समय लगता है.

SharePoint में डायनेमिक लुकअप स्तंभों का अति प्रयोग न करें. इस अति प्रयोग के कारण डेटा में फेर बदल के लिए SharePoint साइट पर परिहार्य और अतिरिक्त ओवरहेड लग सकता है. इसके बजाय, उदाहरण के लिए, आप ईमेल उपनाम या लोगों के नाम रखने के लिए स्थैतिक कॉलम का उपयोग कर सकते हैं.

चित्र स्तंभ और अनुलग्नक

क्लाइंट को रिट्राइव करते समय एक छवि और संलग्न फ़ाइल का आकार धीमी प्रतिक्रिया में योगदान कर सकता है.

अपनी सूची की समीक्षा करें और सुनिश्चित करें कि केवल आवश्यक स्तंभ परिभाषित किए गए हैं. सूची में स्तंभों की संख्या डेटा अनुरोधों के प्रदर्शन को प्रभावित करती है. ऐसा इसलिए है क्योंकि मिलान किए गए रिकॉर्ड, या परिभाषित डेटा पंक्ति सीमाओं तक के रिकॉर्ड, रिट्राइव किए जाते हैं और सूची में परिभाषित सभी कॉलम के साथ ग्राहक को वापस प्रेषित किए जाते हैं—भले ही ऐप उन सभी का उपयोग न करता हो.

केवल ऐप द्वारा उपयोग किए जाने वाले कॉलम की पूछताछ करने के लिए, स्पष्ट कॉलम चयन सुविधा को सक्षम करें, जैसा कि इस आलेख में पहले वर्णित है.

बड़ी सूचियाँ

यदि आपके पास सैकड़ों हजारों रिकॉर्ड वाली एक बड़ी सूची है, तो सूची को विभाजित करने पर विचार करें या सूची को श्रेणियों या दिनांक और समय जैसे मापदंडों के आधार पर कई सूचियों में विभाजित करें.

उदाहरण के लिए, आपके डेटा को वार्षिक या मासिक आधार पर विभिन्न सूचियों में संग्रहित किया जा सकता है. ऐसे मामले में, आप यूज़र को एक टाइम विंडो चुनने और उस सीमा के भीतर डेटा पुनर्प्राप्त करने देने के लिए ऐप डिज़ाइन कर सकते हैं.

एक नियंत्रित परिवेश के भीतर, प्रदर्शन बेंचमार्क ने यह साबित कर दिया है कि Microsoft Lists या SharePoint सूचियों के खिलाफ OData अनुरोधों का प्रदर्शन सूची में कॉलम की संख्या और रिट्राइव की जा रही पंक्तियों की संख्या से संबंधित है (गैर-डेलीगेबल क्वेरी के लिए डेटा पंक्ति की सीमा द्वारा सीमित है). कम कॉलम और कम डेटा पंक्ति सीमा सेटिंग होने से कैनवास ऐप बेहतर प्रदर्शन कर सकता है.

हालांकि वास्तविक दुनिया में, ऐप को कुछ खास व्यावसायिक आवश्यकताओं को पूरा करने के लिए डिज़ाइन किया गया है. हो सकता है कि डेटा पंक्ति सीमा या सूची में स्तंभों की संख्या को कम करना त्वरित या सरल न हो. हालांकि, हम सिफारिश करते हैं कि आप ग्राहक साइड में OData अनुरोधों की निगरानी करें और गैर-डेलीगेबल क्वेरी और सूची में कॉलमों की संख्या के लिए डेटा पंक्ति सीमा को ट्यून करें.

डेटा स्रोत के रूप में Dataverse का उपयोग करते समय प्रदर्शन विचार

जब आप Microsoft Dataverse को डेटा स्रोत के रूप में उपयोग करते हैं, तो डेटा अनुरोध Azure API प्रबंधन से गुजरे बिना, सीधे परिवेश इंस्टेंस पर जाते हैं. अधिक जानकारी: Microsoft Dataverse से कनेक्ट होने पर डेटा कॉल फ्लो

युक्ति

जब Dataverse में कस्टम टेबल का उपयोग किया जाता है, तो उपयोगकर्ताओं को कैनवास ऐप्स के साथ रिकॉर्ड देखने लायक होने के लिए अतिरिक्त सुरक्षा कॉन्फ़िगरेशन की आवश्यकता हो सकती है. अधिक जानकारी: Dataverse में सुरक्षा अवधारणाएं, परिवेश में संसाधनों के लिए यूज़र सुरक्षा कॉन्फ़िगर करें, और सुरक्षा भूमिकाएं और विशेषाधिकार

अगर यह क्लाइंट-भारी स्क्रिप्टिंग जैसे कि के अनुसार फ़िल्टर या JOIN क्लाइंट-साइड के बजाय सर्वर-साइड चलाता है तो Dataverse से जुड़ा एक कैनवस ऐप धीरे-धीरे प्रदर्शन कर सकता है.

संभव होने पर, Dataverse दृश्य का उपयोग करें. आवश्यक 'शामिल हों' या 'फ़िल्टर' मानदंडों वाला एक दृश्य, संपूर्ण तालिका का उपयोग करने के ओवरहेड को कम करने में मदद करता है. उदाहरण के लिए, यदि आपको टेबल में शामिल होने और उनके डेटा को फ़िल्टर करने की ज़रूरत है, तो आप उनसे जुड़कर एक दृश्य परिभाषित कर सकते हैं और केवल उन कॉलम को परिभाषित कर सकते हैं जिनकी आपको आवश्यकता है. फिर आप अपने ऐप में इस दृश्य का उपयोग कर सकते हैं, जो क्लाइंट साइड के बजाय जॉइन/ फिल्टर ऑपरेशन के लिए सर्वर साइड पर इस ओवरहेड को बनाता है.यह विधि न केवल अतिरिक्त संचालन को कम करती है, बल्कि डेटा ट्रांसमिशन को भी कम करती है। फ़िल्टर को संपादित करने और सॉर्ट मापदंड के बारे में जानकारी के लिए, फ़िल्टर संपादित करें मापदंड पर जाएँ.

Excel कनेक्टर के लिए प्रदर्शन विचार

Excel कनेक्टर Excel फ़ाइल के अंदर एक तालिका में कैनवास ऐप से डेटा तक कनेक्टिविटी प्रदान करता है. इस कनेक्टर की अन्य डेटा स्रोतों की तुलना में सीमाएं हैं—उदाहरण के लिए, सीमित प्रतिनिधि फ़ंक्शन—जो कैनवास ऐप को टेबल से केवल 2,000 रिकॉर्ड तक डेटा लोड करने के लिए प्रतिबंधित करता है. 2000 से अधिक रिकॉर्ड लोड करने के लिए, अपने डेटा को अन्य डेटा स्रोतों के रूप में विभिन्न डेटा तालिकाओं में विभाजित करें.

आइए, कैनवास ऐप्स के डेटा स्रोत के रूप में एक्सेल का उपयोग करने और उन्हें कैसे हल करें, के साथ सामान्य प्रदर्शन समस्याओं पर एक नज़र डालें.

बहुत अधिक डेटा तालिकाएँ और बड़ा डेटा आकार

एक ऐप तब धीरे प्रदर्शन कर सकता है जब वह एक एक्सेल फ़ाइल का उपयोग करता है जिसमें बहुत अधिक डेटा टेबल, या ऐसे डेटा टेबल होते हैं जिसमें कई कॉलम पर डेटा की विशाल मात्रा होती है. Excel फ़ाइल एक रिलेशनल डेटाबेस नहीं है या एक ऐसा डेटा स्रोत नहीं है, जो प्रत्यायोजनीय फ़ंक्शन प्रदान करता हो. Power Apps को पहले परिभाषित डेटा तालिका से डेटा लोड करना होगा और फिर फ़ंक्शन जैसे कि फ़िल्टर, सॉर्ट, शामिल हों, इसके अनुसार समूहीकृत करें और खोज का उपयोग करना होगा.

पंक्तियों और सतंभों की कई संख्या वाली बहुत सारी डेटा तालिकाएँ ऐप के प्रदर्शन और क्लाइंट-साइड ओवरहेड को प्रभावित करती है, क्योंकि JS हीप के अंतर्गत प्रत्येक डेटा तालिका में फेर बदल करने की आवश्यकता होती है. इस प्रभाव के कारण ऐप अधिक क्लाइंट-साइड मेमोरी का भी उपभोग करता है.

यह सुनिश्चित करने के लिए कि आपका ऐप इस समस्या से प्रभावित नहीं है, केवल वे कॉलम परिभाषित करें जो Excel फ़ाइल में डेटा टेबल पर आपके लिए आवश्यक हैं.

भारी लेनदेन

Excel रिलेशनल डेटाबेस सिस्टम नहीं है. ऐप के किसी भी परिवर्तन को Excel द्वारा उसी तरह प्रबंधित किया जाता है, यदि उपयोगकर्ता Excel फ़ाइल में डेटा बदलते हैं. यदि ऐप में अधिक संख्या में रीड्स हैं, लेकिन कम CRUD ऑपरेशन हैं, तो यह अच्छा प्रदर्शन कर सकता है. हालाँकि, यदि ऐप भारी लेनदेन करता है, तो यह ऐप के प्रदर्शन पर प्रतिकूल प्रभाव डाल सकता है.

लेन-देन की संख्या के लिए कोई विशिष्ट सीमा मान नहीं है, क्योंकि यह डेटा के मैनिपुलेशन पर भी निर्भर करता है. कई अन्य पहलू भी ऐप के प्रदर्शन को प्रभावित करते हैं, जैसे कि नेटवर्क ओवरहेड या उपयोगकर्ता का डिवाइस.

यदि आपके पास केवल-पढ़ने के लिए डेटा है, तो आप डेटा स्रोत से डेटा को लोड करने के बजाय उस डेटा को ऐप में स्थानीय रूप से आयात कर सकते हैं. एंटरप्राइज़ ऐप के लिए, आपके इसके बजाए Dataverse, SQL Server या SharePoint जैसे डेटा स्रोतों का उपयोग करें.

फ़ाइल का आकार

आप Excel फ़ाइल के लिए अलग-अलग—या कॉन्फ़िगर—करने योग्य संग्रहण क्षमता वाले क्लाउड संग्रहण विकल्पों की विस्तृत श्रृंखला में से चुन सकते हैं. हालांकि, उस फ़ाइल में परिभाषित सभी टेबल के साथ एक बड़ी Excel फाइल होने से ऐप के लिए तब अतिरिक्त ओवरहेड जुड़ जाता है, जब यह फ़ाइल डाउनलोड करता है और क्लाइंट साइड पर लोड करने के लिए डेटा पढ़ता है.

एक बड़ी फ़ाइल का उपयोग करने के बजाय, डेटा को न्यूनतम डेटा तालिकाओं वाली कई Excel फ़ाइलों में विभाजित करें. तब प्रत्येक फ़ाइल से सिर्फ तब कनेक्ट करें जब आपको इसकी आवश्यकता हो. इस तरह, डेटा तालिका से डेटा लोड करना टुकड़ों में होता है, जिससे कई तालिकाओं या बड़े डेटा सेट का ओवरहेड कम हो जाता है.

फ़ाइल स्थान

डेटा स्रोत की भौगोलिक स्थिति और क्लाइंट के स्थानों से उसकी दूरी ऐप के लिए प्रदर्शन की बाधा हो सकती है और नेटवर्क विलंबता को शुरू कर सकती है. यह प्रभाव तब बढ़ सकता है जब मोबाइल क्लाइंट के पास कनेक्टिविटी के लिए सीमित बैंडविड्थ हो.

फ़ाइल को अपने यूज़र (या अधिकांश यूज़र, यदि आपके पास वैश्विक ऑडियंस है) के पास रखना बेहतर है, ताकि फ़ाइल को जल्दी से डाउनलोड किया जा सके.

अगले कदम

कैनवास ऐप के प्रदर्शन को बेहतर बनाने के लिए युक्तियाँ और सर्वोत्तम अभ्यास

इसे भी देखें

कैनवास ऐप के निष्पादन चरणों और डेटा कॉल प्रवाह को समझें
कैनवास ऐप के लिए धीमे प्रदर्शन के सामान्य स्रोत
के लिए सामान्य समस्याएं और समाधान Power Apps
Power Apps के लिए स्टार्टअप समस्याओं का निवारण करना

नोट

क्या आप हमें अपनी दस्तावेज़ीकरण भाषा वरीयताओं के बारे में बता सकते हैं? एक छोटा सर्वेक्षण पूरा करें. (कृपया ध्यान दें कि यह सर्वेक्षण अंग्रेज़ी में है)

सर्वेक्षण में लगभग सात मिनट लगेंगे. कोई भी व्यक्तिगत डेटा एकत्र नहीं किया जाता है (गोपनीयता कथन).