2011-06-22 4 views
5

मैं एक ऑनलाइन दुकान & बना रहा हूं MYSQL क्वेरी को कम करके प्रदर्शन में सुधार करने की कोशिश कर रहा हूं।PHP - क्या यह txt फ़ाइल में MYSQL क्वेरी को कैश करने का अच्छा अभ्यास है?

क्या यह txt फ़ाइल के माध्यम से mysql क्वेरी को कैश करने और फिर क्वेरी के बजाय इसे लाने का अच्छा अभ्यास है? यह है कि मैं क्या "कर रहा हूँ

  1. एक php वर्ग स्ट्रिंग के रूप एसक्यूएल क्वेरी लेता है
  2. करता है इसके बारे में एक md5
  3. अगर यह पहली बार यह
  4. फिर क्वेरी प्रदर्शन चलाए है डेटाबेस पर
  5. प्राप्त एक सरणी
  6. में परिणाम सरणी को क्रमानुसार और md5_Of_Query.txt के रूप में संग्रहीत
  7. वापसी या तो unserialize (file_get_contents (md5_of_Query.txt)) या $ रेस वास्तविक क्वेरी के ults, कैश मौजूद है या नहीं, इस पर निर्भर करता है।
  8. कक्षा txt फ़ाइल के filemtime() को भी जांचती है और यदि यह एक घंटे पुरानी कहती है, तो क्वेरी को दोबारा निष्पादित करें और कैश को रीफ्रेश करें।

क्या यह हर बार एसक्यूएल प्रश्न करने से अधिक कुशल है? कोई सुरक्षा समस्या मुझे याद आ रही है?

उत्तर

5

तुम सिर्फ आवेदन शुरू कर रहे हैं, तो मेम्कैश पाठ फ़ाइलों का उपयोग करने से जाने के लिए एक बहुत तेजी से रास्ता है।

http://memcached.org/

पाठ फ़ाइलें काम करेगा, और कदम हैं जो आप समझ रेखांकित किया है, लेकिन मेम्कैश तेजी से हो सकता है और आप के लिए भारी उठाने का एक बहुत संभाल लेंगे।

+0

धन्यवाद एक बहुत, मिल गया मेम्कैश मेरे WAMP सर्वर पर स्थापित है, अब इस कैश का उपयोग कर का निर्माण करेगा। – Emmanuel

+0

एक ही WAMP पर यह अंतर नहीं कर सकता है, विंडोज़ पर टेक्स्ट फ़ाइल का उपयोग ** पहले से ही ** मेमोरी में कैश किया गया है। Memcached ओवरहेड जोड़ता है और ** स्मृति चुराता है ** वेब सर्वर और डीबी के लिए और अधिक उपयोग होगा। Memcached का मतलब है * बहुत * ** अधिक ** बड़े परिदृश्यों के लिए। * बड़े * सर्वर खेतों और * पूल * कैशिंग सर्वर के प्रश्नों और सबक्वायरी का उत्तर देने के साथ। उस परिदृश्य में memcached (जो ** ** सॉकेट ** पर मेमोरी ट्रॉफ़ एक बहुत ** टेक्स्टुअल प्रोटोकॉल ** पूछताछ करता है) संसाधनों के समृद्ध अनावश्यकता से प्रदर्शन का सबसे अच्छा प्रदर्शन कर सकता है। एकल मशीनों से इसका कोई फायदा नहीं हो सकता है। – ZJR

+0

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

2

आपकी विधि एक कोने से दूसरे को समस्या को स्थानांतरित करने की तरह दिखती है।

कैश पेश करना MySQL प्रदर्शन में सुधार नहीं कर रहा है। बेहतर देखो कि कौन से प्रश्न वास्तव में धीमे होते हैं और फिर प्रश्नों को अनुकूलित करते हैं।

http://dev.mysql.com/doc/refman/5.1/en/slow-query-log.html

8

यदि आप एक बेंचमार्क करते हैं, तो एक अद्वितीय हैश बनाने और डिस्क पर आईओ प्रदर्शन करने की लागत केवल MySQL सर्वर से प्राप्त करने से अधिक होगी।

आईएमएचओ, इस सीमा तक जाने से परेशान मत हो। अच्छे विचार, लेकिन MySQL में पहले से ही आंतरिक कैशिंग और प्रदर्शन ट्विक है।

अपने आवेदन के निर्माण पर ध्यान केंद्रित करें, क्योंकि "समयपूर्व अनुकूलन सभी बुराइयों की जड़ है"।

+0

धन्यवाद। आपने मुझे अपनी सलाह के साथ बहुत परीक्षण और त्रुटि बचाई है। – Emmanuel

2

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

  1. मूल पृष्ठ क्वेरी चलाने की जरूरत है
  2. यह यूआरएल
  3. एक php में स्थित लिपि में क्वेरी पैरामीटर के रूप में पैरामीटर प्रदान करने के सेवा यूआरएल के लिए एक http GET अनुरोध उत्पन्न करता है URL क्वेरी के लिए पैरामीटर स्वीकार करता है, उन्हें मान्य करता है, और उन्हें ने MySQL क्वेरी
  4. स्क्रिप्ट में जोड़ता है डेटाबेस
  5. स्क्रिप्ट परिणाम serializes और उत्पादन के रूप में यह सेट
  6. वेब रों पर क्वेरी चलाता है erver अनुरोध के लिए प्रतिक्रिया कैश और उसी यूआरएल
  7. मूल पृष्ठ सेवा से धारावाहिक परिणाम का उपयोग करता है एचटीएमएल

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

1

बस मेरे दो सेंट में वजन करना चाहता था, सीरियलवार्म और थेप्पी डेवलपर ने यह तथ्य साझा किया कि मेमोरी/रैम किसी भी डिस्क IO बाध्य ऑपरेशन से कहीं अधिक तेज़ है। जितना राम आप mysql के लिए कर सकते हैं और आपको कैश प्रबंधन से निपटने की आवश्यकता नहीं होगी जबतक कि आपको वास्तव में क्लस्टर में अपग्रेड करने की आवश्यकता नहीं होती है, और इसके लिए अन्य विचारों की आवश्यकता होती है। मेमचेचे आपको कैश प्रबंधन पर अधिक नियंत्रण देता है और इसके परिणामस्वरूप आपको अधिक कोडिंग करने की आवश्यकता होती है।

मैं ऐप बनाने से शुरू करूंगा, फिर तनाव का परीक्षण करूँगा और प्रश्नों को अनुकूलित कर सकता हूं, और/या आवश्यकतानुसार कैश प्रबंधन जोड़ सकता हूं।

0

क्या आपने MySQL के query cache को कॉन्फ़िगर किया है?

1

दो चीजें 2 देखें, benchmarking और profiling। आपके द्वारा उपयोग की जाने वाली एकमात्र तरीके से तुलनात्मक रूप से तुलना करने की एकमात्र तरीका है, इन मौजूदा डिस्प्लेन्स के 2 मीट्रिक का उपयोग करके, वर्तमान में उपयोग की गई MySQL कॉन्फ़िगरेशन, php.ini, httpd.conf, .htaccess, mod rewrite stuff और कई अन्य सामान का उपयोग करके बेंचमार्किंग और प्रोफाइलिंग होगी कार्य करने वाली अभिनय प्रौद्योगिकियां।

1

यह गैरकानूनी है, आपको परिणाम कैश करना चाहिए।

क्वेरी असेंबली समय बहुत नगण्य होना चाहिए। (यदि ऐसा नहीं है, तो आप एसक्यूएल का उपयोग नहीं कर के रूप में यह चाहिए था,, पैदा करने के बजाय कर रहे हैं, धाराओं बेवकूफ select रों जहां एक स्मार्ट join हल होता की) डिस्क से

लोड हो रहा है क्वेरी जाहिर है चीजों को धीमा करने के लिए प्रवण।
(ओएस, कैशिंग किया जा सकता है डिस्क आईओ हालांकि, और यह मुश्किल को पहचानना बनाने)

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

संबंधित मुद्दे