2012-09-27 16 views
7

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

हालांकि, पहली बार गैर-कैश की गई छवि को लोड करने वाली वेबसाइट विज़िटर इस भारी भारी परिवर्तन से प्रभावित होती है।

हम अपनी छवियों को 'प्री-कैश' करने की क्षमता चाहते हैं (प्रत्येक छवि यूआरएल का अनुरोध करने वाले बैच नौकरी का उपयोग करके) ताकि अंतिम उपयोगकर्ता किसी विशेष आकार में छवि को हिट करने वाले पहले व्यक्ति न हों।

दुर्भाग्य से, चूंकि छवियों को केवल पूर्व-कैशिंग सेवा को सौंपा गया एज स्थान पर कैश किया जाता है, इसलिए वेबसाइट विज़िटर को किसी अन्य एज स्थान का उपयोग करके कैश की गई छवि नहीं मिलती है और मूल सर्वर पर भारी आकार बदलने वाली स्क्रिप्ट के साथ हिट होती है।

हम एक CloudFront वितरण कि एक मूल EC2 PHP स्क्रिप्ट के लिए अंक है:

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

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

अब, फ्रांस से एक अनुरोध एक ही छवि का अनुरोध करता है। फ्रांसीसी एज स्थान में इसे कैश नहीं किया गया है, इसलिए यह मूल कहता है, जो आयरलैंड में ईसी 2 मशीन है, जो दूसरे सीएफ वितरण को कॉल करता है जो फिर से आयरिश एज स्थान को हिट करता है। इस बार इसमें छवि कैश्ड है, और इसे तुरंत वापस कर सकते हैं। अब फ्रेंच एज स्थान में भी कैश की गई छवि है, लेकिन इसे 'आकार बदलने' पृष्ठ के बिना - आयरलैंड में कैश की गई छवि के साथ केवल 'स्ट्रीमिंग' पृष्ठ कहा जाता है।

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

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

क्या हमने एक और बेहतर समाधान को अनदेखा किया है? उपरोक्त को कोई टिप्पणी?

उत्तर

1

मुझे यकीन नहीं है कि यह लोडिंग समय को कम करेगा (यदि यह y था हमारा लक्ष्य)।

हां, यह सेटअप कुछ "परिवर्तन समय" बचाएगा लेकिन दूसरी ओर यह सर्वर के बीच एक अतिरिक्त संचार भी बनाएगा।

आईई। क्लाइंट फ्रांसीसी पीओपी कॉल करता है >> फ्रेंच पीओपी कॉल आयरलैंड पीओपी = डाउनलोड समय (और कुछ) जो दो बार "परिवर्तन समय" से अधिक हो सकता है ...

मैं इंकापुला के लिए काम करता हूं और हमने वास्तव में अपना खुद का विकास किया है गतिशील सामग्री कैशिंग को संभालने के लिए हेरिस्टिक प्रक्रिया का विश्लेषण करने वाला एक व्यवहार अद्वितीय है। (संक्षेप में यहाँ प्रलेखित: http://www.incapsula.com/the-incapsula-blog/item/414-advanced-caching-dynamic-through-learning)

हमारे परिसर है: एक वेबसाइट गतिशील वस्तुओं के लाखों हो सकता है

जबकि, केवल उन में से कुछ दोहराया अनुरोध के अधीन हैं।

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

सामग्री को फिर से स्कैन किया जाता है, ताजाता को संरक्षित करने के लिए और हेरिस्टिक सिस्टम ट्रैक रखता है, यह सुनिश्चित करने के लिए कि सामग्री अभी भी लोकप्रिय है।

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

उम्मीद है कि इससे मदद मिलती है।

0

बस एक विचार ...

दो कैश चलाएं।

  1. प्रत्येक किनारे स्थान पर एक,
  2. सर्वर पर एक (या elasticache कई सर्वरों अगर) आयरलैंड में। उन्हें कुछ मिनटों से ज्यादा समय तक कैश करने की आवश्यकता नहीं है।

एक माइक्रो उदाहरण डेटा पाइपलाइन या एक कतार से जुड़ी चल रहा है,

अनुरोध मूल सर्वर में आता है, वापस करने और सर्वर कैश छवि। कतार पर यूआरएल भी छोड़ दें।

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

यदि यह परिवर्तन नहीं कर रहा है, और केवल कैश से बाहर निकलना - एक बड़ा सौदा नहीं होना चाहिए।

तो प्रवाह की तरह इस

Request -> Cloud Front -> EC2 -> Add to cache -> Response -> CloudFront Cache -> User 
    -      -> Queue new request at each edge location 
Request -> Cloud Front -> EC2 -> already cached -> Response -> CloudFront -> User 

आप राज्य के लिए है कि यह कार्य किया गया है और पहले से ही कैश मार्कर के कुछ फार्म आवश्यकता होगी अन्यथा आप अनंत लूप में पहुंचते हैं होगा।

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