रीयल-टाइम क्यूरेशन सेवा के लिए, कम से कम समय में डेटा ट्रांसफ़र करने की ज़रूरी शर्तों को पूरा करने के लिए, अपने सर्वर को उन Google Cloud क्षेत्रों के आस-पास रखें जहां से आपको टारगेट की जा रही जगहों के लिए सेगमेंट के अनुरोध मिलने की संभावना सबसे ज़्यादा है. डीएनएस को इस तरह से कॉन्फ़िगर करें कि किसी जगह से आपके एंडपॉइंट पर भेजा गया ट्रैफ़िक, आपके सबसे नज़दीकी सर्वर पर रूट हो जाए.
इस टेबल में, रीयल-टाइम क्युरेशन में इस्तेमाल किए गए Google Cloud के क्षेत्रों की सूची दी गई है. साथ ही, उनकी अनुमानित जगह और टारगेट की गई जगहों के उदाहरण दिए गए हैं. इन जगहों से SegmentRequest
में मौजूद डेटा को आपके सर्वर पर भेजे जाने की सबसे ज़्यादा संभावना होती है:
Google Cloud क्षेत्र | क्षेत्र की लोकेशन | टारगेट की गई जगह का उदाहरण |
---|---|---|
us-east1 | साउथ कैरोलिना, अमेरिका | उत्तरी अमेरिका (पूर्वी तट) |
us-west1 | ओरेगन, अमेरिका | उत्तरी अमेरिका (वेस्ट कोस्ट) |
us-central1 | आयोवा, अमेरिका | उत्तरी अमेरिका (सेंट्रल) |
europe-west1 | बेल्जियम | यूरोप |
europe-west4 | Amsterdam, Netherlands | यूरोप |
asia-southeast1 | सिंगापुर | एशिया |
asia-east1 | ताइवान | एशिया |
लेटेंसी कम करने के लिए, एचटीटीपी परसिस्टेंट कनेक्शन का इस्तेमाल करना
Google का सुझाव है कि आप रीयल-टाइम क्युरेशन इंटिग्रेशन को इस तरह कॉन्फ़िगर करें कि वह लगातार कनेक्शन का इस्तेमाल करे. इससे, वीडियो स्ट्रीम होने और उसके दिखने के समय के अंतर को कम किया जा सकता है. स्थायी कनेक्शन बन जाने के बाद, आपका एंडपॉइंट हर आने वाले सेगमेंट के अनुरोध के लिए नया कनेक्शन बनाने के बजाय, कनेक्शन का फिर से इस्तेमाल करेगा.
सर्वर की जगह
ऐसा हो सकता है कि सेगमेंट के ज़्यादातर अनुरोध, उपयोगकर्ता की जगह के सबसे नज़दीकी इलाके से भेजे जाएं. हालांकि, Google इस बात की गारंटी नहीं देता कि ऐसा हमेशा होगा. ज़्यादा से ज़्यादा इलाकों के आस-पास सर्वर लगाने से, आपको टारगेट की गई जगहों के लिए सेगमेंट के ज़्यादा अनुरोध मिल सकते हैं. Google का सुझाव है कि सर्वर को उन इलाकों के आस-पास रखा जाए जहां आपके टारगेट किए गए इलाके मौजूद हैं. उदाहरण के लिए, उत्तरी अमेरिका से ज़्यादातर ट्रैफ़िक पाने के लिए, अपने सर्वर को us-east1, us-west1, और us-central1 क्षेत्रों के आस-पास रखें.
आपको सेगमेंट के जवाब 50 मिलीसेकंड के अंदर भेजने होंगे.
इस समयसीमा में, क्षेत्र और आपके सर्वर के बीच नेटवर्क में लगने वाला समय और आपके सर्वर को जवाब तैयार करने में लगने वाला समय, दोनों शामिल हैं. हमारा सुझाव है कि नेटवर्क की लेटेन्सी में अचानक होने वाले बदलावों के लिए, आपके पास कम से कम 10 मिलीसेकंड का बफ़र होना चाहिए.
अगले चरण
- रीयल-टाइम क्युरेशन प्रोटोकॉल का रेफ़रंस: जानें कि रीयल-टाइम क्युरेशन में इस्तेमाल किए गए अनुरोध और जवाब कैसे बनाए जाते हैं.
- रीयल-टाइम में कॉन्टेंट को व्यवस्थित करने के अनुरोधों को पार्स करना: रीयल-टाइम में कॉन्टेंट को व्यवस्थित करने के अनुरोधों को पार्स करने का तरीका जानें.
- रीयल-टाइम में जवाब जनरेट करने की सुविधा बनाना: रीयल-टाइम में जवाब जनरेट करने की सुविधा बनाने का तरीका जानें.