C ++ में ऑब्जेक्ट्स को अक्सर बनाने और हटाने की समस्या

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

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

प्रॉक्सी को उलट दें

आइए, रिवर्स प्रॉक्सिंग पर जाएं और देखें कि आप इसे C ++ में कैसे लागू कर सकते हैं और कैसे बढ़ा सकते हैं। सबसे पहले, हमें सर्वर और क्लाइंट सेशन नामक दो ऑब्जेक्ट चाहिए। सर्वर सत्र ब्राउज़र के साथ संबंध स्थापित करता है और बनाए रखता है; ग्राहक सत्र सेवा के साथ संबंध स्थापित करता है और बनाए रखता है। आपको एक स्ट्रीम बफर की भी आवश्यकता होगी जो काम को अंदर मेमोरी के साथ एनकैप्सुलेट करता है, जिसमें सर्वर सत्र सॉकेट से पढ़ता है और जिसमें से क्लाइंट सत्र सॉकेट को लिखता है। सर्वर और क्लाइंट सत्र के उदाहरण बूस्ट.आसियो के लिए प्रलेखन में पाए जा सकते हैं। स्ट्रीम बफर के साथ कैसे काम किया जाए, वहां पाया जा सकता है।

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

हम किस तरह की मेमोरी कॉपी कर रहे हैं? तथ्य यह है कि फ़िल्टर करते समय, ट्रैफ़िक हमेशा अपरिवर्तित नहीं होता है। नीचे दिए गए उदाहरण को देखें: इसमें हम एक हेडर को हटाते हैं और इसके बजाय दो जोड़ते हैं। उपयोगकर्ता क्वेरी की संख्या जिस पर समान कार्य किए जाते हैं, सेवा के अंदर तर्क की जटिलता के साथ बढ़ जाती है। किसी भी स्थिति में आप ऐसे मामलों में डेटा की नकल नहीं कर सकते! यदि कुल अनुरोध का केवल 1% बदलता है, और 99% अपरिवर्तित रहते हैं, तो आपको केवल 1% के लिए नई मेमोरी आवंटित करनी चाहिए। यह आपको इस बढ़ावा के साथ मदद करेगा :: asio :: const_buffer और boost :: asio :: mutable_buffer, जिसकी मदद से आप एक इकाई के साथ मेमोरी के कई निरंतर ब्लॉकों का प्रतिनिधित्व कर सकते हैं।

उपयोगकर्ता अनुरोध:

Browser -> Proxy: > POST / HTTP/1.1 > User-Agent: curl/7.29.0 > Host: 127.0.0.1:50080 > Accept: */* > Content-Length: 5888903 > Content-Type: application/x-www-form-urlencoded > ... Proxy -> Service: > POST / HTTP/1.1 > User-Agent: curl/7.29.0 > Host: 127.0.0.1:50080 > Accept: */* > Transfer-Encoding: chunked > Content-Type: application/x-www-form-urlencoded > Expect: 100-continue > ... Service -> Proxy: < HTTP/1.1 200 OK Proxy -> Browser < HTTP/1.1 200 OK 

समस्या

नतीजतन, हमें एक तैयार-तैयार एप्लिकेशन मिला जो अच्छी तरह से स्केल कर सकता है और सभी प्रकार के अनुकूलन के साथ संपन्न है। इसे प्रोडक्शन में लॉन्च करके, हम इस बात से काफी खुश थे कि इसने कितने समय तक अच्छा काम किया है।

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

एम्पलीफायर का स्क्रीनशॉट (वोस्लैब):



स्क्रीनशॉट में, ऑपरेटर नए ने 67 सेकंड काम किया, और ऑपरेटर ने और भी अधिक - 97 सेकंड हटा दिए।

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

स्लैब वितरण का विचार नया नहीं है। यह आविष्कार किया गया था और सोलारिस में लागू किया गया था, बाद में लिनक्स कर्नेल में स्थानांतरित हो गया, और इस तथ्य में शामिल है कि अक्सर एक ही प्रकार की वस्तुओं का उपयोग पूल में स्टोर करना आसान होता है। हमें जरूरत पड़ने पर हम पूल से ही वस्तु लेते हैं और काम पूरा होने पर हम उसे वापस लौटा देते हैं। ऑपरेटर नए और ऑपरेटर को हटाने के लिए कोई कॉल नहीं! इसके अलावा, प्रारंभ का एक न्यूनतम। स्लैब कोर में, वितरण का उपयोग सेमाफोर, फ़ाइल डिस्क्रिप्टर, प्रक्रियाओं और थ्रेड्स के लिए किया जाता है। हमारे मामले में, यह सर्वर और क्लाइंट सत्रों पर पूरी तरह से गिर गया, साथ ही साथ सब कुछ जो उनके अंदर है।

चार्ट (स्लैब वितरण):



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

• छोटा :: आवंटनकर्ता
• छोटा :: slab_cache (स्थानीय स्थानीय)
• छोटा :: स्लैब
• छोटा :: अखाड़ा
• छोटा :: कोटा

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

लपेटना

लिबस्मॉल लाइब्रेरी C में लिखी गई है, C ++ में नहीं, इसलिए हमें मानक C ++ लाइब्रेरी में पारदर्शी एकीकरण के लिए कई आवरण विकसित करने पड़े।

• variti :: slab_allocator
• variti :: स्लैब
• variti :: thread_local_slab
• variti :: slab_allocate_sared

Variti :: slab_allocator वर्ग न्यूनतम आवश्यकताओं को लागू करता है जो मानक द्वारा निर्धारित किए जाते हैं जब वह स्वयं को आवंटित करता है। अंदर वारिटी :: स्लैब क्लासेस, लिबासामल लाइब्रेरी के साथ सभी काम समझाया जाता है। वेराइटी :: थ्रेड_लोकल_स्लैब की आवश्यकता क्यों है? तथ्य यह है कि वितरण स्लैब कैश थ्रेड स्थानीय ऑब्जेक्ट हैं। इसका मतलब है कि प्रत्येक थ्रेड में कैश का अपना सेट होता है। यह एक नई वस्तु को वितरित करते समय अवरुद्ध कार्यों की संख्या को शून्य करने के लिए किया जाता है। इसलिए, प्रत्येक थ्रेड की स्मृति में, हम अपने उदाहरण को variti :: स्लैब क्लास में रखते हैं, और उस तक पहुँच को variti :: thread_local_slab आवरण का उपयोग करके विनियमित किया जाता है। मैं आपको टेम्पलेट फंक्शन variti :: slab_allocate_sared के बारे में बताऊंगा।

वेराइटी के अंदर :: slab_allocator वर्ग, सब कुछ काफी सरल है। उसके पास एक प्रकार से दूसरे प्रकार तक विद्रोह करने की क्षमता है, उदाहरण के लिए, शून्य से चार तक। दिलचस्प है, आप nullptr की व्यापकता पर ध्यान दे सकते हैं अपवाद std :: bad_alloc मामले में जब मेमोरी वितरण स्लैब से बाहर निकलती है। बाकी वैराइटी :: थ्रेड_लोकल_स्लैब रैपर के अंदर कॉल फॉरवर्ड कर रहा है।

स्निपेट (slab_allocator.hpp):

 template <typename T> class slab_allocator { public: using value_type = T; using pointer = value_type*; using const_pointer = const value_type*; using reference = value_type&; using const_reference = const value_type&; template <typename U> struct rebind { using other = slab_allocator<U>; }; slab_allocator() {} template <typename U> slab_allocator(const slab_allocator<U>& other) {} T* allocate(size_t n, const void* = nullptr) { auto p = static_cast<T*>(thread_local_slab::allocate(sizeof(T) * n)); if (!p && n) throw std::bad_alloc(); return p; } void deallocate(T* p, size_t n) { thread_local_slab::deallocate(p, sizeof(T) * n); } }; template <> class slab_allocator<void> { public: using value_type = void; using pointer = void*; using const_pointer = const void*; template <typename U> struct rebind { typedef slab_allocator<U> other; }; }; 

आइए देखें कि कंस्ट्रक्टर और डिस्ट्रक्टर वेरिटी :: स्लैब कैसे लागू किया जाता है। कंस्ट्रक्टर में, हम सभी वस्तुओं के लिए मेमोरी के 1 GiB से अधिक कुल आवंटित करते हैं। हमारे मामले में प्रत्येक पूल का आकार 1 MiB से अधिक नहीं है। न्यूनतम वस्तु जिसे हम वितरित कर सकते हैं वह आकार में 2 बाइट्स है (वास्तव में, लीबस्मॉल इसे न्यूनतम आवश्यक - 8 बाइट्स तक बढ़ा देगा)। हमारे स्लैब वितरण के माध्यम से उपलब्ध शेष वस्तुएं दो में से कई (स्थिर 2.f द्वारा निर्धारित) होंगी। कुल, आप आकार 8, 16, 32, आदि की वस्तुओं को वितरित कर सकते हैं। यदि अनुरोधित वस्तु 24 बाइट आकार में है, तो स्मृति से एक ओवरहेड होगा। वितरण इस ऑब्जेक्ट को आपके पास लौटा देगा, लेकिन इसे एक पूल में रखा जाएगा जो आकार में 32 बाइट्स के ऑब्जेक्ट से मेल खाती है। शेष 8 बाइट्स बेकार हो जाएंगे।

स्निपेट (slab.hpp):

 inline void* phys_to_virt_p(void* p) { return reinterpret_cast<char*>(p) + sizeof(std::thread::id); } inline size_t phys_to_virt_n(size_t n) { return n - sizeof(std::thread::id); } inline void* virt_to_phys_p(void* p) { return reinterpret_cast<char*>(p) - sizeof(std::thread::id); } inline size_t virt_to_phys_n(size_t n) { return n + sizeof(std::thread::id); } inline std::thread::id& phys_thread_id(void* p) { return *reinterpret_cast<std::thread::id*>(p); } class slab : public noncopyable { public: slab() { small::quota_init(& quota_, 1024 * 1024 * 1024); small::slab_arena_create(&arena_, & quota_, 0, 1024 * 1024, MAP_PRIVATE); small::slab_cache_create(&cache_, &arena_); small::allocator_create(&allocator_, &cache_, 2, 2.f); } ~slab() { small::allocator_destroy(&allocator_); small::slab_cache_destroy(&cache_); small::slab_arena_destroy(&arena_); } void* allocate(size_t n) { auto phys_n = virt_to_phys_n(n); auto phys_p = small::malloc(&allocator_, phys_n); if (!phys_p) return nullptr; phys_thread_id(phys_p) = std::this_thread::get_id(); return phys_to_virt_p(phys_p); } void deallocate(const void* p, size_t n) { auto phys_p = virt_to_phys_p(const_cast<void*>(p)); auto phys_n = virt_to_phys_n(n); assert(phys_thread_id(phys_p) == std::this_thread::get_id()); small::free(&allocator_, phys_p, phys_n); } private: small::quota quota_; small::slab_arena arena_; small::slab_cache cache_; small::allocator allocator_; }; 

ये सभी प्रतिबंध एक विशेष उदाहरण के वैराइटी :: स्लैब वर्ग पर लागू होते हैं। चूंकि प्रत्येक थ्रेड का अपना (थ्रेड लोकल के बारे में सोचना) होता है, प्रक्रिया पर कुल सीमा 1 GiB नहीं होगी, लेकिन स्लैब वितरण का उपयोग करने वाले थ्रेड्स की संख्या के लिए सीधे आनुपातिक होगी।

चार्ट (std :: थ्रेड :: id):



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

स्निपेट (थ्रेड_लोकल_स्लैब.हप):

 class thread_local_slab : public noncopyable { public: static void initialize(); static void finalize(); static void* allocate(size_t n); static void deallocate(const void* p, size_t n); }; 

स्निपेट (थ्रेड_लोकल_स्लैब.कैप):

 static thread_local slab* slab_; void thread_local_slab::initialize() { slab_ = new slab(slab_cfg_); } void thread_local_slab::finalize() { delete slab_; } void* thread_local_slab::malloc(size_t n) { return slab_->malloc(n); } void thread_local_slab::free(const void* p, size_t n) { slab_->free(p, n); } 

जब स्ट्रीम पर नियंत्रण खो जाता है (जब विभिन्न आईओई संदर्भों के बीच किसी वस्तु को स्थानांतरित करना), तो एक स्मार्ट पॉइंटर ऑब्जेक्ट के सही रिलीज की अनुमति देता है। वह जो कुछ भी करता है, वह वस्तु को उसके io संदर्भ को याद करते हुए वितरित करता है, और फिर इसे std में लपेटता है :: एक कस्टम विभक्त के साथ साझा किया गया, जो वितरण को वस्तु को तुरंत वापस नहीं करता है, लेकिन इसे पहले सहेजे गए io संदर्भ में करता है। यह अच्छी तरह से काम करता है जब प्रत्येक io संदर्भ एक ही धागे पर चलता है। अन्यथा, दुर्भाग्य से, यह दृष्टिकोण लागू नहीं है।

स्निपेट (slab_helper.hpp):

 template <typename T, typename Allocator, typename... Args> std::shared_ptr<T> slab_allocate_shared(Allocator allocator, Args... args) { T* p = allocator.allocate(1); new ((void*)p) T(std::forward<Args>(args)...); std::shared_ptr<T> ptr(p, [allocator](T* p) { p->~T(); allocator.deallocate(p); }); return ptr; }; template <typename T, typename Allocator, typename... Args> std::shared_ptr<T> slab_allocate_shared(Allocator allocator, boost::asio::io_service* io, Args... args) { T* p = allocator.allocate(1); new ((void*)p) T(std::forward<Args>(args)...); std::shared_ptr<T> ptr(p, [allocator, io](T* p) { io->post([allocator, p]() { p->~T(); allocator.deallocate(p); }); }); return ptr; }; 

निर्णय

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

• variti :: चंक
• variti :: streambuf
• variti :: server_session
• variti :: client_session

उसी समय, अतिरिक्त समस्याओं को हल करना आवश्यक था, अर्थात्: सरल वस्तुओं, समग्र वस्तुओं और संग्रह को स्लैब आवंटनकर्ताओं में स्थानांतरित करना। और अगर वस्तुओं के पहले दो वर्गों के साथ कोई गंभीर कठिनाइयाँ नहीं थीं (समग्र वस्तुओं को सरल लोगों के लिए कम कर दिया जाता है), तो संग्रह का अनुवाद करते समय हम गंभीर कठिनाइयों में भाग गए।

• एसटीडी :: सूची
• std :: deque
• एसटीडी :: वेक्टर
• एसटीडी :: स्ट्रिंग
• एसटीडी :: नक्शा
• std :: unordered_map

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

एसटीडी :: सूची स्लैब के लिए, आवंटनकर्ता महान काम करते हैं। यह संग्रह एक लिंक की गई सूची का उपयोग करके आंतरिक रूप से कार्यान्वित किया जाता है, जिसके प्रत्येक तत्व का एक निश्चित आकार होता है। इस प्रकार, std में नए डेटा के साथ :: स्लैब वितरण में सूची, नई प्रकार की वस्तुएं नहीं दिखाई देती हैं। ऊपर बताई गई शर्त संतुष्ट है! एसटीडी :: मानचित्र समान रूप से व्यवस्थित है। अंतर केवल इतना है कि इसके अंदर एक लिंक की गई सूची नहीं है, बल्कि एक पेड़ है।

Std :: deque के मामले में, चीजें अधिक जटिल हैं। यह संग्रह मेमोरी के एक सन्निहित ब्लॉक के माध्यम से कार्यान्वित किया जाता है जिसमें चोंट करने के लिए पॉइंटर्स होते हैं। जबकि चंक्स बहुत सटीक हैं, std :: deque std :: list के समान व्यवहार करता है, लेकिन जब वे समाप्त होते हैं, तो स्मृति का यह एक ही ब्लॉक पुनर्वितरित होता है। स्लैब आबंटकों के दृष्टिकोण से, प्रत्येक मेमोरी पुनर्वितरण एक नए प्रकार के साथ एक वस्तु है। संग्रह में जोड़ी गई वस्तुओं की संख्या सीधे उपयोगकर्ता पर निर्भर करती है और अनियंत्रित रूप से बढ़ सकती है। यह स्थिति स्वीकार्य नहीं है, इसलिए हम या तो std :: deque का आकार सीमित करते हैं जहाँ यह संभव था, या पसंदीदा std :: सूची।

अगर हम std :: वेक्टर और std :: string लेते हैं, तो वे अभी भी अधिक जटिल हैं। इन संग्रहों का कार्यान्वयन कुछ हद तक std :: deque के समान है, सिवाय इसके कि उनका निरंतर मेमोरी ब्लॉक काफी तेजी से बढ़ता है। हमने std :: वेक्टर और std :: std के साथ स्ट्रिंग :: deque, और std :: सूची के साथ सबसे खराब स्थिति में प्रतिस्थापित किया। हां, हम कार्यक्षमता में खो गए और कहीं न कहीं प्रदर्शन में भी, लेकिन इसने अंतिम तस्वीर को उन अनुकूलन से बहुत कम प्रभावित किया जिनके लिए सब कुछ कल्पना की गई थी।

हमने std :: unordered_map के साथ ठीक वैसा ही किया, स्व-लिखित वैराइटी के पक्ष में इसे छोड़ते हुए :: flat_map को std :: deque के माध्यम से लागू किया गया। उसी समय, हमने बस अलग-अलग चर में अक्सर उपयोग की जाने वाली कुंजियों को कैश किया, उदाहरण के लिए, जैसा कि nginx में http अनुरोध हेडर के साथ किया जाता है।

निष्कर्ष

स्लैब आवंटन के लिए सर्वर और क्लाइंट सत्रों का पूरा हस्तांतरण समाप्त होने के बाद, हमने एक गुच्छा के साथ काम करने में लगने वाले समय को डेढ़ गुना से कम कर दिया।

एम्पलीफायर (कोलडस्लैब) का स्क्रीनशॉट:



स्क्रीनशॉट में, ऑपरेटर नए ने 32 सेकंड काम किया और ऑपरेटर ने 24 सेकंड हटा दिए। इस समय तक, ढेर के साथ काम करने के लिए अन्य कार्य जोड़े गए थे: स्मॉलोक - 21 सेकंड, mslab_alloc - 37 सेकंड, smfree - 8 सेकंड, mslab_free - 21 सेकंड। कुल, 143 सेकंड बनाम 161 सेकंड।

लेकिन स्लैब वितरण में कैश को शुरू किए बिना सेवा शुरू करने के तुरंत बाद ये माप किए गए थे। एक यैंडेक्स-टैंक से बार-बार गोलीबारी के बाद, समग्र तस्वीर में सुधार हुआ।

एम्पलीफायर का स्क्रीनशॉट (hotslab):



स्क्रीनशॉट में, ऑपरेटर नए ने 20 सेकंड, स्मॉलोक - 16 सेकंड, mslab_alloc - 27 सेकंड, ऑपरेटर डिलीट - 16 सेकंड, smfree - 7 सेकंड, mslab_free - 17 सेकंड काम किया। 161 सेकंड के मुकाबले कुल 103 सेकंड।

माप तालिका:

  woslab coldslab hotslab operator new 67s 32s 20s smalloc - 21s 16s mslab_alloc - 37s 27s operator delete 94s 24s 16s smfree - 8s 7s mslab_free - 21s 17s summary 161s 143s 103s 

वास्तविक जीवन में, परिणाम और भी बेहतर होना चाहिए, क्योंकि स्लैब आवंटनकर्ता न केवल लंबी मेमोरी आवंटन और मुक्त होने की समस्या को हल करते हैं, बल्कि विखंडन को भी कम करते हैं। स्लैब के बिना, समय के साथ, ऑपरेटर नए और ऑपरेटर हटाने का संचालन केवल धीमा होना चाहिए। स्लैब के साथ - यह हमेशा एक ही स्तर पर रहेगा।

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

आवेदन

यहाँ स्रोत कोड की जाँच करें !