बफर/कैश करने के लिए $ _SESSION का उपयोग MySQL क्वेरी

Question

मैं एक वेबसाइट विकसित कर रहा हूं। वर्तमान में, मैं सस्ता साझा होस्टिंग पर हूँ। लेकिन एक लड़का सपना देख सकता है और मैं पहले से ही सोच रहा हूं कि मेरी साइट पर बड़ी संख्या में उपयोगकर्ताओं के साथ क्या होता है।

आगंतुकों को कभी-कभी डेटाबेस लिखने की आवश्यकता होगी, क्योंकि साइट पर गेम में उनकी प्रगति लॉग है।

मैंने प्रगति लिखकर प्रश्नों को कम करने और अन्य जानकारी $_SESSION चर में रहने के बारे में सोचा। और केवल जब सत्र नष्ट हो जाता है (लॉग आउट, ब्राउज़र बंद या टाइमआउट), मैं डेटाबेस में $_SESSION की सामग्री लिखना चाहता हूं।

सवाल:

1. कि संभव है? सत्र समाप्त होने या ब्राउज़र बंद होने पर सत्र निष्पादित करने का कोई तरीका है?

2. क्या यह कामुक है? क्या कुछ सौ समवर्ती एसक्यूएल प्रश्न साझा सर्वर के लिए एक समस्या होने जा रहे हैं और इनमें से कुछ को कम करने जा रहे बफर के रूप में $_SESSION का उपयोग करने का विचार है।

Answer 1

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

तो ... मैं आपको या तो साझा स्मृति (रैम) कैश सिस्टम जैसे memcache (यदि आपका होस्टर इसे प्रदान करता है) या डिस्क आधारित कैश सिस्टम का उपयोग करने का सुझाव देता है।

वैसे, यदि आपके प्रश्न अनुकूलित हैं, कॉलम सही ढंग से अनुक्रमित हैं, आदि, आपकी साझा होस्टिंग "एक ही समय" में कई प्रश्न ले सकती है।

Answer 2

क्या सत्रों को समय-समय पर या ब्राउज़र बंद करने पर कार्य निष्पादित करने का कोई तरीका है?

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

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

क्या यह कामुक है? कुछ साझा समवर्ती एसक्यूएल प्रश्न पर साझा सर्वर के लिए समस्या होने के लिए जा रहे हैं और इनमें से कुछ को कम करने जा रहे बफर के रूप में $ _SESSION का उपयोग करने का विचार है।

मैं वास्तव में कई कारणों से ऐसा नहीं होगा:

• समय से पहले अनुकूलन (इससे पहले कि आप को मापने के लिए, बस यह न मानें कि यह "बेहतर" हो जाएगा)।
• सत्र कभी कचरा एकत्र नहीं किया जा सकता है; भले ही ऐसा न हो, आप को नियंत्रित नहीं करते हैं जब वे एकत्र किए जाते हैं। यह एक समस्या हो सकती है।
• सत्र में सबकुछ खोने की संभावना है (उदा। सर्वर रीबूट), जिसमें प्लेयर प्रगति शामिल है। खिलाड़ियों को प्रगति खोना पसंद नहीं है।
• उसी उपयोगकर्ता के लिए समवर्ती सत्र असंभव होंगे (जिसका "सहेजा गया डेटा" जीतता है और डेटाबेस तक बना रहता है?)।

विकल्पों के बारे में क्या?

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

किसी भी मामले में, मैं यह सुनिश्चित करके शुरू करता हूं कि डेटाबेस स्वयं को अच्छी तरह से संरचित किया गया है और कोड इस तरह से लिखा गया है कि डेटाबेस पर लोड को कम करता है (केवल एक संपादक में सामान टाइप करके मुफ्त प्रदर्शन)।

इसके बाद, आप केवल पढ़ने के लिए कैशिंग पेश कर सकते हैं: आमतौर पर वहां बहुत सारी चीज़ें होती हैं जिन्हें आपको प्रदर्शित करने की आवश्यकता होती है लेकिन संशोधित करने का इरादा नहीं है। डेटा के लिए "लगभग कभी नहीं" अपडेट हो जाता है, जब भी आपको एक आसान और बहुत प्रभावी सुधार हो सकता है, तो एक सत्र कैश जिसे आप अमान्य करते हैं (आप अमान्यता के संबंध में झूठी सकारात्मक भी हो सकते हैं, जब तक कि वे बहुत अधिक नहीं हैं चीजों की भव्य योजना)।

अंत में, यदि आप एकल अनुरोध के दौरान डेटाबेस से दो बार डेटा खींचने के बारे में चिंतित हैं तो आप प्रति-अनुरोध कैशिंग (चर में) जोड़ सकते हैं।

Answer 3

असल में आप डुप्लिकेट पढ़ने से बचने के लिए $ _SESSION को बफर के रूप में उपयोग कर सकते हैं, यह मेरे लिए एक अच्छा विचार प्रतीत होता है (उस से भी बेहतर memcached), निश्चित रूप से लेखन में देरी के लिए नहीं (यह बहुत जटिल है और इसे संभाला जाना चाहिए डीबी);

आप एक सरल हैश है कि आप में बचाने के इस्तेमाल कर सकते हैं $ _SESSION

$cache = array(); 
$_SESSION['cache'] = $cache; 

तो आप करना है जब एक प्रश्न

if(isset($_SESSION['cache'][$id]){ 
    //you have a cache it 
    $question = $_SESSION['cache'][$id]; 
}else{ 
    //no cache, retrieve your $question and save it in the cache 
    $_SESSION['cache'][$id] = $question ; 
} 

Answer 4

कि sensical है? क्या कुछ सौ समवर्ती एसक्यूएल प्रश्न साझा सर्वर के लिए एक समस्या होने जा रहे हैं और इनमें से कुछ को कम करने जा रहे बफर के रूप में $ _SESSION का उपयोग करने का विचार है।

नहीं। सबसे पहले तो आप कभी पता नहीं क्या एक सत्र के लिए होता (लॉगआउट, स्पष्ट है, जहां एक टाइम-आउट लगभग undetectable है), तो यह किसी भी दर पर एक विश्वसनीय कैशिंग तंत्र नहीं है। यदि ऐसे परिणाम हैं जो आप कुछ अनुरोधों के दौरान कई बार पूछते हैं, जो अक्सर नहीं बदलते हैं, तो उन प्रश्नों के परिणाम को समर्पित कैशिंग तंत्र, जैसे APC, या memcached पर सहेजें।

अब, मैं समझता हूं कि आपका वेबहोस्ट इन कैशिंग सिस्टम प्रदान नहीं करेगा, लेकिन फिर, आप शायद अपनी साइट को अनुकूलित करने के लिए अलग-अलग चीजें कर सकते हैं। शुरुआत करने वालों के लिए, मेरे सबसे जटिल सॉफ्टवेयर उत्पाद (जो काफी जटिल हैं) डेटाबेस प्रति औसतन 6 बार प्रति पृष्ठ क्वेरी करते हैं। यदि परिणाम पुन: प्रयोज्य है, तो मैं कैशिंग का उपयोग करता हूं, जिससे प्रश्नों की संख्या कम हो जाती है।

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

गुड लक, मुझे आशा है कि आपकी साइट है कि एक सफलता का बड़ा आप ऊपर सलाह वास्तव में आवश्यकता होगी हो जाता है;)