Vercel फ़ंक्शंस को टोक्यो रीजन में फ़िक्स करके स्पीड सुधारने की कहानी — प्रशांत महासागर के आर-पार राउंड ट्रिप का समाधान

इस लेख का सारांश

• डैशबोर्ड के धीमे होने का कारण था कि "Vercel फ़ंक्शन अमेरिका में और DB टोक्यो में" था, जिससे हर बार प्रशांत महासागर के आर-पार राउंड ट्रिप हो रहा था
• x-vercel-id रिस्पॉन्स हेडर से पता चलता है कि फ़ंक्शन किस रीजन में चला
• vercel.json के regions से टोक्यो फ़िक्स करने और क्वेरी को समानांतर (parallel) करने से, आंतरिक मापन में कई सेकंड से घटकर लगभग 0.2 सेकंड रह गया

"डैशबोर्ड की स्क्रीन बदलने में कई सेकंड लग जाते हैं" — इस अनुभव की गई धीमी गति की जांच कर, कारण का पता लगाकर सुधार करने का रिकॉर्ड है। यह अनुमान नहीं, बल्कि वास्तविक मापन के आधार पर अलग-अलग करके देखा गया है।

लक्षण और विश्लेषण

स्क्रीन बदलने में लगभग 3 सेकंड लगते थे। सबसे पहले यह जांचा गया कि "सर्वर का प्रारंभिक रिस्पॉन्स (TTFB)" धीमा है या "अंदर का डेटा लाना" धीमा है — पता चला कि शुरुआत तेज़ थी, लेकिन पेज के भीतर डेटा लाने की प्रक्रिया धीमी थी।

हर क्वेरी अपने आप में डेटाबेस पर कुछ मिलीसेकंड में ही तेज़ी से चल रही थी। फिर भी पूरी प्रक्रिया धीमी थी। यहाँ जिस पर शक हुआ, वह था कोड कहाँ चल रहा है (रीजन)।

कारण #1: प्रशांत महासागर के आर-पार राउंड ट्रिप हो रहा था

रिस्पॉन्स हेडर x-vercel-id देखने पर पता चला कि फ़ंक्शन अमेरिका के पूर्वी रीजन (iad1) में चल रहा था। वहीं दूसरी ओर, डेटाबेस (Supabase) टोक्यो में था। यानी हर क्वेरी पर जापान और अमेरिका के बीच राउंड ट्रिप हो रहा था।

हेडर कुछ इस तरह दिखता है (उदाहरण)।

x-vercel-id: hnd1::iad1   ← एंट्री पॉइंट टोक्यो (hnd1) है, लेकिन एक्ज़िक्यूशन अमेरिका (iad1) में हो रहा है

अगर कई क्वेरीज़ हों, तो हर बार प्रशांत महासागर के आर-पार राउंड ट्रिप होता है, और लेटेंसी जमा होती जाती है।

कारण #2: क्वेरीज़ को क्रम में (सीक्वेंशियल) चलाकर इंतज़ार किया जा रहा था

एक और बात यह थी कि होम स्क्रीन कई तरह के एग्रीगेशन (जोड़ी गई गणनाएँ) क्रम में (एक के बाद एक) ला रही थी। राउंड ट्रिप की देरी हर बार सीधे जुड़ती जा रही थी।

समाधान

रीजन को टोक्यो में फ़िक्स करना

vercel.json में रीजन तय करके, फ़ंक्शन को टोक्यो (hnd1) में चलाया जाने लगा।

{ "regions": ["hnd1"] }

इससे x-vercel-id hnd1::hnd1 हो गया, यानी फ़ंक्शन और DB दोनों टोक्यो में आ गए। राउंड ट्रिप की देरी खत्म हो गई।

क्वेरीज़ को समानांतर (parallel) करना

क्रम में चल रहे एग्रीगेशन को Promise.all से समानांतर (parallel) किया गया, और साथ ही दोहराए जा रहे डेटा फ़ेच को एक में मिला दिया गया।

नतीजा

आंतरिक मापन में, होम स्क्रीन के दिखने का समय कई सेकंड से घटकर लगभग 0.2 सेकंड रह गया। खास बात यह है कि कैशिंग पर निर्भर हुए बिना, प्रोसेस को ही तेज़ किया गया। दिखाया जाने वाला डेटा हमेशा नवीनतम ही रहता है।

सीख

• जब "क्वेरी तो तेज़ है, लेकिन स्क्रीन धीमी है" ऐसा लगे, तो सिर्फ़ DB की गति नहीं, बल्कि फ़ंक्शन और DB के बीच की भौगोलिक दूरी (रीजन) पर भी शक करें।
• x-vercel-id किस रीजन में एक्ज़िक्यूशन हुआ, यह जानने का एक आसान और असरदार तरीका है।
• जिस माहौल में राउंड ट्रिप की लागत ज़्यादा हो, वहाँ क्रम में इंतज़ार करना नुकसानदेह साबित हो सकता है। समानांतर (parallel) प्रोसेसिंग का असर बड़ा होता है।

निष्कर्ष

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