बड़ी सूचियों पर अनन्य सुरक्षा स्कोप के साथ SharePoint प्रदर्शन में कमी

सभी को नमस्कार!

इस लेख में, हमने SharePoint में बड़ी सूचियों के प्रदर्शन पर अपनी जीवन टिप्पणियों को साझा करने का निर्णय लिया।

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

पहले एक छोटी शब्दावली:

ACLs (एक्सेस कंट्रोल लिस्ट) उन प्राचार्यों की एक आदेशित सूची है जो किसी तत्व या समूह के अधिकारों को परिभाषित करते हैं।

सुरक्षा स्कोप - समूहों या उपयोगकर्ता + एसीएल के जोड़े का एक सेट।

Microsoft अनुशंसाएँ

Microsoft अनुशंसा करता है कि आप काफी सरल नियमों का पालन करें: दस्तावेज़ लाइब्रेरी या सूची प्रति 5,000 से अधिक एक साथ सुरक्षा स्कोप से बचें।

ऐसा क्यों? प्रतिबंध कहां से आया? सबसे पहले, आइए इस प्रश्न का उत्तर दें कि MS SharePoint सूची अनुरोध को कैसे संसाधित करता है।

1. सामग्री डेटाबेस पर कॉल करता है और पढ़ता है:
   एक। सूची मेटाडेटा, अर्थात् क्षेत्र सूचियों को परिभाषित करना, आदि।
   ख। कंप्यूटेड फ़ील्ड्स, इवेंट हैंडलर परिभाषाएँ और बहुत कुछ।
   सी। सूची के सभी दायरे (या प्रस्तुति)।
2. सामने के किनारे पर, यह निर्धारित करता है: उपयोगकर्ता गुंजाइश में प्रवेश करता है।
3. यह डेटा को सीधे बाहर निकालता है।

इस दृष्टिकोण के लिए स्पष्टीकरण हैं, और वे सदस्यता के बाहरी प्रदाताओं और भूमिकाओं के मॉडल का समर्थन करने के साथ जुड़े हुए हैं (पहली जगह, यानी विज्ञापन सदस्यता और भूमिकाओं का सबसे व्यापक प्रदाता है)।

व्यवहार में, आप देख सकते हैं कि अद्वितीय अधिकारों के साथ 1000 तत्वों के साथ समस्याएं पहले ही शुरू हो गई हैं।

इन SQL प्रश्नों का उपयोग करके, आप गणना कर सकते हैं कि आपके पास वर्तमान में कितने सुरक्षा स्कोप हैं:

SELECT [SiteId], [ScopeId], [RoleDefWebId], [WebId], [ScopeUrl], [Acl] FROM [your Content DB].[dbo].[Perms] order by scopeurl 

एक और भी बेहतर क्वेरी वेब URL को उजागर करती है

 SELECT [fullurl],perms.[SiteId] , perms.[ScopeId], [RoleDefWebId], [WebId], [ScopeUrl], [Acl] FROM [dbo].[Perms],[dbo].allwebs where perms.WebId = allwebs.id order by scopeurl 

एक तरफ के रूप में, आप इस एसक्यूएल का उपयोग करके प्रति सुरक्षा प्रिसिंपल की संख्या देख सकते हैं

 select COUNT(ra.PrincipalId) as [Count],p.ScopeUrl from RoleAssignment ra with(nolock) join Perms p with(nolock) on p.SiteId = ra.SiteId and p.ScopeId = ra.ScopeId group by p.ScopeUrl order by p.ScopeUrl desc 

Microsoft समस्या को हल करने का सुझाव देता है:

1. समान अधिकारों के साथ आइटम के समूहों पर अनुमतियों को एन्क्रिप्ट करने के लिए फ़ोल्डर्स का उपयोग करें।
2. विभिन्न सूचियों या दस्तावेज़ पुस्तकालयों में विभाजित करें और विरासत में मिले अधिकारों का उपयोग करें।
3. एक शीट पर 5,000 विशिष्ट अधिकारों की सीमा से परे कभी न जाएं।

इन सिफारिशों का उल्लंघन क्या होता है:

1. प्रति 1,000 अद्वितीय अधिकारों के लिए प्रदर्शन में 20% की कमी।
2. एक तत्व पर अधिकारों को तोड़ने और अद्वितीय जारी करने की कोशिश करते समय सॉफ़्टवेयर त्रुटियां।

MS SharePoint- आधारित समाधानों के लिए, यह महत्वपूर्ण है कि खेत में भार है, और यहाँ क्यों है।

डेवलपर के लिए कोई लेनदेन समर्थन नहीं है। और फॉर्म के संचालन के सेट (एक तत्व बनाएं, अधिकार तोड़ें, एमएस SharePoint में इसे अधिकार प्रदान करें):

  var item = list.AddItem(...); // ... item.Update(); item.BreakRoleInheritance(false); item.RoleAssignments.Add(new SPRoleAssignment(...)); 

अप्रत्याशित स्थानों में व्यवधान होगा, सिर्फ इसलिए कि खेत लोड का सामना नहीं कर सकता (यानी तार्किक त्रुटियों के कारण नहीं)।

यह स्पष्ट है कि सिफारिशें 2 और 3 प्रकृति में अधिक कक्ष हैं और तत्वों को एक साथ रखने और अद्वितीय अधिकारों की समस्या को हल नहीं करती हैं, इसलिए हम पहले सबसे प्रभावी तरीके के रूप में ध्यान केंद्रित करेंगे - फ़ोल्डर्स का उपयोग करना।

हमारा उदाहरण है

उदाहरण के लिए, वास्तव में काम करने वाले सिस्टम से एक सूची लें, जिसमें वर्तमान में 132,073 तत्व हैं:



इसमें 3,590 सुरक्षा स्कोप हैं - यह कुछ इस तरह दिखता है:



721 फ़ोल्डर की सूची के अंदर ...:



... कौन से अधिकार निम्नानुसार दिए गए हैं:



Google Analytics के अनुसार, औसत पृष्ठ लोड समय एक सेकंड से भी कम है - जब इस अवधि के लिए इस विशेष सूची की यात्राओं का स्तर कार्य के दौरान प्रति दिन लगभग 968 है।

हमारा दृष्टिकोण

हमारे दृष्टिकोण के अनुसार, अधिकार इस तरह वितरित किए जाते हैं:

  public static void ProcessItem(SPListItem item, SPFolder folder) { var file = item.Web.GetFile(item.UniqueId); //    item.File ..      null // http://msdn.microsoft.com/ru-ru/library/microsoft.sharepoint.splistitem.file.aspx file.MoveTo(string.Format("{0}/{1}", folder.Url, item[SPBuiltInFieldId.LinkFilename])); } 

मैं यह भी जोड़ना चाहूंगा कि यदि अधिकारों के सेट दृश्यता अनुमतियों में भिन्न नहीं हैं, लेकिन परिवर्तन की संभावना में, आप इवेंट हैंडलर का उपयोग कर सकते हैं, जो परिवर्तनों को रोक देगा।

  class PermissionEventHandler : SPItemEventReceiver { public override void ItemUpdating(SPItemEventProperties properties) { var updatingAllowed = CheckUserHasPermission(properties.Web.CurrentUser, properties.ListItem); //       if (!updatingAllowed) { properties.Cancel = true; properties.ErrorMessage = "Access denied"; } } public override void ItemAdding(SPItemEventProperties properties) { //... } //... } 

इस दृष्टिकोण के आविष्कार से पहले, हमें 5 वर्षों के लिए SharePoint के साथ मिलकर काम करना पड़ा, बहुत सारे कुत्ते और कैक्टि खाए। इसकी अपनी बारीकियां हैं, लेकिन यह निश्चित रूप से काम करता है - यह पहले से ही दो पोर्टलों पर परीक्षण कर चुका है।

हमेशा की तरह, हम अनुभव साझा करने के लिए खुश थे!