लड़ कैश लाल के साथ पुनर्निर्माण करता है

समस्या का वर्णन

एक औसत अत्यधिक भरी हुई साइट की कल्पना करें। आमतौर पर ऐसी साइटों पर बैकएंड और डीबी के बीच एक कैश लेयर लगाई जाती है। आगंतुकों की संख्या में वृद्धि के साथ, कई उपयोगकर्ताओं द्वारा एक साथ "सड़ा हुआ" कैश बढ़ने की संभावना बढ़ जाती है। यदि ऐसा होता है, तो बैकएंड और डीबी पर लोड बढ़ता है, जो बदले में अनुरोध के प्रसंस्करण समय को बढ़ाता है और एक समान स्थिति की संभावना को बढ़ाता है। यहाँ इस तरह की एक सकारात्मक प्रतिक्रिया प्रणाली है: छोटे लाल कूबड़ कई कैश अपडेट पर "धुंधले" अनुरोध हैं। यह आलेख PHP ( APC बंडल) के उदाहरण ( patch attached ) का उपयोग करके समस्या को हल करने के दृष्टिकोण में से एक का वर्णन करेगा, हालांकि, सैद्धांतिक आधार किसी भी भाषा और कैशिंग सिस्टम पर लागू होता है।

समस्या को हल करने के लिए विकल्प

समस्या को हल करने के लिए कई दृष्टिकोण हो सकते हैं। नीचे प्रस्तावित विधि सिर्फ एक समाधान है। सही दृष्टिकोण, IMHO, व्यस्त तालों का उपयोग करना है, जो कैश को अपडेट करने के लिए केवल एक प्रक्रिया की अनुमति देगा, जबकि बाकी पुराने डेटा देगा। हालांकि, यह समाधान पर्याप्त रूप से तुच्छ नहीं है और ज्यादातर मामलों में (अनुरोधों का एक समान वितरण के साथ) वर्णित समाधान पर्याप्त से अधिक होना चाहिए।

इसके अलावा, मेरे मामले में, कैश के स्तर पर ही RED को लागू करने का निर्णय लिया गया था, हालाँकि इसे आवेदन कोड के अंदर वर्ग / आवरण में लागू किया जा सकता था। इस विधि को इसलिए चुना गया क्योंकि यह PHP कोड में चढ़ने के लिए बहुत आलसी था।

लाल

RED , उर्फ random early detection , random early discard या random early drop - राउटर और शेपर्स में पाए जाने वाले कतार प्रबंधन के लिए एक एल्गोरिथ्म है। इसका भौतिक अर्थ लगभग निम्नलिखित है: जब कतार भरी होती है तो इंतजार करने के बजाय और आपको सब कुछ (टेलड्रॉप) छोड़ना पड़ता है, एक निश्चित सीमा में प्रवेश किया जाता है, जिसके बाद हम कुछ संभाव्यता के साथ पैकेट छोड़ना शुरू करते हैं, संभावना खुद बफ़र में खाली जगह के सीधे आनुपातिक होती है। इसलिए Random Early Drop ।

हमारे मामले में, हम कैश एंट्री ( drop_threshold ) के जीवनकाल के लिए एक निश्चित सीमा का परिचय देंगे, जिसके बाद हम cache miss से अनुरोध पढ़ने के cache miss जारी करने के लिए एक निश्चित संभावना p साथ शुरू करेंगे, जो एप्लिकेशन को डेटा के नवीनतम संस्करण को कैश करने के लिए मजबूर करेगा। इस प्रकार, हम p साथ प्रतिस्पर्धात्मक कैश अपडेट की संख्या कम कर देते हैं।

materiel

गणित यहाँ तीसरी कक्षा के स्तर पर है, इसलिए केवल एक चित्र और एक सूत्र दीजिए:

त्याग

PHP मुझे नहीं पता। मैं सी में रेड इंडियन लिखता हूं।

एपीसी पैच

उत्पादन उपयोग के लिए कोड को PoC की तरह लिखा जाता है। छत से 75% का मूल्य लिया गया था। वास्तविक स्थितियों में, drop_threshold को drop_threshold जाना चाहिए।

सूचकांक: apc_cache.c
================================================== =================
--- apc_cache.c ( संशोधन 320057 )
+++ apc_cache.c ( काम की प्रतिलिपि )
@@ - @ ०५ , ६ + , ०५ , १३ @@
वाष्पशील apc_cache_entry_t * value = NULL;
अहस्ताक्षरित लंबी एच;

+ / * APC-RED PATCH * /
+ const int drop_threshold = 75 ;
+ अहस्ताक्षरित अंतर संभावना = 0 ;
+ int red_cf = 0 ;
+ छोटी बूंद = 0 ;
APC-RED PATCH * का + / * अंत
+
अगर ( apc_cache_busy ( कैश ) )
{
/ * कैश क्लीनअप प्रगति में * /
@@ - 720 , 8 + 727 , 25 @@
जबकि ( * स्लॉट ) {
अगर ( h == ( * स्लॉट ) -> key.h ) &&
मेमॉम्प ( ( * स्लॉट ) -> key.data.user.identifier, strkey, keylen ) ) {
+ / * APC-RED PATCH * /
+ अगर ( ( * स्लॉट ) -> मूल्य-> data.user.ttl ) {
+ red_cf = ( t - ( * स्लॉट ) -> creation_time ) * 100 /
+ ( * स्लॉट ) -> मूल्य-> data.user.ttl;
+ अगर ( red_cf> = 100 ) {
+ ड्रॉप = 1 ;
+ }
+ और अगर ( red_cf <= drop_threshold ) {
+ ड्रॉप = 0 ;
+ }
+ और {
+ संभावना = ( red_cf - drop_threshold ) * 100 / ( 100 - drop_threshold ) ;
+ ड्रॉप = ( आर्क 4 आयामी ( ) % 100 ) <संभावना? 1-0 ;
+ }
+ }
APC-RED PATCH * का + / * अंत
+
/ * यह सुनिश्चित करने के लिए जाँच करें कि यह प्रविष्टि एक कठिन TTL द्वारा समाप्त नहीं हुई है * /
- अगर ( ( * स्लॉट ) -> मूल्य-> data.user.ttl && ( time_t ) ( ( * स्लॉट ) -> सृष्टि_टाइम + ( * स्लॉट ) -> मूल्य-> data.user.ttl ) <t
+ if ( ( * * स्लॉट ) -> value-> data.user.ttl && ( time_t ) ( ( * स्लॉट ) -> सृष्टि_टाइम + ( * स्लॉट ) -> मूल्य-> data.user.ttl ) <t | | ड्रॉप ) {
#if ( USE_READ_LOCKS == 0 )
/ * यह केवल एक मेमोरी-फ्रेंडली ऑप्टिमाइज़ेशन है, अगर हमारे पास राइट-लॉक है
* साथ ही इसे हटाए गए_लिस्ट में दाईं ओर ले जा सकता है। अन्यथा एक सम्मिलित

यह ध्यान में रखते हुए कि यह पैच हब में जाने से पहले कितने पार्स से गुजरा है, यह शायद लागू नहीं होता है, इसलिए यह बेहतर है कि यहां लिंक देने के लिए एक लिंक छोड़ दें: पैच- apc_red.patch

सुंदर पर प्रतिबिंब

यह APC कोड (उदाहरण के लिए, liburcu के माध्यम से) में RCU समर्थन जोड़ने के लायक भी होगा, क्योंकि उच्च भार के तहत इसे rwlock (वैसे, अपेक्षाकृत हाल ही में APC में जोड़ा गया) में चलाना इतना मुश्किल नहीं है। APC ही लंबे समय तक PHP में एम्बेड करने लायक रहा होगा।

आप यह भी सोच सकते हैं कि drop_threshold को कैसे सेट किया drop_threshold क्योंकि drop_threshold जैसी कुछ वैश्विक संरचना के लिए, जिसमें phpbb ऑल-ओवर वैश्विक सेटिंग्स को संग्रहीत करता है और जो प्रत्येक अनुरोध के लिए प्रत्येक उपयोगकर्ता द्वारा खींचा जाता है, यह 50% तक थ्रेशोल्ड सेट करने के लिए समझ में आता है, और उपयोगकर्ता सत्र के लिए, इसके विपरीत , यह "सुविधा" को 100% की सीमा को अक्षम करने के लिए "लायक" है। यदि आप इस विषय के बारे में सोचते हैं, तो आप फिर से नेटवर्क एनालॉग्स की दिशा में देख सकते हैं, उदाहरण के लिए, Adaptive / Active RED (ARED) ।

इसके अलावा, कैश क्षय की समस्या और इसके खिलाफ लड़ाई के बारे में, आप आंद्रेई स्मिरनोव ( स्माइरा ) द्वारा हाई लोड 2008 पर लंबे समय तक लेकिन अभी भी प्रासंगिक रिपोर्ट पढ़ सकते हैं: वेब, कैशिंग और मेमकास्ट