ईएसआई के साथ एक सिम्फनी 2 ऐप कैसे व्यवस्थित करें?

बहुत से ट्रैफ़िक वाले एक नए प्रोजेक्ट पर, हम इस बारे में सोच रहे हैं कि कैसे हमारे सिम्फनी 2 ऐप को कैश का लाभ उठाने के लिए तैयार किया जाए, और भविष्य में अधिक आक्रामक होने के लिए तैयार रहें। मुझे आपकी राय जानना अच्छा लगेगा।ईएसआई के साथ एक सिम्फनी 2 ऐप कैसे व्यवस्थित करें?

मान लें कि उपयोगकर्ता किसी पृष्ठ को स्थानों की एक सूची का अनुरोध करता है। यह पृष्ठ है:

<html>... 
<body> 
    <header> 
    ... 
    <!-- Embed the top user menu --> 
    <esi:include src="http://example.com/profile/menu" /> 
    ... 
    </header> 

    <content> 
    ... 
    common data of the list 
    ... 
    <!-- Embed the common data of the first 20 places, the same for everyone --> 
    <esi:include src="http://example.com/lists/17/places" /> 
    ... 
    <!-- Embed the user data of the list (used in JS) --> 
    <esi:include src="http://example.com/lists/17/user" /> 
    ... 
    <!-- Embed the user data of the list of places (used in JS) --> 
    <esi:include src="http://example.com/lists/17/places/user" /> 
    ... 
    </content> 
</body>  
</html>

एचटीएमएल गेटवे (Symfony या वार्निश) पर कैश किया जाएगा:

- list 
    - common data (title, author, description) 
    - user data (the user likes the list + other data) 
- first 20 places 
    - common data (title, photo of each place) 
    - user data (the rates of the user for those places)

HTML की तरह हो सकता है। गेटवे पर ज्यादातर समय स्थानों की सूची कैश की जाएगी। उपयोगकर्ता डेटा अनुरोध वे लोग होंगे जिन्हें कैश किया जाता है और कैश नहीं किया जाता है (प्रारंभ में कम से कम नहीं)।

प्रश्न:

आप इस संरचना के बारे में कैसा लगता है?
यदि उपयोगकर्ता अज्ञात है, तो क्या मैं उपयोगकर्ता डेटा के लिए esi-include बनाने से बच सकता हूं? अगर मेरे पास एनन उपयोगकर्ता के लिए कुकी भी है? कैसे?
क्या उपयोगकर्ता मेनू के लिए esi-include समझ में आता है?
या क्या हमें ईएसआई के बारे में भूल जाना चाहिए और हमेशा नियंत्रक के माध्यम से जाना चाहिए (उदाहरण के लिए आम डेटा के प्रस्तुत दृश्य को कैशिंग करना)?
क्या हमें 2 ईएसआई-अनुरोधों को स्थानांतरित करना चाहिए जो उपयोगकर्ता डेटा को सर्वर पर प्रतीक्षा करने के बजाय AJAX-Call होने के लिए कहें?
क्या यह हमें स्केल करने का एक अच्छा तरीका है यदि हमें इसे तेजी से करने की आवश्यकता है? सबसे अच्छा क्या होगा?

बहुत बहुत धन्यवाद!

स्रोत

2012-11-26 fesja

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

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

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

आप यूआरएल से कुछ नियम बनाने का प्रयास कर सकते हैं, लेकिन यदि आप डिफ़ॉल्ट सिम्फनी ट्विग हेल्पर्स का उपयोग करते हैं, तो जेनरेट किए गए यूआरएल/_internal/... हैं, इसलिए सार्वजनिक और निजी लोगों को अलग करना मुश्किल हो सकता है।

यदि आप Cache-Control: public पास हो गए हैं तो भी आप हमेशा किसी भी कुकीज़ को अनदेखा करने के लिए कॉन्फ़िगर कर सकते हैं। यह Symfony में डिफ़ॉल्ट रूप से किया जाता है:
```
if ($this->isPrivateRequest($request) && !$response->headers->hasCacheControlDirective('public')) { 
    $response->setPrivate(true); 
} 
```
आप कोड से देख के रूप में, यदि आप public निर्देश है, प्रतिक्रिया निजी कभी नहीं होगा।

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

मुझे लगता है कि आपके पंजीकृत उपयोगकर्ताओं के लिए जेएस आवश्यक है (खोज बॉट नहीं), इसलिए मैं उपयोगकर्ता डेटा लोड करने में भिन्नता के लिए जावास्क्रिप्ट का उपयोग करने का सुझाव दूंगा।

जावास्क्रिप्ट कोड देख सकता है कि उपयोगकर्ता को कुकी session-id आदि है और केवल इस मामले में डेटा प्राप्त करने का अनुरोध करें। सत्र आईडी प्राप्त करने से जावास्क्रिप्ट कोड से बचने के लिए _loggedin जैसी कुछ अन्य कुकी सेट करना भी एक अच्छा विचार हो सकता है।

उपयोगकर्ताओं में लॉग इन नहीं किया गया है कुकीज़ में कुछ डेटा भी हो सकता है, जैसे _likedPost:1,2,132। जावास्क्रिप्ट इस कुकी को प्राप्त कर सकता है और अतिरिक्त अनुरोध किए बिना कुछ HTML सुधार भी कर सकता है।

जैसा कि हमने इन कुकीज़ के साथ किया था: हमने एप्लिकेशन कुकीज़ से जेएस-केवल कुकीज़ को अलग किया। हमने जेएस कुकीज़ के लिए _\w जैसे कुछ पैटर्न से ऐसा किया। फिर हमने कुकी हेडर को विभाजित करने और इन जेएस-केवल कुकीज़ को हटाने के लिए वार्निश कॉन्फ़िगरेशन को ट्वीक किया। फिर, यदि कोई अन्य कुकी नहीं छोड़ी गई है, तो प्रतिक्रिया हर किसी के साथ साझा की जाती है। एप्लिकेशन (सिम्फनी) उन कुकीज़ को नहीं प्राप्त करता है, क्योंकि वे छीन दिए जाते हैं।
मुझे लगता है कि यह हर पृष्ठ में समान है।
मुझे लगता है कि ईएसआई अच्छा है क्योंकि वार्निश मेमोरी में कैश पकड़ सकता है। तो हो सकता है कि यह सामग्री के लिए आपकी हार्ड डिस्क पर कोई प्रश्न न करे। चूंकि आपका कंट्रोलर कैश भी स्मृति में हो सकता है, मुझे लगता है कि वार्निश कैश को सभी रूटिंग, पीएचपी कोड, सेवाओं के प्रारंभिक इत्यादि के साथ सिम्फनी ढांचे की तुलना में अधिक तेज दिखेंगे।
यह निर्भर करता है, लेकिन मुझे लगता है कि यह हो सकता है बेहतर दृष्टिकोण बनें। ध्यान रखें, कैश अलग-अलग जीवन जीते हैं। उदाहरण के लिए, यदि आपकी जगह सूची 2 घंटों तक कैश की जाती है, तो इस समय के अंत में स्थान बदल सकते हैं - सूची में कुछ नए आइटम नए हैं और उनमें से कुछ गायब हैं। उपयोगकर्ता की आपकी सूची अभी भी पुरानी है (कैश), लेकिन आप नई सूची के बारे में उपयोगकर्ता का डेटा प्रदान करते हैं - कुछ डेटा की आवश्यकता नहीं है, इसमें से कुछ गायब है।

जावास्क्रिप्ट द्वारा लोड किए गए स्थानों को प्राप्त करने के लिए यह बेहतर तरीका हो सकता है, उदाहरण के लिए data-list-item-id जैसे कुछ HTML गुणों की खोज करना और फिर इन वस्तुओं के बारे में डेटा पूछने के लिए AJAX अनुरोध करें। इस मामले में आपके उपयोगकर्ता डेटा को वर्तमान कैश सूची के साथ सिंक्रनाइज़ किया जाएगा और आप 2.
यदि कैश अमान्यता (PURGE अनुरोध) का उपयोग नहीं किया जाता है, तो सभी HTTP कैश शीम वास्तव में अच्छा है, के बजाय दोनों सूचियों के लिए 1 AJAX अनुरोध कर सकते हैं। मापने के लिए। आप एप्लिकेशन को कई सर्वरों पर स्केल कर सकते हैं और वार्निश को कुछ नियमों से यादृच्छिक रूप से कॉल करने के लिए कॉन्फ़िगर कर सकते हैं या उनमें से एक को असफलता के रूप में उपयोग करने के लिए कॉन्फ़िगर कर सकते हैं। यदि बैंडविड्थ अभी भी बहुत बड़ा है, तो आप हमेशा कैश टाइमआउट और अन्य कॉन्फ़िगरेशन को संशोधित कर सकते हैं।

स्रोत

2012-12-11 22:39:08

बहुत बहुत शुक्रिया barius, हम बजाय ईएसआई में की, ajax में उपयोगकर्ता डेटा अनुरोध कर रहे हैं। तो मैं आपसे सहमत हूं। चलो यह कैसे जाता है देखते हैं। कुंजी और मजेदार हिस्सा PURGE का उपयोग करने से बचने के साथ होगा। यह स्केल करने में सक्षम होने का उद्देश्य है। – fesja

इसे साझा करने के बाद यह कैसे चला जाता है साझा करें –

ईएसआई के साथ एक सिम्फनी 2 ऐप कैसे व्यवस्थित करें?

उत्तर

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