क्या यह सरल ब्राउज़र कैशिंग का लाभ उठाने के लिए मेरी संपूर्ण उपयोगकर्ता छवियों फ़ाइल संरचना को बदलने के लिए लायक है?

Question

मेरी एक मोबाइल साइट पर, मैं बस अपने उपयोगकर्ता के प्रोफ़ाइल चित्रों को उनके उपयोगकर्ता फ़ोल्डर में '1.jpg' के रूप में संग्रहीत करता हूं, और जो भी वे अपलोड करते हैं, उसके लिए वृद्धिशील रूप से वहां से जाते हैं। इसका मतलब यह है कि जब भी वे अपना प्रोफ़ाइल चित्र बदलते हैं, उदाहरण के लिए, फ़ाइल नाम वही रहता है।

मैं इमेज कैशिंग का लाभ उठाना चाहता हूं, ताकि जब भी उपयोगकर्ता की प्रोफ़ाइल देखी जाए और उसे दोबारा देखा जाए, तो वही पुरानी तस्वीर बार-बार डाउनलोड न हो, लेकिन मैं अपने उपयोगकर्ताओं के ब्राउज़र चाहता हूं नया डाउनलोड करें यदि यह बदल गया है।

जो मैं पढ़ रहा हूं, उससे ऐसा लगता है कि वास्तव में ऐसा करने का एकमात्र तरीका वास्तव में यादृच्छिक फ़ाइल नामों का उपयोग करना है और DB में उन सभी फ़ाइल नामों पर नज़र रखना है, जिससे आप हाल ही में एक गैर-निष्कासित कैश सेट कर सकते हैं क्योंकि वे एक नया फ़ाइल नाम है, तब तक परिवर्तित पिक्स फिर से खींचे जाते हैं। जिस तरह से मैंने उन्हें अब तक संरचित किया है, उसकी सुंदरता यह है कि मैं डेटाबेस को पूरी तरह से छोड़ सकता हूं और फ़ाइलों को सीधे एक्सेस कर सकता हूं क्योंकि उनके स्थान का अनुमान है।

तो मेरा सवाल यह है कि क्या मेरे लिए अपनी साइट की पूरी फ़ाइल संरचना को बदलना, नए अपलोड पर शाश्वत कैशिंग और ऑटोमैटिक री-डाउनलोडिंग के लाभ के लिए डीबी तत्व को जोड़ना है?

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

धन्यवाद।

Answer 1

आमतौर पर इस्तेमाल किया जाने वाला एक उपाय यह है कि आपकी छवि के URL कुछ इस तरह दिखें:

http://www.example.com/path/to/images/1.jpg?v=123456

यहां, /path/to/images/1.jpgछवि का वास्तविक URL पथ है, जबकि ?v=123456URL के अंत में केवल एक डमी क्वेरी घूर रही है। क्वेरी स्ट्रिंग कुछ भी हो सकती है - एक संस्करण संख्या, एक टाइमस्टैम्प, छवि सामग्री का एक हैश - जब तक आप इसे बदलते हैं जब भी छवि बदलती है, और इसे उसी समय रखें जब यह नहीं होता है।

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

इस प्रकार, आप अपने वेब सर्वर को भेजने Expiresऔर Cache-ControlHTTP हेडर को अनिश्चित कैशिंग की अनुमति देने के लिए कॉन्फ़िगर कर सकते हैं , इस ज्ञान में सुरक्षित है कि आप क्वेरी स्ट्रिंग को बदलकर फिर से लोड कर सकते हैं। ऐसा करने का एक तरीका है, यदि आप mod_expires के साथ Apache का उपयोग कर रहे हैं, तो .htaccessलाइनों के साथ अपनी छवि निर्देशिका में एक फ़ाइल डालनी है :

ExpiresActive On
ExpiresDefault "access plus 1 year"

इस तकनीक का उपयोग कई लोकप्रिय वेबसाइटों द्वारा किया जाता है। उदाहरण के लिए, यदि आप इस पृष्ठ के HTML स्रोत को देखते हैं, तो आप पाएंगे कि इसके लिए शैली पत्रक इस तरह के URL से लोड किया गया है:

http://cdn.sstatic.net/stackoverflow/all.css?v=7cd8ea9d6f1e

यहाँ, ?v=7cd8ea9d6f1eएक डमी क्वेरी स्ट्रिंग है जैसे मैंने ऊपर वर्णित किया है; आप पुष्टि कर सकते हैं कि इसे बदलकर और यह देखकर कि यह वास्तव में अभी भी उसी फ़ाइल को लौटाता है।

Comments

यह भी दिलचस्प है, लेकिन जब फ़ाइल को पिछली बार संशोधित किया गया था, तब मैं कैसे ट्रैक करूंगा कि जब ब्राउज़र पहली बार देखा गया था, तो यह निर्धारित करने के लिए कि मुझे उपयोगकर्ता के ब्राउज़र को फिर से लाने के लिए कहना चाहिए (जैसे कि क्वेरी मान बदलकर)?

— प्रोग्रामरगर्ल

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

— इल्मरी करोनन

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

— प्रोग्रामरगर्ल

हां, वह काम करना चाहिए।

— इल्मरी करोनें

वहाँ कोई महत्वपूर्ण downsides कि मैं के बारे में पता कर रहे हैं नहीं कर रहे हैं। आप खोज इंजन इंडेक्स में अपनी छवियों की डुप्लिकेट प्रतियों के साथ समाप्त हो सकते हैं, लेकिन Google जैसे कम से कम प्रमुख खोज इंजन ऐसी चीजों से निपटने के बारे में बहुत स्मार्ट हैं, क्योंकि यह एक ऐसी सामान्य चाल है। किसी भी स्थिति में, उस मुद्दे को rel = "कैनोनिकल" HTTP हेडर भेजकर और आपके समाप्ति समय को मामूली रखकर (जैसे, पूरे वर्ष के बजाय सिर्फ एक महीने या एक सप्ताह) भेजकर कम किया जा सकता है ।

— इल्मरी करोनन

Answer 2

कैश करने का एक से अधिक तरीका है।

सशर्त जी.ई.टी.

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

इस मामले में पूरी छवि वापस नहीं दी गई है, इसलिए आपके पास बैंडविड्थ की बचत है। हालाँकि, एक GET अनुरोध अभी भी जारी किया जाएगा, इसलिए आपके पास अभी भी अनुरोध का ओवरहेड और विलंबता होगा।

आप अपने वेबसर्वर सेट Cache-Controlहेडर को public,max-age=Nअपनी छवियों के लिए एक मूल्य के साथ कैश ताजगी की कीमत पर अनुरोधों की संख्या को थोड़ा कम कर सकते हैं । यह कहता है कि कैश max-ageको अपडेट करने से पहले संसाधन को सबसे अधिक सेकंड तक रख सकते हैं ।

हालांकि, HTTP कैशे प्रविष्टि को अमान्य करने का केवल एक ही तरीका परिभाषित करता है, जो आपके एप्लिकेशन के शब्दार्थों को फिट नहीं कर सकता है: यदि आप किसी ऐसे url को POST या PUT करते हैं जो प्रोफ़ाइल फ़ोटो को अपडेट करता है, तो Location: [url of photo]हेडर के साथ उत्तर दें और उस url के लिए कैश प्रविष्टि को अमान्य कर दिया जाएगा।

(यह वह तंत्र है जो आपको टिप्पणियों के साथ एक वेबपृष्ठ को कैश करने की अनुमति देता है, और फिर उपयोगकर्ता द्वारा नई टिप्पणी पोस्ट करने के बाद पृष्ठ को जबरन ब्राउज़र द्वारा पुनः लोड किया जाता है। ब्राउज़र एक और एक के POST /commentसाथ जवाब देगा । ध्यान दें कि यह उपयोग नहीं किया गया था। लंबे समय तक बग के कारण फ़ायरफ़ॉक्स में काम करना ।)303 See OtherLocation: /page/with/comment

जब तक आपके पास बहुत अधिक ट्रैफ़िक नहीं है, कैशिंग के लिए यह दृष्टिकोण ठीक है।

उरोज बदलना

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

इसके लिए दो सामान्य तकनीकें हैं।

क्वेरी स्ट्रिंग्स

फ़ाइल सिस्टम से फ़ाइल की सेवा करते समय वेब सर्वर क्वेरी स्ट्रिंग्स को अनदेखा करते हैं। कैश, हालांकि, नहीं: /1.jpg?t=12345और /1.jpg?t=67890दो पूरी तरह से अलग, असंबंधित संसाधन हैं, भले ही सर्वर को लगता है कि वे समान हैं।

जब भी आप अपने HTML में एक संसाधन के लिए एक संदर्भ बनाते हैं, और एक लंबे Expiresहेडर को सेट करते हैं, तो एक आसान चीज जो आप कर सकते हैं, वह है फाइल सिस्टम टाइमस्टैम्प को एक क्वेरी स्ट्रिंग के रूप में जोड़ना । तब ब्राउज़र इस संसाधन को हमेशा के लिए कैश कर देगा और जब तक क्वेरी स्ट्रिंग नहीं बदलेगा, तब तक कोई GET नहीं करेगा।

एक नकारात्मक पक्ष यह है कि किसी आइटम के लिए नए यूआरएल के वेबसर्वर को निर्देश देना मुश्किल या असंभव है यदि आप किसी कैश को जबरन अमान्य करना चाहते हैं। उदाहरण के लिए, यदि किसी ब्राउज़र में /1.jpg?v=1संदर्भ के साथ एक कैश्ड एचटीएमएल पेज है , लेकिन प्रविष्टि को साफ़ करने के लिए हुआ है /1.jpg?v=1(शायद यह फ़ाइल या मेमोरी स्पेस से बाहर चला गया है), तो यह एक नया अनुरोध करेगा /1.jpg?v=1। यदि इस बीच छवि बदल गई है /1.jpg?v=2, तो उचित प्रतिक्रिया या तो है:

1. फ़ाइल का पुराना संस्करण परोसें। आप ऐसा करेंगे यदि आप चाहते थे कि सभी संसाधन एक-दूसरे के अनुरूप हों क्योंकि वे एक निश्चित समय पर थे। यह आपको सीएसएस फाइलों के साथ करना चाहिए, उदाहरण के लिए, चूंकि एक पुरानी एचटीएमएल फाइल वाली नई सीएसएस फाइल ठीक से काम नहीं कर सकती है!
2. फ़ाइल के नए संस्करण का उपयोग करने के लिए पुनर्निर्देशित करें 301 Moved Permanently। आप ऐसा करेंगे यदि आप चाहते थे कि सभी संसाधन यथासंभव नए हों।

इन दोनों को अकेले एक वेबसर्वर के साथ करना मुश्किल है, जिसका अर्थ है कि आपको छवि अनुरोधों के लिए भी एक वेब एप्लिकेशन को आमंत्रित करना होगा, जो अधिक जटिल और अधिक संसाधन-गहन दोनों हो सकता है। Webservers फ़ाइलों की सेवा में बहुत तेज़ हैं , इसलिए एक वेब एप्लिकेशन का ओवरहेड आपके बैंडविड्थ और विलंबता लाभ को निगल सकता है।

फ़ाइल नाम

क्वेरी स्ट्रिंग जोड़ने के बजाय, आप फ़ाइल नाम बदलते हैं। इसका मतलब है कि फ़ाइल सिस्टम पर फ़ाइलों के कई संस्करणों को रखना आसान है, लेकिन आपको संभवतः फ़ाइल मेटाडेटा को संग्रहीत करने और अपने संसाधनों और उनके नामों पर नज़र रखने के लिए अन्य डेटाबेस बुक-कीपिंग की आवश्यकता होगी।

Answer 3

http स्थिति के बारे में पढ़ें 304 Not Modified, आपको 304 के साथ एक डाउनलोड अनुरोध का जवाब देने में सक्षम होना चाहिए, और इसके द्वारा सर्वर को कैश्ड डेटा का उपयोग करने के लिए कहा जा सकता है, जो इसे ब्राउज़र में बदलने के लिए प्रेरित करता है। और इस सवाल को पढ़ें /programming/2978496/make-php-page-return-304-not-modified-if-it-hasnt-been-modified

Comments

दिलचस्प है, लेकिन क्या यह एक समस्याग्रस्त फ़ाइल स्कीमा के लिए "बैंड सहायता" समाधान है, या क्या मेरी फ़ाइल स्कीमा अच्छी है और बस इस कोचिंग की आवश्यकता है? इसके अलावा, मुझे यह कैसे पता चलेगा कि जब फ़ाइल को पिछली बार संशोधित किया गया था, जब ब्राउज़र पहली बार देखा गया था, यह निर्धारित करने के लिए कि मुझे उपयोगकर्ता के ब्राउज़र को फिर से लाने के लिए कब बताना चाहिए?

— प्रोग्रामरगर्ल

im इसके साथ परिचित नहीं है, लगता है कि फ्रांसिस Avila इसके बारे में अधिक जानते हैं

— Puggan Se