वार्निश + स्टेटिक एचटीएमएल पेज

Question

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

मेरा सवाल यह है कि यदि आपके पास ऐसी वेबसाइट है जिसमें इसकी कैशिंग तंत्र स्थिर एचटीएमएल फाइलों के लिए सभी तरह से कॉन्फ़िगर किया गया है तो वार्निश पर इसका कितना असर होगा? क्या एक रिवर्स प्रॉक्सी अनुरोध को संसाधित करने के लिए HTTP सर्वर द्वारा किए गए काम को काटता है? यदि आपके पास सर्वर-साइड पर व्यापक रूप से कैश किया गया है (HTTP शीर्षलेख, एटैग, एक्सपियर हेडर, डाटाबेस कैशिंग, फ्रैगमेंट और पेज कैशिंग) तो HTTP त्वरक इस पर सुधार करने के लिए और क्या करेगा? HTTPS संचय और सर्वर साइड कैशिंग:

Answer 1

सबसे पहले, हम है कि एक सामान्य वेब प्रणाली में पर जाने के कैशिंग दो अलग अलग प्रकार के बीच अंतर करना चाहिए।

HTTPS संचय HTTP हेडर द्वारा नियंत्रित किया जाता है, तो आप ETag और विभिन्न समाप्ति तंत्र का कहना है विशेष रूप से के रूप में (Cache-Control की Expires और विभिन्न पहलुओं सहित)। यह सब RFC 2616 (HTTP), section 13 में शामिल है, और क्लाइंट से HTTP अनुरोध के जवाब को वापस करने के लिए मूल सर्वर पर वापस जाने के बिना HTTP कैश की अनुमति देता है। असल में, HTTP कैशिंग तंत्र कुछ मामलों में क्लाइंट और सर्वर के बीच एक और मशीन को कार्य करने की अनुमति देता है जैसे कि यह सर्वर है। यह वास्तव में वार्निश क्या कर रहा है, जैसा कि हम एक मिनट में देखेंगे; एक और आम उपयोग है कि बहुत से लोग परिचित हैं जब आईएसपी अपने नेटवर्क के भीतर एक HTTP कैश प्रदान करते हैं, जो आमतौर पर अपने नेटवर्क के बाहर मूल सर्वर की तुलना में अपने ग्राहकों (और कथित प्रदर्शन में सुधार) को तेजी से प्रतिक्रिया दे सकते हैं।

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

मैंने पहले कहा था कि वार्निश एक HTTP कैश था, जिसका अर्थ है कि यह सीधे एक स्थिर फ़ाइल की सेवा करने वाले वेब सर्वर से अधिक कुशल होने में सक्षम है।पर विचार करें एक वेब सर्वर करना है क्या:

1. HTTP अनुरोध
2. एक फ़ाइल पर यूआरआई (और इस तरह Accept-Encoding रूप में किसी भी प्रासंगिक अनुरोध हेडर,) मानचित्र
3. फ़ाइल का निर्माण करने के बारे में जानकारी को ऊपर खींचने के पार्स प्रतिक्रिया में HTTP शीर्षलेख; इन इकाई हेडर के रूप में जाना जाता है (RFC 2616 section 7.1 है, जो चीजों को शामिल Content-Length जैसे, Content-Type और Expires और Last-Modified हेडर HTTPS संचय में प्रयुक्त)
4. आंकड़ा बाहर अतिरिक्त प्रतिक्रिया हेडर (RFC 2616 section 6.2 क्या; इन में शामिल ETag और Vary, दोनों महत्वपूर्ण)) HTTPS संचय के कुछ हिस्सों और सामान्य हेडर फील्ड (RFC 2616 section 4.5 जरूरत है
5. नेटवर्क से बाहर HTTP स्थिति लाइन और हेडर लिखने
6. नेटवर्क

तुलनात्मक रूप से करने के लिए बाहर फ़ाइल की सामग्री लिखते हैं, वार्निश इस सब के ऊपर है, इसलिए यह सब करना पड़ता है:

1. HTTP अनुरोध
2. यूआरआई के नक्शे को पार्स (और कोई प्रासंगिक अनुरोध शीर्षलेख) अपने आंतरिक कैश
3. में एक प्रविष्टि पर एक प्रविष्टि पर देखें कि कोई प्रविष्टि है या नहीं; यदि वहां है, तो इसे नेटवर्क पर लिखें; HTTP हेडर कैश

में संग्रहीत किया गया होगा अगर वहाँ एक प्रविष्टि नहीं है, वार्निश थोड़ा और अधिक काम करने के लिए दिया गया है:

1. एक वेब से कनेक्ट इसके पीछे सर्वर है कि सब पहली सूची में 1-6 तक
2. सभी HTTP हेडर के साथ नेटवर्क के जवाब लिखने के लिए एक प्रतिक्रिया उत्पन्न करने के लिए चरणों के माध्यम से चला जाएगा
3. दुकान अपने कैश में प्रतिक्रिया

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

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

(ध्यान दें कि वार्निश हेडर्स और वास्तव में कैश के अंदर और बाहर जा रहा डेटा संपादित कर सकता है, जो चीजों को जटिल बनाता है। लेकिन मुख्य बिंदु अभी भी खड़े हैं, और फ्लाई वार्निश पर चीजों को संपादित करते समय भी अविश्वसनीय रूप से तेज़ हो सकते हैं।)