2013-01-03 12 views
5

मेरे वेबगैम में उपयोगकर्ता PHP के $ _SESSION में कैश किए गए कुछ खिलाड़ी की जानकारी रखते हैं। प्रत्येक बार जब वे गेम लोड करते हैं तो यह जांचता है कि सत्र मौजूद है, अगर नहीं, तो उन्हें एक MySQL डेटाबेस से प्लेयर जानकारी मिलती है और फिर यह $ _SESSION में संग्रहीत हो जाती है।तेज़ क्या है? File_exist या MySQL क्वेरी?

अब मेरी समस्या यह है कि, यदि खिलाड़ी की जानकारी किसी अन्य प्रक्रिया या प्लेयर द्वारा अपडेट की जाती है तो क्या होगा? वे अन्य प्लेयर के $ _SESSION कैश को अपडेट नहीं कर सकते हैं।

मैं जानता हूँ कि memcached सबसे शायद इस के लिए समाधान है, लेकिन मुझे यकीन है कि अगर मैं कुछ इस तरह के लिए समय लेना चाहिए नहीं कर रहा हूँ। इस के अलावा, $ _SESSION कैश मेरे लिए अच्छा कर रहा है।

  • मैं इसके लिए एक MySQL तालिका बनाने के बारे में सोच रहा था जो हर अनुरोध पर पढ़ता है और यदि खिलाड़ी के लिए रिकॉर्ड है कि यह कैश को दोबारा शुरू करता है।
  • एक अन्य समाधान फ़ाइल के नाम पर प्लेयर की आईडी के साथ निर्देशिका में फ़ाइल बनाना होगा। प्रत्येक अनुरोध PHP file_exist के साथ जांच करेगा यदि उसे कैश साफ़ करना चाहिए या नहीं।

तुम लोग क्या करना होगा? यह हर अनुरोध को निष्पादित करता है इसलिए यह अनुकूलित करने के लिए यह बहुत महत्वपूर्ण है।

+1

डेटाबेस विकल्प के लिए जाना होगा, स्पीड वार एक अच्छी डेटाबेस स्कीमा के साथ अंतर नहीं होगा। लेकिन इसकी गति के बारे में नहीं, इसके बारे में बेहतर प्रबंधन के बारे में –

+0

यदि यह बेहद असाधारण मामला नहीं है, तो आप हमेशा डेटाबेस के लिए जाते हैं। वास्तविक दुनिया में आरएमडीबी शायद फ्लैट फ़ाइल से तेज हो सकता है (यदि डेटा पहले से ही स्मृति या पूर्ण तालिका में लोड किया गया है, तो उपलब्ध स्मृति में फिट हो गया है।) – Dasun

उत्तर

3

अकेले एक डिजाइन दृष्टिकोण से मैं file_exists और निर्देशिका दृष्टिकोण से बचूंगा। निश्चित रूप से 'file_exists' तेज़ है, लेकिन यह अच्छी तरह से स्केल नहीं करेगा ... यदि कोई उपयोग उनके नाम को बदलता है तो क्या होता है?

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

इसके अलावा, न एपीसी या अपने file_exists समाधान एकाधिक लोड संतुलित सर्वरों के लिए पैमाने पर होगा - you'd कि के लिए एक डीबी समाधान या memcached की जरूरत है।

+0

उनके मुखपृष्ठ से: "कैश के लिए एपीसी का उपयोग करें जो अक्सर नहीं बदलता", खिलाड़ी की जानकारी वास्तव में बहुत कुछ बदलता है क्योंकि इसमें प्लेयर से गेम आंकड़े भी शामिल होते हैं। क्या यह अभी भी उपयोगी होगा? – Martin

+1

@ मार्टिन आप एपीसी में उपयोगकर्ता कैशिंग में भारी परिवर्तन के साथ विखंडन के मुद्दों में भाग सकते हैं।उस स्थिति में, आप सबसे अच्छी शर्त मेमकैड हैं। – Ray

+0

आपकी टिप्पणी के लिए धन्यवाद। मैं थोड़ा बेहतर Memcached में देख सकते हैं। – Martin

1

जिस तरह से आप यह अवगत कराया, कितनी तेजी से एक अन्य बनाम है, सत्र दृष्टिकोण अपने संगामिति समस्या के कारण अभी मान्य नहीं है के बारे में नहीं है।

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

1

यदि यह केवल कैश के बारे में है, और आप स्थापित करने के लिए मेम्कैश (घ) चाहते हैं, तो आप स्मृति में एक mysql तालिका के साथ जा सकते हैं। यह memcached के रूप में तेज़ नहीं है, लेकिन अभी भी एक अच्छा समाधान है। और सुनिश्चित करें कि आपकी सभी तालिकाओं पर उचित अनुक्रमणिका बनाएं (शायद यह बेहतर समाधान है, कोई कैश नहीं है, बस इसे अपनी तालिका से चुनें)।

CREATE TABLE t (i INT) ENGINE = MEMORY; 
संबंधित मुद्दे