ऑप्टिमाइज़ेशन गाइड

इस गाइड में सुरक्षा, परफ़ॉर्मेंस, और इस्तेमाल के हिसाब से आपके Google Maps API के इस्तेमाल को ऑप्टिमाइज़ करने की कई रणनीतियों के बारे में बताया गया है.

सुरक्षा

सुरक्षा के सबसे सही तरीकों की समीक्षा करना

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

Maps API ऐक्सेस करने के लिए, एपीआई पासकोड इस्तेमाल करना

Google Maps API एपीआई ऐक्सेस करने के लिए, एपीआई पासकोड पुष्टि करने का पसंदीदा तरीका है. फ़िलहाल, क्लाइंट आईडी का इस्तेमाल करने पर वे अब भी काम करती हैं. हालांकि, एपीआई पासकोड ज़्यादा बेहतर सुरक्षा कंट्रोल के साथ काम करते हैं. इन्हें खास वेब पतों, आईपी पतों, और मोबाइल SDK टूल (Android और iOS) पर काम करने के लिए ट्यून किया जा सकता है. एपीआई पासकोड बनाने और उसे सुरक्षित करने के बारे में जानकारी पाने के लिए, हर एपीआई या SDK टूल के लिए "एपीआई पासकोड का इस्तेमाल करना" पेज पर जाएं. (उदाहरण के लिए, Maps JavaScript API के लिए, एपीआई पासकोड का इस्तेमाल करना पर दिए गए इसके पेज पर जाएं.)

परफ़ॉर्मेंस

गड़बड़ियों को ठीक करने के लिए एक्सपोनेन्शियल बैकऑफ़ का इस्तेमाल करना

अगर आपके ऐप्लिकेशन में कम समय में बार-बार एपीआई को कॉल करने की कोशिश करने पर गड़बड़ियों का पता चलता है, जैसे कि क्यूपीएस की गड़बड़ियां, तो अनुरोधों को प्रोसेस करने के लिए एक्स्पोनेंशियल बैकऑफ़ का इस्तेमाल करें.

500 के दशक की गड़बड़ियों के लिए एक्सपोनेंशियल बैकऑफ़ सबसे ज़्यादा कारगर साबित होता है. ज़्यादा जानकारी के लिए, एचटीटीपी के रिटर्न स्टेटस कोड को मैनेज करना देखें.

खास तौर पर, अपनी क्वेरी की रफ़्तार को अडजस्ट करें. अपने कोड में, क्वेरी के बीच S सेकंड का इंतज़ार करें. अगर क्वेरी का जवाब अब भी क्यूपीएस की गड़बड़ी वाला मिलता है, तो इंतज़ार का समय दोगुना करें और फिर दूसरी क्वेरी भेजें. इंतज़ार का समय तब तक एडजस्ट करना जारी रखें, जब तक क्वेरी बिना किसी गड़बड़ी के वापस न आ जाए.

मांग पर उपयोगकर्ता-इंटरैक्शन के अनुरोध भेजना

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

जब मैप इधर-उधर जा रहा हो, तब ओवरले कॉन्टेंट न दिखाएं

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

Draw के तरीकों में इंटेंसिव ऑपरेशन से बचना

सामान्य नियम के तौर पर, Draw() तरीके में नॉन-ड्रॉइंग ऑपरेशन से बचना चाहिए, जो ज़्यादा परफ़ॉर्म करने वाले हों. उदाहरण के लिए, Draw() के तरीके कोड में इन चीज़ों से बचें:

  • ऐसी क्वेरी जो ज़्यादा कॉन्टेंट दिखाती हैं.
  • दिखाए जा रहे डेटा में कई बदलाव किए गए हैं.
  • कई दस्तावेज़ ऑब्जेक्ट मॉडल (DOM) एलिमेंट में बदलाव करना.

इन कार्रवाइयों की वजह से परफ़ॉर्मेंस धीमी हो सकती है. साथ ही, मैप रेंडर करते समय, लैग या विज़ुअल में रुकावट आ सकती है.

मार्कर के लिए रास्टर इमेज का इस्तेमाल करना

मैप पर किसी जगह की पहचान करने के लिए मार्कर जोड़ते समय, रास्टर इमेज का इस्तेमाल करें. जैसे, .PNG या .JPG फ़ॉर्मैट में इमेज. स्केलेबल वेक्टर का इस्तेमाल करने से बचें ग्राफ़िक्स (SVG) इमेज, क्योंकि SVG इमेज को रेंडर करने से, मैप को फिर से बनाए जाने पर लैग लग सकता है.

मार्कर ऑप्टिमाइज़ करना

ऑप्टिमाइज़ेशन कई मार्कर को एक स्टैटिक एलिमेंट के रूप में रेंडर करके परफ़ॉर्मेंस बेहतर बनाता है. यह उन मामलों में उपयोगी होता है जहां मार्कर की ज़्यादा संख्या की ज़रूरत होती है. डिफ़ॉल्ट रूप से, Maps JavaScript API यह तय करेगा कि किसी मार्कर को ऑप्टिमाइज़ किया जाएगा या नहीं. मार्कर की संख्या ज़्यादा होने पर, Maps JavaScript API ऑप्टिमाइज़ेशन की मदद से मार्कर को रेंडर करने की कोशिश करेगा. सभी मार्कर ऑप्टिमाइज़ नहीं किए जा सकते; कुछ स्थितियों में, Maps JavaScript API को ऑप्टिमाइज़ेशन के बिना मार्कर रेंडर करने की ज़रूरत पड़ सकती है. ऐनिमेट किए गए GIF या PNG के लिए ऑप्टिमाइज़ की गई रेंडरिंग बंद करें या जब हर मार्कर को एक अलग DOM एलिमेंट के तौर पर रेंडर करना ज़रूरी हो.

मार्कर डिसप्ले मैनेज करने के लिए क्लस्टर बनाना

किसी मैप पर जगहों की पहचान करने के लिए मार्कर के डिसप्ले को मैनेज करने के लिए, मार्कर क्लस्टरर लाइब्रेरी का इस्तेमाल करके मार्कर क्लस्टर बनाएं. मार्कर क्लस्टरर लाइब्रेरी में ये विकल्प शामिल होते हैं:

  • ग्रिड का साइज़, ताकि क्लस्टर में एक साथ ग्रुप किए जाने वाले मार्कर की संख्या बताई जा सके.
  • ज़्यादा से ज़्यादा ज़ूम, ताकि क्लस्टर को दिखाने के लिए, ज़्यादा से ज़्यादा ज़ूम का लेवल तय किया जा सके.
  • इमेज पाथ, ग्राफ़िक इमेज के लिए मार्कर आइकॉन के तौर पर इस्तेमाल करने के लिए.

संगीत का आनंद लेना

अपने बजट की योजना बनाने और अपनी लागत कंट्रोल करने के लिए, ये काम करें:

  • यह ट्रैक करने के लिए बजट अलर्ट सेट करें कि एक खास रकम के लिए आपकी लागत कैसे बढ़ रही है. बजट तय करने से एपीआई के इस्तेमाल की सीमा नहीं होती - यह सिर्फ़ तब आपको सूचना देता है जब आपकी लागत आपकी तय की गई रकम के आस-पास पहुंच जाती है.
  • अपने दैनिक API उपयोग की सीमा तय करें ताकि बिल करने योग्य API के लिए अपनी लागतें प्रबंधित की जा सकें. हर दिन के अनुरोध पर कैप सेट करके, अपने शुल्क को सीमित किया जा सकता है. रोज़ का बजट तय करने के लिए, आसान समीकरण का इस्तेमाल करें. यह इस बात पर निर्भर करता है कि आपको कितना खर्च करना है: (हर महीने की लागत/हर दिन की कीमत )/30 = हर दिन की सीमा के अनुरोध (एक एपीआई के लिए). कोई खास कॉन्फ़िगरेशन, बिल करने लायक कई एपीआई का इस्तेमाल कर सकता है. इसलिए, समीकरण में ज़रूरत के हिसाब से बदलाव करें. आपको 200 डॉलर का Google Maps API क्रेडिट हर महीने मिलता है. इसलिए, इसे कैलकुलेट करते समय ध्यान रखें.
  • अपने प्रोजेक्ट को अलग-अलग करके इस्तेमाल करने के लिए अलग-अलग प्रोजेक्ट का इस्तेमाल करें, उन्हें प्राथमिकता दें, और ट्रैक करें. उदाहरण के लिए, मान लें कि आपके टेस्ट में नियमित तौर पर Google Maps Platform API का इस्तेमाल किया जाता है. इसके लिए, अलग कोटे और एपीआई कुंजियों की मदद से, टेस्टिंग के लिए एक अलग प्रोजेक्ट बनाया जा सकता है. साथ ही, बहुत ज़्यादा खर्च होने से भी बचा जा सकता है.

Maps में इस्तेमाल की जानकारी मैनेज करना

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

स्टैटिक इमेज का इस्तेमाल करना

डाइनैमिक इमेज (डाइनैमिक मैप और डाइनैमिक स्ट्रीट व्यू) का इस्तेमाल करने वाले अनुरोधों की कीमत, स्टैटिक Maps और स्टैटिक स्ट्रीट व्यू से ज़्यादा होती है. अगर आपको Maps या Street View (ज़ूम या पैन करने) पर उपयोगकर्ता इंटरैक्शन का अनुमान नहीं है, तो इन एपीआई के स्टैटिक वर्शन का इस्तेमाल करें.

थंबनेल - बहुत छोटे मैप और फ़ोटो - स्टैटिक मैप और स्टैटिक स्ट्रीट व्यू के लिए एक और अच्छा इस्तेमाल है. इन आइटम के लिए कम दर और उपयोगकर्ता के इंटरैक्शन (ऑन-क्लिक) पर बिल भेजा जाता है और ये उपयोगकर्ताओं को Google Maps का पूरा अनुभव लेने के लिए डाइनैमिक वर्शन पर ले जा सकते हैं.

Maps Embed API का इस्तेमाल करना

Maps Embed API का इस्तेमाल करके किसी सिंगल मार्कर या डाइनैमिक मैप के साथ, बिना किसी शुल्क के मैप जोड़ा जा सकता है. उन ऐप्लिकेशन के लिए Maps Embed API का इस्तेमाल करें, जहां एक मार्कर और मैप को पसंद के मुताबिक बनाने की ज़रूरत नहीं होती. निर्देश मोड, व्यू मोड या खोज मोड का इस्तेमाल करने वाले Maps एंबेड एपीआई अनुरोधों का बिल भेजा जाएगा (ज़्यादा जानकारी के लिए कीमत तय करने वाली टेबल देखें).

मोबाइल ऐप्लिकेशन के लिए मोबाइल मैप SDK टूल का इस्तेमाल करना

मोबाइल ऐप्लिकेशन के लिए, Android के लिए Maps SDK टूल या मैप दिखाते समय iOS के लिए Maps SDK टूल का इस्तेमाल करें. जब मोबाइल SDK टूल इस्तेमाल करने से जुड़ी ज़रूरी शर्तों को पूरा न किया जाए, तब Maps स्टैटिक API या Maps JavaScript API का इस्तेमाल करें.

रूट में खपत का डेटा मैनेज करना

निर्देश एपीआई वेपॉइंट सीमित करना

जब संभव हो, तो किसी क्वेरी में उपयोगकर्ता एंट्री को ज़्यादा से ज़्यादा 10 वेपॉइंट तक सीमित करें. ऐसे अनुरोधों के लिए ज़्यादा दर वाला बिल भेजा जाता है जिनमें 10 से ज़्यादा वेपॉइंट होते हैं.

सबसे सही रूटिंग के लिए निर्देश API ऑप्टिमाइज़ेशन का इस्तेमाल करना

वेपॉइंट ऑप्टिमाइज़ेशन आर्ग्युमेंट का इस्तेमाल करने वाले अनुरोधों की बिलिंग ज़्यादा होती है. ज़्यादा जानकारी के लिए, Optimize वेपॉइंट देखें.

ऑप्टिमाइज़ेशन आर्ग्युमेंट, बेहतर रूटिंग पक्का करने के लिए, वेपॉइंट को क्रम से लगाता है. इसका मतलब है कि ऑप्टिमाइज़ किए गए रूट (जैसे कि A-D-B-C-E) के रैंडम क्रम (जैसे कि A-B-C-D-E) को ऑप्टिमाइज़ करने पर A से E तक की यात्रा करना बेहतर अनुभव है.

निर्देश एपीआई और दूरी मैट्रिक्स एपीआई में रीयल-टाइम ट्रैफ़िक मॉडल का इस्तेमाल करना

रीयल-टाइम ट्रैफ़िक मॉडल शामिल करने वाले निर्देश एपीआई और डिस्टेंस मैट्रिक्स एपीआई के अनुरोधों के लिए, आपको ज़्यादा शुल्क देना होता है. रीयल-टाइम ट्रैफ़िक मॉडल, निकलने के समय को now पर सेट करके चालू किए जाते हैं.

अगर ट्रैफ़िक के मॉडल को किसी अनुरोध से हटा दिया जाता है, तो नतीजे सिर्फ़ चीज़ों के आधार पर दिखाए जाते हैं. जैसे, सड़कें, दूरी, और रफ़्तार की सीमाएं.

जीपीएस डेटा सटीक न होने पर, यात्रा के लिए तय किए गए रास्ते और सबसे नज़दीकी सड़क का इस्तेमाल करना

Maps Roads API की सुविधाएं, जिस रूट से सफ़र किया गया है और सबसे नज़दीक वाली सड़क को बेहतर टियर में शामिल किया गया है. साथ ही, इनके लिए शुल्क भी ज़्यादा लिया जाता है. इन सुविधाओं का इस्तेमाल सिर्फ़ तब करें, जब जीपीएस डेटा सटीक न हो. साथ ही, Roads API, सही सड़क का पता लगाने में मदद कर सकता है. स्पीड सीमाएं, जो Roads API की दूसरी सुविधा है, सिर्फ़ एसेट ट्रैकिंग ग्राहकों के लिए उपलब्ध है.

5 से 15 मिनट के अंतराल पर, सैंपलिंग की स्पीड सीमा वाली जगहें

Maps Roads API पर कॉल की संख्या कम करने के लिए स्पीड लिमिट सेवा को, 5 से 15 मिनट के अंतराल में अपनी एसेट की जगहों का नमूना बनाएं. सटीक वैल्यू इस बात पर निर्भर करती है कि कोई एसेट कितनी तेज़ी से चल रही है. अगर कोई एसेट स्थिर है, तो सिर्फ़ एक लोकेशन सैंपल काफ़ी होता है. कई बार कॉल करने की ज़रूरत नहीं है.

कुछ डेटा इकट्ठा हो जाने पर, मोबाइल एसेट की जगह की जानकारी मिलने पर एपीआई को कॉल करने की बजाय, इंतज़ार के समय को कम करने के लिए, स्पीड सीमा सेवा को हर बार कॉल करें.

जगहों में खपत को मैनेज करना

जगह की जानकारी के अपने-आप पूरा होने की सुविधा को ऑप्टिमाइज़ करना

जगह के अपने-आप पूरे होने की सुविधा के इस्तेमाल की लागत को ऑप्टिमाइज़ करने के लिए:

  • JavaScript, Android, और iOS ऑटोकंप्लीट विजेट में, फ़ील्ड मास्क का इस्तेमाल करें, ताकि आपको सिर्फ़ वे डेटा फ़ील्ड दिखाए जा सकें जिनकी आपको ज़रूरत है.

  • बिलिंग विकल्प आपके उपयोग के उदाहरण पर निर्भर करते हैं. आपके लागू करने के दौरान, ऑटोकंप्लीट सेशन का इस्तेमाल किया जाता है या नहीं, इसके आधार पर आपसे अपने-आप पूरा होने की सुविधा - हर अनुरोध के हिसाब से या अपने-आप पूरा होने की सुविधा - हर सेशन की SKU के लिए शुल्क लिया जाएगा.

अपने इस्तेमाल के हिसाब से सही विकल्प चुनने के बारे में ज़्यादा जानकारी और दिशा-निर्देश के लिए, 'अपने-आप पूरा होने की लागत को ऑप्टिमाइज़ करने के सबसे सही तरीके डालें' लेख पढ़ें.

जगह की जानकारी और जगह से जुड़ी खोज के अनुरोधों में, किसी खास फ़ील्ड का डेटा लौटाना

आप अपने ऐप्लिकेशन में इस्तेमाल किए गए खास फ़ील्ड का डेटा लौटाने के लिए, जगह की जानकारी और जगह की जानकारी खोजने के अनुरोधों को पसंद के मुताबिक बना सकते हैं. इन फ़ील्ड को कैटगरी में बांटा जाता है: बेसिक, संपर्क, और माहौल. किसी भी फ़ील्ड के बारे में नहीं बताने वाले अनुरोधों को सभी फ़ील्ड का डेटा मिलेगा.

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

जियोकोडिंग एपीआई का इस्तेमाल करके लागत में कमी

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

अगर आपके पास सटीक पता (या उसके पास) है, तो ऑटोकंप्लीट के बजाय जियोकोडिंग का इस्तेमाल करके शुल्क कम किया जा सकता है. ज़्यादा जानकारी के लिए, जियोकोडिंग के पते इस्तेमाल करने के सबसे सही तरीके लेख पढ़ें.

Google Maps Platform के कोटा कैसे काम करते हैं

हमारे सभी एपीआई की सीमाएं तय होती हैं कि कोई ग्राहक कितने कॉल कर सकता है. ये कोटे, हर मिनट के हिसाब से कॉन्फ़िगर किए जाते हैं. किसी दिए गए एपीआई पर एक मिनट में कॉल की सीमा तक पहुंचने के बाद, अगले एक मिनट तक कॉल स्वीकार नहीं किए जाएंगे.

कोटे में सिर्फ़ सफल अनुरोध और सर्वर की गड़बड़ियां पैदा करने वाले अनुरोध ही गिने जाते हैं. पुष्टि न होने वाले अनुरोधों को कोटे में नहीं गिना जाता.

हर मिनट लागू करने की सीमा के अलावा, कई Maps API में हर सेकंड नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) लागू होते हैं. नीति उल्लंघन ठीक करने का यह तरीका (एनफ़ोर्समेंट), न तो पूरे मिनट में एक जैसे इस्तेमाल की गारंटी देता है. साथ ही, यह आपको उस मिनट के लिए इस्तेमाल किए जाने का कोटा खत्म होने से भी रोकता है. यह आपको किसी भी एक मिनट के पहले एक या दो मिनट में पूरा कोटा इस्तेमाल करने से रोकता है. साथ ही, अचानक इस्तेमाल में बढ़ोतरी होने पर, सेवा में रुकावट से बचाता है. नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) के इन अंतरों से निपटने के लिए, सभी क्यूपीएस में अपने क्यूपीएम के इस्तेमाल का औसत निकाल कर, अपने कोटे के इस्तेमाल और ज़रूरी शर्तों की योजना बनाएं.

GMP API में हर सेकंड के लिए नीति उल्लंघन ठीक करने का तरीका (एनफ़ोर्समेंट) शामिल है. जैसे, दिशा एपीआई, डिस्टेंस मैट्रिक्स एपीआई, एलिवेशन एपीआई, जियोकोडिंग एपीआई, जगहें एपीआई, और रोड्स एपीआई.

आपके किए गए अनुरोधों की कुल संख्या के हिसाब से, किसी भी GMP API प्रॉडक्ट की कीमत का अनुमान लगाएं.