वार्निश के साथ स्थिर फ़ाइलों को कैश क्यों करें, पास क्यों नहीं


9

मेरे पास nnx / php-fpm / varnish / wordpress और amazon s3 चलाने वाला एक सिस्टम है।

अब मैंने सिस्टम की स्थापना करते समय बहुत सारी विन्यास फाइलों को देखा है, और उन सभी में मैंने कुछ इस तरह पाया:

    /* If the request is for pictures, javascript, css, etc */
    if (req.url ~ "\.(jpg|jpeg|png|gif|css|js)$") {
        /* Remove the cookie and make the request static */
        unset req.http.cookie;
        return (lookup);
    }

मुझे समझ नहीं आता कि ऐसा क्यों किया जाता है। अधिकांश उदाहरण वेब के रूप में NginX भी चलाते हैं। अब सवाल यह है कि आप इन स्थिर फाइलों को कैश करने के लिए वार्निश कैश का उपयोग क्यों करेंगे।

यह मुझे और अधिक समझ में आता है केवल डायनामिक फ़ाइलों को कैश करने के लिए ताकि php-fpm / mysql इतना हिट न हो।

क्या मैं सही हूँ या मैं यहाँ कुछ याद कर रहा हूँ?

अपडेट करें

मैं दिए गए उत्तर के आधार पर प्रश्न में कुछ जानकारी जोड़ना चाहता हूं।

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

उस ने कहा, मेरे लिए और अधिक महत्वपूर्ण स्थिर केंट है । मुझे विभिन्न कैश ऐप्स और वेबसर्वर ऐप पर कुछ परीक्षण और बेंचमार्क के साथ एक लिंक मिला है।

http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwan/

NginX वास्तव में आपकी स्थैतिक सामग्री प्राप्त करने में तेज है, इसलिए यह सिर्फ इसे पास करने के लिए अधिक समझ में आता है। NginX स्थिर फ़ाइलों के साथ बहुत अच्छा काम करता है।

-

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

जवाबों:


10

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

जुड़ा हुआ लेख नहीं-समझ के साथ, अधिकांश लोग यह सुझाव देंगे कि वार्निश Nginx की तुलना में बेहतर करता है यदि सेटअप ठीक से हो - हालाँकि, (और मैं वास्तव में इसे स्वीकार करने से नफरत करता हूं) - मेरे स्वयं के परीक्षण से प्रतीत होता है कि nginx वार्निश () से तेज एक स्थिर फ़ाइल की सेवा कर सकता है सौभाग्य से, मैं उस उद्देश्य के लिए वार्निश का उपयोग नहीं करता हूं)। मुझे लगता है कि समस्या यह है कि यदि आप वार्निश का उपयोग करते हैं, तो आपने अपने सेटअप में एक अतिरिक्त परत जोड़ ली है। बैकएंड सर्वर पर उस अतिरिक्त परत के माध्यम से गुजरना हमेशा बैकएंड से सीधे सेवा देने की तुलना में धीमा होगा - और यही कारण है कि वार्निश को कैश करने की अनुमति तेज हो सकती है - आप एक कदम बचाते हैं। अन्य लाभ डिस्क-आईओ फ्रंट पर है। यदि आप मॉलॉक का उपयोग करने के लिए वार्निश सेटअप करते हैं, तो आप डिस्क को बिल्कुल भी नहीं मारते हैं, जो इसे अन्य प्रक्रियाओं के लिए उपलब्ध है (और आमतौर पर चीजों को गति देगा)।

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

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

(मेरा त्वरित - बहुत मोटा, किसी भी विश्वसनीयता को नहीं दिया जाना - परीक्षण से पता चला कि नगनेक्स (प्रत्यक्ष) सबसे तेज था - चलो इसे 100% कहते हैं, वार्निश (मैलोक के साथ) थोड़ा धीमा था (लगभग 150%), और नितंब के पीछे नग्नेक्स पास के साथ) सबसे धीमा (लगभग 250%) था। यह खुद के लिए बोलता है - सभी या कुछ भी नहीं - बैकएंड के साथ संवाद करने के लिए अतिरिक्त समय (और प्रसंस्करण) को जोड़ने, बस यह बताता है कि यदि आप वार्निश का उपयोग कर रहे हैं, और रैम को समाप्त करना है , आप नगीन को वापस पारित करने के बजाय वार्निश से प्राप्त कर सकते हैं और इसे सब कुछ कैश कर सकते हैं।)


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

उस ने कहा, मेरे पास एक के लिए भी मेमोरी नहीं है, और मेरे पास कुछ टेम्प्लेट लेआउट फाइलें हैं, जिन्हें मैं CDN पर नहीं रखना चाहता, मैं सिर्फ उन्हें अपने टेम्पलेट डायरेक्टरी में रखना चाहता हूं। मैं अपने वार्निश कॉन्फ़िगरेशन से स्निपेट को हटा दूंगा जो उन्हें कैश करता है, इसलिए मेरे पास जो मेमोरी है उसका बेहतर उपयोग किया जा सकता है। मुझे 3 अलग-अलग सेटअप के बारे में टिप पसंद आई। मुझे लगता है कि बीमार सिर्फ पोर्ट को सीधे nginx के लिए खोलते हैं और वहां से टेम्पलेट फ़ाइलों की सेवा करते हैं। वार्निश संभाल HTML, nginx स्थिर संभाल, और अगर कुछ ताजा सामग्री के लिए nessesary php / mysql।
सैफ बेचन

आप ध्यान दें कि कई वारिश सेटअप कई जीबी मेमोरी का उपयोग करते हैं - ठीक से सेटअप, और वास्तविक जीवन परिदृश्यों के तहत, मुझे संदेह नहीं है कि यह नगीन-आउट करता है; हालांकि, मैं सुझाव दे सकता हूं कि यह लचीलापन और विकल्प वार्निश की पेशकश है जो इसे लोकप्रिय बनाता है - यह विशेष रूप से कैशिंग ऑफ्टर के लिए डिज़ाइन किया गया है। Wordpress के साथ, मेरा पसंदीदा सेटअप Wordpress + W3TC (+ Cloudfront) + वार्निश + Nginx + PHP-FPM + APC है। यह वास्तव में कुछ मामलों में अन्य सेटअपों की तरह तेज नहीं है, लेकिन यह अच्छे प्रदर्शन के साथ लोड को काफी अच्छी तरह से संभालता है। ध्यान रखें कि कॉर्पोरेट फ़ायरवॉल अक्सर गैर मानक पोर्ट ब्लॉक करते हैं।
साइबरएक्स ६६

जिज्ञासा से बाहर, अपने सीडीएन पर अपने टेम्प्लेट (संभवतः अर्थ सीएसएस / जेएस - PHP, निश्चित रूप से अपने सर्वर पर क्यों रहना चाहिए) को न रखें। इसके अलावा, मेरे एक ec2- इंस्टेंस को ध्यान में एक ही आधार के साथ सेटअप किया गया है, और इसमें निम्नलिखित शामिल हैं: if (req.url ~ "\.(png|gif|jp(e?)g|avi|flv|mp(e?)g|mp4|mp3)"){return(pass);}vcl_recv () में। मूलतः, मैं मीडिया को कैश नहीं करना चाहता - लेकिन निश्चित रूप से html (php) और यहां तक ​​कि js / css को कैश करना चाहता हूं (सिद्धांत है कि चित्र लेआउट के मुकाबले कथित पेज लोड समय में कम योगदान करते हैं)।
साइबरएक्स

मैंने w3tc देखा है, लेकिन मुझे वास्तव में प्लगइन्स का उपयोग करना पसंद नहीं है। मैं बस अपने स्वयं के छोटे प्लगइन्स बनाता हूं जो प्रत्येक विशिष्ट साइट के लिए विशिष्ट विकल्पों का ध्यान रखते हैं, इसलिए मुझे पता है कि सब कुछ क्या करता है। एक प्रोग्रामर POV से मैंने कुछ प्लगइन्स को देखा है, और कुछ भयानक रूप से डिज़ाइन किए गए हैं। मैंने अपना खुद का मिनीइज़ प्लगइन बनाया, एस 3 और सीएफ, छोटे मेमेकैच्ड प्लगइन और कुछ अन्य लोगों के लिए मीडिया फाइलों को डायरेक्ट स्मशिंग और अपलोड करना। मुझे बस अंतिम प्लगइन बनाने के लिए कोई मुद्दा नहीं मिला है जो सीडीएन को टेम्प्लेट अपलोड करने का ध्यान रखता है।
सैफ बेचन

2

मुझे लगता है कि आप कुछ याद कर रहे होंगे।

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

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

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

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

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

सही बात?


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

2

के लिए गतिशील सामग्री , किसी तरह की तरह शेयर भाव वास्तव में अक्सर परिवर्तन (एक पर एक दूसरे अद्यतन SaaS serverएक से backend server) लेकिन फिर भी अधिक बार (दसियों हजार से पूछे जा सकता है subscription clients):

[stock calculation / backend server] ----- [SaaS server] ------ [subscription clients]

इस मामले में, कैशिंग पर SaaS serverसे प्रति-सेकंड अद्यतन backend serversबनाता है यह संभव दसियों हजार के प्रश्नों को पूरा करने के subscription users

सास सर्वर पर कैश के बिना तो यह मॉडल काम नहीं करेगा।


1

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

स्टैटिक फाइल्स के लिए: कैश टू एचडीडी सब कुछ के लिए: कैश टू रैम।

यह आपको इस परिदृश्य को लागू करने के बारे में अधिक जानकारी देनी चाहिए: http://www.getpagespeed.com/server-setup/varnish-static-files-cache


बस आप उत्सुक हैं कि आप HDD कैश पर स्टेटिक फाइल्स क्यों डाल सकते हैं - क्या यह अनिवार्य रूप से कैश के बिना डिस्क से सर्विस करने जैसा ही काम नहीं है?
शेन एन

अनिवार्य रूप से, हाँ :) लेकिन अगर वार्निश जगह में है, तो उसे लाने के लिए बैकेंड (नगनेक्स, अपाचे, जो भी हो) से संपर्क करना होगा। यह सीधे फाइल सिस्टम से ऐसा नहीं कर सकता। बैकएंड संचार के ओवरहेड को खत्म करने के लिए, उन्हें डिस्क पर भी, कैश किया जाना चाहिए।
डैनिला वर्शिनिन

आह ठीक है, जो समझ में आता है - धन्यवाद @ danila-v
शेन एन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.