क्या कैशिंग हमेशा प्रदर्शन को बढ़ाती है?

Question

मेरे पास PHP और MySQL के साथ कई साइटें हैं, विशेष रूप से मीडियाविकि चल रही हैं, और मुझे प्रदर्शन को बढ़ाने की आवश्यकता है। हालांकि, मेरे पास केवल सीपीयू का सीमित प्रतिशत है जिसे मुझे उपयोग करने की अनुमति है।

प्रदर्शन में सुधार करने के बारे में मैं सोच सकता हूं कि सबसे अच्छी चीज कैशिंग को सक्षम करना है। हालांकि, मैं उलझन में हूं: क्या यह वास्तव में प्रदर्शन को समग्र रूप से बढ़ाता है या बस गति को बढ़ाता है?

क्या मैं सोच सकता हूं कि यदि कैशिंग फाइलों का उपयोग करेगी, तो इन फ़ाइलों की सामग्री प्राप्त करने के लिए और अधिक प्रोसेसिंग होगी। यदि यह SQL टेबल का उपयोग करेगा, तो यह इन तालिकाओं को क्वेरी करने के लिए और अधिक प्रोसेसिंग करेगा, शायद समय छोटा होगा, लेकिन CPU उपयोग अधिक होगा।

क्या यह सही है या नहीं? कैशिंग एक तेज परिणाम देने के लिए अधिक CPU का उपभोग करता है या यह समग्र रूप से प्रदर्शन में सुधार करता है?

Answer 1

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

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

सबसे पहले, आपको अपने डेटाबेस डिज़ाइन और दूसरी बार अपने प्रश्नों को देखने की आवश्यकता है। उदाहरण के लिए आप normalizing your database correctly हैं, जब आप केवल संग्रहित कर सकते हैं, तो बड़ी मात्रा में डेटा के माध्यम से आपके प्रश्न पूछे जा रहे हैं, क्या आप गैर-अनुक्रमित फ़ील्ड पर टेबल में शामिल हो रहे हैं, क्या आपके क्लॉज फ़ील्ड से पूछताछ कर रहे हैं जिन्हें अनुक्रमणित किया जा सकता है (IN इन मामलों में कण खराब है) ।

मैं आपको query analyzer पकड़ने की सलाह देता हूं और अधिक कठोर परिवर्तनों को देखने से पहले उस बोतल की गर्दन को खोजने के लिए अपनी तालिका संरचना और प्रश्नों को अनुकूलित करने में कुछ समय व्यतीत करता हूं।

Answer 2

आपको अपनी प्रकृति को प्रोफ़ाइल करने और पता लगाने की आवश्यकता है कि बोतल गर्दन कहाँ हो रही है। कैशिंग पेज लोड का सबसे अच्छा प्रकार है, यह वह है जो सर्वर को बिल्कुल नहीं दबाता है। आप एक बहुत ही सरल कैशिंग सिस्टम बना सकते हैं जो केवल 15 मिनट की जानकारी को पुनः लोड करता है। इसलिए, यदि पृष्ठ पिछले 15 मिनट में कैश किया गया था तो यह उन्हें एक पूर्व-प्रस्तुत पृष्ठ देता है। पृष्ठ एक बार लोड किया गया, यह एक अस्थायी फ़ाइल बनाता है। हर 15 मिनट में आप एक नया बनाते हैं (यदि कोई उस पृष्ठ को लोड करता है)।

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

Answer 3

संदर्भ: http://msdn.microsoft.com/en-us/library/ee817646.aspx

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

स्केलेबिलिटी: एक ही डेटा, व्यवसाय कार्यक्षमता, और उपयोगकर्ता इंटरफ़ेस टुकड़े अक्सर एप्लिकेशन में कई उपयोगकर्ताओं और प्रक्रियाओं द्वारा आवश्यक होते हैं। यदि यह जानकारी प्रत्येक अनुरोध के लिए संसाधित की जाती है, तो मूल्यवान संसाधनों को उसी आउटपुट को दोबारा बर्बाद कर दिया जाता है। इसके बजाय, आप परिणाम को कैश में स्टोर कर सकते हैं और प्रत्येक अनुरोध के लिए उनका पुन: उपयोग कर सकते हैं। इससे आपके आवेदन की स्केलेबिलिटी में सुधार होता है क्योंकि उपयोगकर्ता आधार बढ़ता है, इन कार्यों के लिए सर्वर संसाधनों की मांग स्थिर बनी हुई है। उदाहरण के लिए, वेब अनुप्रयोग में वेब सर्वर को प्रत्येक उपयोगकर्ता अनुरोध के लिए उपयोगकर्ता इंटरफ़ेस प्रस्तुत करने की आवश्यकता होती है। आप भविष्य में अनुरोधों के लिए उपयोग किए जाने वाले एएसपी.NET आउटपुट कैश में प्रस्तुत पृष्ठ को कैश कर सकते हैं, संसाधनों को अन्य उद्देश्यों के लिए उपयोग करने के लिए मुक्त कर सकते हैं।

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

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

Answer 4

आप 'प्रदर्शन' और 'गति' शब्द का उपयोग करते हैं। मुझे लगता है कि 'प्रदर्शन' आपके वेब सर्वर पर सीपीयू चक्र से संबंधित है और यह कि 'गति' उपयोगकर्ता को पृष्ठ की सेवा करने के लिए लगने वाले समय से संबंधित है। आप 'गति' को अधिकतम करने के दौरान वेब सर्वर 'प्रदर्शन' (पृष्ठों की सेवा के लिए आवश्यक CPU चक्रों की कुल संख्या को कम करके) को अधिकतम करना चाहते हैं (वेब ​​पेज की सेवा करने में लगने वाले समय को कम करना)।

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

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

Answer 5

"प्रदर्शन को बढ़ाने" ईमेल मुझे मिलता है में से कुछ की तरह लगता है ...

वहाँ दो, परस्पर चीजें हैं जो यहां हो रहे हैं। एक "दिए गए अनुरोध को पूरा करने में कितना समय लगता है?", और दूसरा यह है कि "मेरे सीमित संसाधनों को समवर्ती रूप से मैं कितने अनुरोध कर सकता हूं?"। प्रदर्शन के बारे में बात करते समय लोग या तो दोनों अवधारणाओं का उपयोग करते हैं।

कैशिंग उन दोनों चीजों के साथ मदद कर सकता है।

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

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

यदि यह संभव नहीं है, तो आप कुछ डेटाबेस प्रश्नों के परिणाम को कैश करने में सक्षम हो सकते हैं। इससे डेटाबेस लोड को कम करने में मदद मिलती है, और आमतौर पर आपके वेब सर्वर पर लोड भी कम हो जाता है - डेटाबेस क्वेरी चलाने के लिए आवश्यक कोड और परिणाम से निपटने के लिए आमतौर पर अधिक कठिन होता है जो आइटम को कैश से पुनर्प्राप्त करता है; क्योंकि यह तेज़ है, यह आपके अनुरोध को तेज़ी से संभालने की अनुमति देता है, जो संसाधनों को और अधिक तेज़ी से मुक्त करता है। इससे व्यक्तिगत अनुरोध के लिए आपके सर्वर पर लोड कम हो जाता है, और इस प्रकार आप अधिक समवर्ती अनुरोधों की सेवा कर सकते हैं।