🕒 👦🏻 👌 Enumerable: एक व्यावसायिक मूल्य कैसे प्राप्त करें 👨🏾‍⚕️ 👇🏽 ♉️

यह लेख इस बात की संक्षिप्त व्याख्या है कि किसी सामान्य भाषा के कीवर्ड का उपयोग किसी परियोजना के आईटी-बुनियादी ढांचे के बजट पर कैसे प्रभाव डाल सकता है या बुनियादी ढांचे की मेजबानी की कुछ सीमाओं / प्रतिबंधों को प्राप्त करने में मदद करता है और, इसके अलावा, गुणवत्ता का एक अच्छा गाना होगा और स्रोत कोड की परिपक्वता।

विचारों के प्रदर्शन के लिए, लेख में C # भाषा का उपयोग किया जाएगा, लेकिन अधिकांश विचारों का अन्य भाषाओं में अनुवाद किया जा सकता है।

भाषा की विशेषताओं के सेट से, मेरे दृष्टिकोण से, 'उपज' सबसे अचूक कीवर्ड है। आप दस्तावेज़ पढ़ सकते हैं और इंटरनेट पर उदाहरणों का एक विशाल गुच्छा पा सकते हैं। संक्षिप्त रूप से, मान लें कि 'उपज' अंतर्निहित रूप से 'पुनरावृत्तियों' बनाने की अनुमति देती है। डिजाइन के अनुसार, एक पुनरावृत्तिकर्ता को 'सार्वजनिक' उपयोग के लिए एक IEnumerable स्रोत को उजागर करना चाहिए। और यहाँ मुश्किल शुरू होती है। क्योंकि हमारे पास भाषा में IEnumerable के बहुत सारे कार्यान्वयन हैं: सूची, शब्दकोश, हैशसेट, कतार और आदि। और मेरे अनुभव से, कुछ व्यावसायिक कार्य की संतुष्टि आवश्यकताओं के लिए उनमें से एक का चुनाव गलत है। इसके अलावा, यह सब जो कुछ भी कार्यान्वयन द्वारा चुना गया है, कार्यक्रम 'सिर्फ काम करता है' - यह वास्तव में व्यवसाय की आवश्यकता है, है ना? आमतौर पर, यह काम करता है, लेकिन केवल तब तक जब तक कि सेवा उत्पादन वातावरण में तैनात न हो जाए।

समस्या के प्रदर्शन के लिए, मेरा सुझाव है कि अधिकांश उद्यम परियोजना के लिए एक बहुत ही सामान्य व्यावसायिक मामला / प्रवाह का चयन करें जिसे हम लेख के दौरान बढ़ा सकते हैं और इस प्रवाह के कुछ हिस्से को उद्यम परियोजनाओं पर इस दृष्टिकोण के प्रभाव के पैमाने को समझने के लिए प्रतिस्थापित कर सकते हैं। और इसे ठीक करने के लिए आपको इस सेट में अपना मामला खोजने में मदद करनी चाहिए।

कार्य का उदाहरण:

किसी फ़ाइल या DB से रिकॉर्ड के एक सेट को मेमोरी में लोड करें।
रिकॉर्ड के प्रत्येक कॉलम के लिए मान को किसी अन्य मान में बदलें।
फ़ाइल या DB में परिवर्तन के परिणामों को सहेजें।

आइए कई मामलों को मानें जहां यह तर्क लागू हो सकता है। इस समय, मुझे दो मामले दिखाई देते हैं:

यह शायद कुछ कंसोल ETL एप्लिकेशन के लिए प्रवाह का एक हिस्सा है।
यह MVC एप्लिकेशन के नियंत्रक में कार्रवाई के अंदर एक तर्क है।

यदि हम कार्य को अधिक तकनीकी तरीके से परिभाषित करते हैं, तो यह इस तरह से ध्वनि हो सकती है: "(1) स्मृति की मात्रा आवंटित करें, (2) दृढ़ता से मेमोरी में जानकारी लोड करें, (3) संशोधित करें और (4) फ़्लिप रिकॉर्ड स्मृति में हठ भंडारण में परिवर्तन। " यहाँ वर्णन में पहला वाक्यांश "(1) स्मृति की मात्रा आवंटित करें" आपकी गैर-कार्यात्मक आवश्यकताओं के लिए वास्तविक सहसंबंध हो सकता है। क्योंकि आपकी नौकरी / सेवा को कुछ होस्टिंग वातावरण में 'लाइव' होना चाहिए, जिसमें कुछ सीमाएँ / प्रतिबंध हो सकते हैं (उदाहरण के लिए, 150Mb प्रति माइक्रो-सेवा) और बजट में आपकी सेवा पर खर्च की भविष्यवाणी करने के लिए, हमें अपनी स्मृति राशि के मामले में भविष्यवाणी करनी चाहिए। कौन सी सेवा का उपयोग करेगा (आमतौर पर हम अधिकतम मात्रा में मेमोरी के बारे में कहते हैं)। दूसरे शब्दों में, हमें आपकी सेवा के लिए एक स्मृति 'पदचिह्न' निर्धारित करना चाहिए।

आइए वास्तव में आम कार्यान्वयन के लिए एक स्मृति पदचिह्न पर विचार करें जो मैं समय-समय पर उद्यम परियोजनाओं के विभिन्न कोडबेस में निरीक्षण करता हूं। इसके अलावा, आप इसे अपनी परियोजनाओं में भी ढूंढने का प्रयास कर सकते हैं, उदाहरण के लिए, 'रिपोजिटरी' पैटर्न कार्यान्वयन के 'हूड' के तहत, बस ऐसे शब्दों को खोजने की कोशिश करें: 'ToList', 'ToArray', 'ToReadonlybollection' और आदि। इस तरह के सभी कार्यान्वयन का मतलब है कि:

1. फ़ाइल / डीबी में प्रत्येक पंक्ति / रिकॉर्ड के लिए, फ़ाइल / डीबी (यानी var उपयोगकर्ता = नया उपयोगकर्ता) ({FirstName = 'Test', LastName = 'Test2'}) से रिकॉर्ड के गुण रखने के लिए मेमोरी आवंटित करें।

2. इसके बाद, उदाहरण के लिए, 'ToArray' या मैन्युअल रूप से, ऑब्जेक्ट के संदर्भों को कुछ संग्रह (यानी var users = new List) (); Users.Add (उपयोगकर्ता) में रखा जाता है। तो, यह एक फ़ाइल से प्रत्येक रिकॉर्ड के लिए कुछ मात्रा में मेमोरी आवंटित की जाती है और इसके बारे में भूल नहीं करने के लिए, संदर्भ को कुछ संग्रह में संग्रहीत किया जाता है।

यहाँ एक उदाहरण है:

private static IEnumerable<User> LoadUsers2() { var list = new List<User>(); foreach(var line in File.ReadLines("text.txt")) { var splittedLine = line.Split(';'); list.Add(new User() { FirstName = splittedLine[0], LastName = splittedLine[1] }); } return list; // or return File.ReadLines("text.txt") .Select(line => line.Split(';')) .Select(splittedLine => new User() { FirstName = splittedLine[0], LastName = splittedLine[1] }).ToArray(); }

मेमोरी प्रोफाइलर परिणाम:

वास्तव में इस तरह की तस्वीर मैंने कंटेनर के बंद होने के बाद कंटेनर के रुकने / पुनः लोड होने से पहले हर बार उत्पादन वातावरण में देखी थी।

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

ऐसा लगता है कि यह इस तरह के कार्यान्वयन पर फिर से विचार करने का क्षण है। अगली धारणा से हमें सेवा के लिए पदचिह्न की गणना करने के अधिक अवसर मिल सकते हैं: "पदचिह्न को फ़ाइल में केवल एक रिकॉर्ड के आकार पर निर्भर होना चाहिए"। मोटे तौर पर, इस मामले में, हम केवल एक रिकॉर्ड के प्रत्येक कॉलम के अधिकतम आकार की गणना कर सकते हैं और उन्हें योग कर सकते हैं। फ़ाइल में रिकॉर्ड की संख्या की भविष्यवाणी के बजाय रिकॉर्ड के आकार की भविष्यवाणी करना काफी आसान है।

और यह वास्तव में आश्चर्य है कि हम एक ऐसी सेवा को लागू कर सकते हैं जो अप्रत्याशित मात्रा में रिकॉर्ड को संभाल सकती है और लगातार केवल एक कीवर्ड की मदद से मेगाबाइट के एक जोड़े का उपभोग करती है - * उपज '*।

एक उदाहरण के लिए समय:

 class Program { static void Main(string[] args) { // 1. Load byline a set of records from a file or DB into memory. var users = LoadUsers(); // 2. For each column of the record change the value to someone other value. users = ModifyFirstName(users); // 3. Save the results of transformation into a file or DB. SaveUsers(users); } private static IEnumerable<User> LoadUsers() { foreach(var line in File.ReadLines("text.txt")) { var splitedLine = line.Split(';'); yield return new User() { FirstName = splitedLine[0], LastName = splitedLine[1] }; } } private static IEnumerable<User> ModifyFirstName(IEnumerable<User> users) { foreach (var user in users) { user.FirstName += "_1"; yield return user; } } private static void SaveUsers(IEnumerable<User> users) { foreach(var user in users) { File.AppendAllLines("results.txt", new string []{ user.FirstName + ';' + user.LastName }); } } private class User { public string FirstName { get; set; } public string LastName { get; set; } } }

जैसा कि आप ऊपर के उदाहरण में देख सकते हैं, एक समय में केवल एक ही वस्तु के लिए मेमोरी आवंटित की गई है: 'यील्ड रिटर्न न्यू यूजर ()' एक संग्रह बनाने के बजाय इसे ऑब्जेक्ट्स से भरता है। यह अनुकूलन का मुख्य बिंदु है जो हमें सेवा के लिए अधिक पूर्वानुमान योग्य स्मृति पदचिह्न की गणना करने की अनुमति देता है। क्योंकि हमें केवल दो क्षेत्रों का आकार जानने की जरूरत है, हमारे मामले में FirstName और LastName। जब एक संशोधित उपयोगकर्ता फ़ाइल में सहेजा जाता है (देखें File.AppendAllLines), कचरा संग्रहण के लिए उपयोगकर्ता ऑब्जेक्ट का उदाहरण उपलब्ध है। और जो ऑब्जेक्ट द्वारा कब्जा कर लिया गया है मेमोरी को डीलॉकेट किया जाता है (यानी लोडयूजर में 'फ़ॉरवर्ड' स्टेटमेंट का अगला पुनरावृत्ति), इसलिए उपयोगकर्ता ऑब्जेक्ट का अगला उदाहरण बनाया जा सकता है। दूसरे शब्दों में, मोटे तौर पर प्रत्येक पुनरावृत्ति पर स्मृति की समान मात्रा स्मृति द्वारा समान होती है। यही कारण है कि हमें फ़ाइल में एकल रिकॉर्ड के आकार से अधिक मेमोरी की आवश्यकता नहीं है।

अनुकूलन के बाद मेमोरी प्रोफाइलर परिणाम:

एक अन्य दृष्टिकोण से, यदि हम ऊपर कार्यान्वयन में कुछ तरीकों का नाम बदल देते हैं, ताकि उपयोग MVC के आवेदन में नियंत्रकों के लिए कुछ सार्थक तर्क नोटिस कर सकें:

 private static void GetUsersAction() { // 1. Load byline a set of records from a file or DB into memory. var users = LoadUsers(); // 2. For each column of the record change the value to someone other value. var usersDTOs = MapToDTO(users); // 3. Save the results of transformation into a file or DB. OkResult(usersDTOs); }

कोड लिस्टिंग से पहले एक महत्वपूर्ण नोट: EntityFramework, ASP.net MVC, AutoMapper, Dapper, NHibernate, ADO.net और आदि जैसे अधिकांश महत्वपूर्ण पुस्तकालय IEnumerables स्रोतों को उजागर / खपत करते हैं। तो, इसका मतलब है कि ऊपर दिए गए उदाहरण में लोडयूजर को एक कार्यान्वयन द्वारा प्रतिस्थापित किया जा सकता है जो उदाहरण के लिए EntityFramework का उपयोग करता है। जो फाइल के बजाय DB तालिका से पंक्ति द्वारा डेटा पंक्ति को लोड करता है। MapToDTO को ऑटोमेकर द्वारा बदला जा सकता है और OkResult को कुछ MVC फ्रेमवर्क में IActionResult के 'वास्तविक' कार्यान्वयन द्वारा प्रतिस्थापित किया जा सकता है या उदाहरण के लिए नेटवर्क स्ट्रीम पर हमारा स्वयं का कार्यान्वयन आधार:

 private static void OkResult(IEnumerable<User> users) { // you can use a networksteam implementation using(StreamWriter sw = new StreamWriter("result.txt")) { foreach(var user in users) { sw.WriteLine(user.FirstName + ';' + user.LastName); } } }

यह 'mvc-like' उदाहरण हमें दिखाता है कि हम अभी भी वेब-एप्लिकेशन के लिए मेमोरी फुटप्रिंट की भविष्यवाणी और गणना करने में सक्षम हैं। लेकिन इस मामले में, यह अनुरोधों की गिनती पर भी निर्भर करेगा। उदाहरण के लिए, गैर-कार्यात्मक आवश्यकताएं इस तरह से लग सकती हैं: "1000 अनुरोध के लिए अधिकतम मेमोरी राशि तब अधिक नहीं: 200KB प्रति उपयोगकर्ता ऑब्जेक्ट x 1000 अनुरोध ~ 200MB।"

इस तरह की गणना वेब एप्लिकेशन को स्केल करने के मामले में प्रदर्शन अनुकूलन के लिए बहुत उपयोगी हैं। उदाहरण के लिए, आपको अपने वेब एप्लिकेशन को 100 कंटेनरों / वीएम पर स्केल करना होगा। इसलिए, इस मामले में, यह निर्णय लेने के लिए कि आपको होस्टिंग प्रदाता से कितने संसाधन आवंटित करने चाहिए, इसलिए आप इस तरह सूत्र को समायोजित कर सकते हैं: 200KB प्रति उपयोगकर्ता ऑब्जेक्ट x 1000 अनुरोध x 100VMs ~ 20GB। इसके अलावा, यह अधिकतम मेमोरी है और यह राशि आपके प्रोजेक्ट के बजट के नियंत्रण में है।

मुझे उम्मीद है कि इस लेख की जानकारी उपयोगी होगी और आपकी परियोजनाओं में बहुत सारा पैसा और समय बचाने की अनुमति देगा।

Enumerable: एक व्यावसायिक मूल्य कैसे प्राप्त करें

More articles: