वर्चुअल टूर होस्टिंग की व्याख्या: सर्वर, स्टोरेज & CDN

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

यह व्याख्या सर्वरों, स्टोरेज, बैंडविड्थ और एक कंटेंट डिलीवरी नेटवर्क के कामों को अलग करती है। यह यह भी बताती है कि SaaS और self-hosted डिलिवरी किस तरह जिम्मेदारियों को विभाजित करते हैं। इंस्टॉलेशन निर्देशों के बजाय अवसंरचना अवधारणाओं के लिए, हमारे व्यावहारिक गाइड का उपयोग करें अपनी खुद की वर्चुअल टूर होस्ट करना।

जब कोई वर्चुअल टूर खोलता है तो क्या होता है?

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

व्यूअर शुरू होता है: HTML, स्क्रिप्ट्स, और प्रस्तुति एसेट्स इंटरैक्टिव अनुभव स्थापित करते हैं।
प्रोजेक्ट लोड होता है: सीन कनेक्शंस, हॉटस्पॉट पोज़िशन, और सेटिंग्स व्यूअर को बताते हैं कि क्या दिखाना है।
मीडिया पहुँचती है: पैनोरमा फ़ाइलें या टाइल्स, फ़्लोर प्लान, ऑडियो, और वीडियो अनुरोध होने पर डिलीवर किए जाते हैं।
ब्राउज़र सीन को रेंडर करता है: विज़िटर के डिवाइस छवियों को डीकोड करता है और इमर्सिव व्यू को ड्रॉ करता है।

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

सर्वर: एप्लिकेशन चलाना और अनुरोधों का जवाब देना

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

पब्लिशिंग वर्कलोड और व्यूइंग वर्कलोड अलग होते हैं। इमेज टाइल्स जनरेट करना या बड़े पैनोरमास का रीसाइज़िंग तैयारी के दौरान CPU और मेमोरी खा सकता है। पहले से जनरेट की हुई इमेजेज़ सर्व करना मुख्यतः डिलीवरी का काम है। CPU जोड़ने से प्रोसेसिंग में मदद मिल सकती है पर यह विज़िटर के डाउनलोड बॉटलनेक को हल नहीं करता।

मूल स्रोत वह प्राधिकृत स्रोत है जहाँ से फ़ाइलें या प्रतिक्रियाएँ प्राप्त की जाती हैं। यह एक वेब सर्वर, एक एप्लिकेशन सर्विस, या एक ऑब्जेक्ट स्टोरेज सर्विस हो सकती है। एक ही भौतिक मशीन को हर भूमिका निभाने की आवश्यकता नहीं है, और क्लाउड इन्फ्रास्ट्रक्चर किराए पर लेना फिर भी self-hosted डिप्लॉयमेंट का हिस्सा हो सकता है।

स्टोरेज: आप कितना कंटेंट रखते हैं

स्टोरेज वह क्षमता है जो फाइलों और डेटा के आराम (at rest) द्वारा घिरी जाती है। केवल स्रोत पैनोरामाओं से अधिक को गिनें: जनरेट की गई टाइल्स, प्रीव्यू इमेजेज़, हॉटस्पॉट मीडिया, प्रोजेक्ट रिकॉर्ड्स, और रखी गई संस्करण भी जगह लेते हैं। बैकअप और एडिटिंग मास्टर्स अलग रखे जा सकते हैं, पर उनके लिए भी अपनी क्षमता का बजट चाहिए।

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

एक उदाहरणात्मक गणना के रूप में, 40 प्रकाशित प्रोजेक्ट जो औसतन 250 MB प्रत्येक हैं, दशमलव इकाइयों में लगभग 10 GB लेते हैं। इसमें बैकअप, स्रोत आर्काइव, एप्लिकेशन, और अतिरिक्त संस्करण शामिल नहीं हैं। केवल मूल फ़ोटो साइज को गुणा करने के बजाय एक पूर्ण प्रकाशित प्रोजेक्ट को मापें। हमारे वर्चुअल टूर फ़ाइल फ़ॉर्मैट गाइड में बताया गया है कि क्यों काम करने वाले मास्टर्स और डिलीवरी एसेट्स अलग प्रयोजनों की सेवा करते हैं।

बैंडविड्थ और ट्रांसफर: विज़िटर्स कितना कंटेंट प्राप्त करते हैं

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

स्टोर किया गया टूर हर विज़िट पर समान मात्रा का ट्रांसफर उपयोग नहीं करता। विज़िटर एक सीन खोल सकते हैं या सब कुछ एक्सप्लोर कर सकते हैं; मोबाइल व्यूअर कम रेज़ोल्यूशन का अनुरोध कर सकते हैं; कैश्ड एसेट्स पुन: उपयोग हो सकते हैं। ऑटोप्ले वीडियो और प्रीलोडिंग कुल डेटा को काफी बदल सकते हैं।

उदाहरणात्मक मासिक ट्रांसफर = विज़िट्स × प्रति विज़िट औसत डिलीवर किया गया डेटा। यदि 2,000 विज़िट्स को प्रत्येक 30 MB मिलता है, तो विज़िटर डिलीवरी दशमलव इकाइयों में लगभग 60 GB है। 30 MB एक अनुमानित माप है, न कि वर्चुअल टूर का बेंचमार्क। यह पहले दिए गए कुल स्टोर्ड प्रोजेक्ट आकार से संबंधित नहीं है।

मासिक कुलों को समकालिक (concurrent) मांग से भी अलग रखें। एक कैंपेन जो एक ही समय में कई विज़िटर्स लाता है वह डिलिवरी पर दबाव डाल सकता है भले ही मासिक ट्रांसफर मामूली रहे। यह जाँचें कि कोई प्लान ट्रांसफर लिमिट्स, थ्रूपुट, रिक्वेस्ट काउंट्स, और अतिरिक्‍त उपयोग को कैसे संभालता है बजाय इसके कि “अनलिमिटेड” को बिना शर्त अनलिमिटेड संसाधन समझें।

CDN: कैश्ड मीडिया को विज़िटर्स के नज़दीक डिलीवर करना

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

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

कैश नियमों को कंटेंट से मेल खाना चाहिए

पब्लिक पैनोरामा टाइल्स अक्सर पुन: उपयोग के लिए कैश की जा सकती हैं। एडिटर सेशंस, व्यक्तिगत प्रतिक्रियाएँ, और प्रतिबंधित टूर ऐसे नियम मांगते हैं जो एक्सेस कंट्रोल का सम्मान करें। यदि आधारभूत मीडिया सार्वजनिक रूप से पुनःप्राप्त किया जा सकता है तो एक प्राइवेट लिंक पर्याप्त नहीं होता। MDN Cache-Control संदर्भ बताते हैं कि ब्राउज़र और साझा कैशेस को कैसे निर्देशित किया जाता है।

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

ओरिजिन ट्रैफ़िक और विज़िटर ट्रैफ़िक अलग होते हैं

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

SaaS और Self-Hosted: समान बिल्डिंग ब्लॉक्स, अलग ऑपरेटर

दोनों दृष्टिकोणों को compute, स्टोरेज, और नेटवर्क डिलिवरी की आवश्यकता होती है। फर्क यह है कि कौन कंपोनेंट्स का चयन करता है, संचालित करता है, और उनका भुगतान करता है, और ये लागतें और नियंत्रण टूर क्रिएटर को कैसे प्रस्तुत किए जाते हैं।

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

किसी भी लेबल की गारंटी नहीं है कि स्पीड, पोर्टेबिलिटी, या कुल लागत कम होगी। एक SaaS सेवा CDN का उपयोग कर सकती है, और एक self-hosted प्लेटफ़ॉर्म किराए के क्लाउड सर्वरों पर चल सकता है। एक्सपोर्ट एक्सेस, डोमेन कंट्रोल, क्षमता नियमों, और सौंपे गए जवाबदेहियों की तुलना करें। हमारा self-hosted बनाम क्लाउड तुलना व्यापक व्यावसायिक निर्णय को संबोधित करती है।

समस्या के अनुसार होस्टिंग विनिर्देश पढ़ें

अपलोड फेल होते हैं या प्रोसेसिंग रुक जाती है: अपलोड लिमिट्स, रनटाइम सेटिंग्स, उपलब्ध मेमोरी, CPU, और फ्री स्टोरेज की जाँच करें।
पहला सीन धीरे लोड होता है: प्रतिक्रिया समय, प्रारंभिक एसेट आकार, नेटवर्क दूरी, और विज़िटर का कनेक्शन जांचें।
नेविगेशन लंबा इंतजार करवाता है: सीन पेलोड्स, टाइल रिक्वेस्ट्स, प्रीलोडिंग, और कैश व्यवहार की जाँच करें।
किसी व्यस्त लॉन्च पर त्रुटियाँ आती हैं: समकालिक अनुरोध, एप्लिकेशन क्षमता, ओरिजिन लोड, और डिलिवरी सीमाओं की जाँच करें।
अपडेट के बाद पुराने इमेजेस रह जाते हैं: ब्राउज़र और CDN कैशेस, एसेट वर्शन, और इनवैलिडेशन की जाँच करें।

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

अक्सर पूछे जाने वाले प्रश्न

क्या वर्चुअल टूर होस्टिंग 360 फ़ोटो स्टोर करने के समान है?

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

क्या हर विज़िट पर पूरा टूर डाउनलोड होता है?

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

क्या हर वर्चुअल टूर को CDN की ज़रूरत होती है?

नहीं। नज़दीकी ऑडियंस को सेवा देने वाला एक छोटा टूर अपने ओरिजिन से पर्याप्त प्रदर्शन कर सकता है। CDN तब उपयोगी होता है जब नेटवर्क दूरी, बार-बार होने वाले एसेट अनुरोध, या ट्रैफ़िक वितरण इसे जायज़ बनाते हैं; वास्तविक लोडिंग परीक्षणों से लाभ की पुष्टि करें।

क्या self-hosted का मतलब है कि सर्वर मेरे ऑफिस में होना चाहिए?

नहीं। यह डिप्लॉयमेंट के नियंत्रण का वर्णन करता है। किराये की होस्टिंग, मैनेज्ड सर्वर, और क्लाउड अकाउंट्स self-hosted सॉफ़्टवेयर का समर्थन कर सकते हैं जब वे इसकी तकनीकी आवश्यकताओं को पूरा करते हों।

क्या किसी टूर को एंबेड करना उसकी होस्टिंग को मेरी वेबसाइट पर स्थानांतरित कर देगा?

नहीं। एक एम्बेडेड व्यूअर सामान्यतः अपने मूल सर्विस से लोड होता रहता है, और उसका मीडिया कॉन्फ़िगर किए गए होस्ट्स द्वारा ही डिलीवर होता है। एम्बेड यह बदल देता है कि टूर कहाँ दिखाई देता है, न कि स्वचालित रूप से कहाँ उसका एप्लिकेशन और एसेट्स रहते हैं।

योजनाओं की तुलना करने से पहले डिलिवरी चेन को समझें

वर्चुअल टूर की होस्टिंग के लिए एक विश्वसनीय दृष्टिकोण चार प्रश्नों को अलग करना शुरू करता है: एप्लिकेशन क्या चलाता है, फ़ाइलें कहाँ रखी जाती हैं, विज़िटर्स कितना डेटा प्राप्त करते हैं, और पुन: उपयोग योग्य प्रतियाँ कहाँ डिलीवर की जाती हैं। SaaS उन निर्णयों को एक सेवा में बाँध देता है; self-hosting आपको अपने प्रदाताओं के साथ उन्हें व्यवस्थित करने देता है। संसाधनों को वास्तविक वर्कलोड्स से मिलाएँ बजाय यह मानने के कि एक मुख्य स्टोरेज आंकड़ा पूरे अनुभव का वर्णन करता है।

Simple Virtual Tour एक self-hosted तरीका प्रदान करता है इंटरैक्टिव टूर बनाने, प्रबंधित करने, और प्रकाशित करने का। लाइव डेमो देखें ताकि विज़िटर अनुभव को देखें, या उपलब्ध पैकेजों की समीक्षा करें जब आप अपनी खुद की डिप्लॉयमेंट की योजना बना रहे हों।