🎃 🏳️ 🔅 अनपेक्षित कचरा कलेक्टर सत्र व्यवहार 👩🏼‍🏭 🤙🏿 🐀

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

Php में, सत्र के लिए GC के काम के लिए 3 पैरामीटर जिम्मेदार हैं: session.gc_probability , session.gc_divisor और session.gc_maxlifetime ।
ये पैरामीटर निम्न संकेत देते हैं: gc_probability में, gc को gc_divisor सेशन_स्टार्ट से शुरू किया जाता है, जो कि gc_maxlifetime की तुलना में अंतिम एक्सेस समय के साथ सत्र को साफ़ करना चाहिए।

हम सभी के रूप में करते हैं, या उदाहरण नंबर 1

आइए एक छोटी स्क्रिप्ट में GC के काम को परखने की कोशिश करें:

<?php ini_set("session.gc_maxlifetime", 1); session_start(); if (isset($_SESSION['value'])) { $_SESSION['value'] += 1; } else { $_SESSION['value'] = 0; } echo $_SESSION['value']; ?>

हम 10-15 सेकंड के अंतराल के साथ इस फ़ाइल को 10 बार अपडेट करेंगे (यह संभव है और अधिक है, यह महत्वपूर्ण है कि अंतराल दूसरे पांच से अधिक है)। परिणामस्वरूप, हमें "अप्रत्याशित उत्तर" मिलते हैं:

 0 1 2 3 ...

कारण काफी सरल है और, मैं कहूंगा, स्पष्ट:
gc केवल 1000 में से 1 अनुरोध में शुरू होगा, और हमने सिर्फ 15 किया।

नोट: अधिकांश प्रणालियां जो मैंने देखीं, इस एल्गोरिथ्म पर काम कीं और गहरी नहीं हुईं।

बग को हर कीमत पर बाईपास करें, या नंबर 2 का उदाहरण दें

समस्या का समाधान सरल लगता है - लेकिन क्या होगा यदि आप जीसी लॉन्च बल बनाते हैं?

 <?php ini_set("session.gc_maxlifetime", 1); ini_set("session.gc_divisor", 1); ini_set("session.gc_probability", 1); session_start(); if (isset($_SESSION['value'])) { $_SESSION['value'] += 1; } else { $_SESSION['value'] = 0; } echo $_SESSION['value']; ?>

लेकिन इस लिपि का व्यवहार बहुत अधिक अप्रत्याशित हो जाता है। आइए उदाहरण के लिए नंबर 1 के समान कार्यों को दोहराने की कोशिश करें:

 0 1 0 1 ...

डीब्रीफिंग, या ऐसा क्यों होता है

यदि हम session_set_save_handler का उपयोग करके हैंडलर लटकाते हैं, तो हम सत्र लोडिंग / प्रोसेसिंग ऑर्डर को आसानी से बहाल कर सकते हैं:

खुला
पढ़ना
जीसी
कार्यक्रम
पास

यानी कचरा कलेक्टर सत्र को पढ़ने के बाद शुरू हुआ, जिसका अर्थ है कि $ _SESSION सरणी पहले से ही भरी हुई है। यह वह जगह है जहां दूसरे उदाहरण में अप्रत्याशित इकाई से आता है!

1 उदाहरण पर वापस जाएँ

जैसा कि हम अब देखते हैं, कचरा कलेक्टर चरण 3 में शुरू हो सकता है, लेकिन अगर यह शुरू नहीं होता है तो क्या होता है? आखिरकार, मानक सेटिंग्स के साथ, लॉन्च करने का मौका 1000 में से केवल 1 है।
एक पुराना सत्र सफलतापूर्वक खुल जाएगा, पढ़ा जा सकता है, और काम के अंत में इसे सहेजा जाएगा और फ़ाइल तक अंतिम पहुंच का समय अपडेट किया जाएगा - इस मामले में, ऐसा सत्र लगभग अंतहीन हो जाता है। लेकिन, एक ही समय में, यदि हमारी स्क्रिप्ट 1000 विभिन्न उपयोगकर्ताओं का उपयोग करती है, तो आप सत्र के "अनन्तता" के बारे में भूल सकते हैं, क्योंकि जीसी को किसी भी उपयोगकर्ता द्वारा लॉन्च किए जाने की संभावना है, जीवनकाल सही तरीके से काम करना शुरू कर देगा (अधिक सटीक, लगभग सच)। सिस्टम का यह व्यवहार अस्पष्ट और अप्रत्याशित है, और इससे संभावित रूप से बड़ी संख्या में हार्ड-टू-कैच समस्याओं का सामना करना पड़ेगा।

और अब क्या करना है, या स्थिति से बाहर के तरीके

सबसे सुरक्षित समाधान आपके सत्र सत्यापन तंत्र का उपयोग करना है। प्रलेखन स्पष्ट रूप से बताता है कि
“Session.gc_maxlifetime सेकंड में देरी का समय निर्धारित करता है, जिसके बाद डेटा को कचरा माना जाएगा और संभावित रूप से हटा दिया जाएगा। कचरा संग्रह सत्र की शुरुआत के दौरान हो सकता है। उन स्थानों पर जहां सत्र जीवन का समय महत्वपूर्ण है, और कलाकृतियों की घटना, उदाहरण के लिए नंबर 2 महत्वपूर्ण है, अपने जीवन सत्यापन का उपयोग करें।

नंबर 2, खराब और गलत से बाहर निकलें

हम जानते हैं कि जीसी ऑपरेशन का स्थापित "मजबूर मोड" सत्र की शुरुआत के चरण संख्या 3 पर काम करेगा। यानी वास्तव में, एक अप्रचलित सत्र की शुरुआत के बाद, $ _SESSION सरणी में डेटा मौजूद है, और फ़ाइल पहले ही हटा दी गई है। इस मामले में, सत्र को फिर से बनाने की कोशिश करना तर्कसंगत है, अर्थात्, वास्तव में 2 सत्र शुरू करना शुरू होता है:

 <?php ini_set("session.gc_maxlifetime", 1); ini_set("session.gc_divisor", 1); ini_set("session.gc_probability", 1); session_start(); if (isset($_SESSION['value'])) { $_SESSION['value'] += 1; } else { $_SESSION['value'] = 0; } echo $_SESSION['value']; session_commit(); session_start(); echo ' '.$_SESSION['value']; ?>

स्क्रिप्ट के परिणाम होंगे:

 0 0 1 0 0 1 ...

यह व्यवहार सत्र के प्रसंस्करण क्रम से स्पष्ट है, लेकिन (दस्तावेज़ को याद करते हुए, और आमतौर पर पर्याप्त रूप से देखें), यह करने योग्य नहीं है।

हुर्रे, हल - निष्कर्ष

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

अंत तक पढ़ने के लिए आप सभी का धन्यवाद। मुझे उम्मीद है कि आपको यह लेख उपयोगी लगा होगा।

अनपेक्षित कचरा कलेक्टर सत्र व्यवहार