2012-04-23 9 views
5

मैं एक लंबे समय तक 10 एम के हिट/दिन सफलतापूर्वक वेब सेवा के उत्पादन सर्वर पर PHP एपीसी का उपयोग कर रहा हूं।क्या PHP एपीसी स्थानीय ऑब्जेक्ट स्टोर के रूप में भंडारण आकार के अलावा कोई सीमा है?

मैं एपीसी स्थानीय कैश में अधिक डेटा ऑफ़लोड करने पर विचार कर रहा हूं।

सैद्धांतिक रूप से यह मुझे लगता है कि चूंकि एपीसी कॉल मुख्य रूप से स्थानीय स्मृति पहुंच है। इसे 10,000 बार/सेकंड कहने का मुद्दा नहीं बनना चाहिए। जहां तक ​​मैं इसकी सीमा बता सकता हूं स्मृति आकार में हो सकता है लेकिन जब तक सर्वर के पास मुफ्त सीपीयू होता है तो इसमें उच्च दर पर प्रदर्शन या भ्रष्टाचार के मुद्दे नहीं होने चाहिए।

क्या कोई सीमा है जिसके बारे में मुझे पता नहीं है जो मुझे एपीसी के स्थानीय ऑब्जेक्ट कैश को ऐप सर्वर (उबंटू) पर बहुत अधिक दर में उपयोग करने से रोक सकता है।

अद्यतन: स्पष्ट रूप से मेरे प्रश्न के नीचे दिए गए उत्तरों के अनुसार स्पष्ट नहीं था। मैं वैकल्पिक कैशिंग विकल्प (memcache, redis आदि ..) की तलाश नहीं कर रहा हूँ। मेरा सवाल यह है कि स्थानीय एपीसी का उपयोग बहुत अधिक दरों में करने और समरूपता पढ़ने में कोई चिंता या सीमा है या नहीं।

+0

यदि आप बहु-सर्वर वातावरण में हैं तो एक सर्वर के एपीसी कैश को अन्य सर्वर से एक्सेस नहीं किया जा सकता है ... एपीसी को सीएलआई कार्यों –

+0

हां के साथ/साझा नहीं किया जा सकता है। मुझे पता है। इसके लिए मैं द्वितीय स्तर के कैश के रूप में memcached का उपयोग करूंगा ताकि जब कोई नया ऐप सर्वर लांच करता है तो यह डेटा को memcache से पढ़ेगा, न कि डीबी। लेकिन नियमित संचालन के दौरान मुझे जितना संभव हो सके डेटा की आवश्यकता होती है, इसलिए इसे ऐप सर्वर पर डुप्लिकेट किया जाएगा। – Nir

+1

इस सवाल को प्यार करें और एपीसी पूरी तरह से कम्यूटिलाइज्ड कैशिंग परत है। इसके जवाब भी जानना अच्छा लगेगा। – nate

उत्तर

4

मैं व्यक्तिगत रूप से इस तरह के भंडारण के लिए memcached का उपयोग करने का एक बड़ा प्रशंसक हूं। इसमें कई फायदे हैं:

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

एपीसी के उपयोगकर्ता कैश पर memcached का उपयोग करने के कई अन्य फायदे हैं, लेकिन मेरे लिए यह एपीसी के उपयोगकर्ता कैश का उपयोग नहीं करने के प्राथमिक तीन कारण थे। मैं निश्चित रूप से उपयोगकर्ता कैश नहीं, एपीसी का उपयोग करता हूं।

+0

और एक नोट आरई: @ मार्कबेकर की टिप्पणी पर टिप्पणी: memcached ** ** सीएलआई कार्यों के बीच साझा किया जा सकता है, और बहु-सर्वर वातावरण में बहुत उपयोगी है। –

+0

रेडिस भी बेहतर है क्योंकि एकाधिक रेडिस सर्वर संग्रहीत डेटा को दोहराने में सक्षम हो सकते हैं ... इसलिए यदि आप क्लस्टर से एक सर्वर खो देते हैं तो डेटा अभी भी दूसरों में उपलब्ध है .... प्लस यह जी-व्हिज तेज़ –

+0

है हाय टॉम, मैं उपयोग करता हूं डेटा के हिस्से के लिए memcached। विशिष्ट डेटा के लिए जो मैं जोड़ना चाहता हूं, मुझे memcache की तुलना में कुछ तेज़ चाहिए। मैं इस विशिष्ट डेटा के लिए मेमकेचे का उपयोग दूसरे चरण बफर के रूप में करने की योजना बना रहा हूं, इसलिए यदि एपीसी मेमकैच में नहीं है तो इसकी खोज की जाएगी और यदि वहां नहीं है तो डीबी मारा जाएगा। मुख्य कारण यह है कि जब अतिरिक्त ऐप सर्वर लॉन्च हो जाते हैं, तो मैं इस विशिष्ट डेटा के लिए डीबी को हिट नहीं करना चाहता हूं। – Nir