IPFS परफॉर्मेंस: gateway से फ़ाइल रिट्रीवल तेज़ करें

IPFS फ़ाइल रिट्रीवल की गति बढ़ाने की व्यावहारिक तकनीकें: डेडिकेटेड गेटवे, कैशिंग रणनीतियाँ, प्रीलोडिंग और CDN इंटीग्रेशन।

Nacho Collद्वारा अपडेट किया गया: 7 मिनट पढ़ें
IPFS फ़ाइल रिट्रीवल की गति बढ़ाने की व्यावहारिक तकनीकें: डेडिकेटेड गेटवे, कैशिंग रणनीतियाँ, प्रीलोडिंग और CDN इंटीग्रेशन।
TL;DR
  • IPFS लेटेंसी को सेकंडों से घटाकर 200 ms से कम करने के लिए पब्लिक गेटवे को डेडिकेटेड गेटवे से बदलें।
  • पब्लिक गेटवे कोल्ड CIDs पर DHT लुकअप चलाते हैं, जिससे कंटेंट रिज़ॉल्व होने से पहले 2–15 सेकंड जुड़ जाते हैं।
  • फ़ाइलों को राइट टाइम पर पिन करें, रीड टाइम पर नहीं, ताकि पहली रिक्वेस्ट से पहले ही गेटवे उन्हें रखे हो।
  • वैश्विक IPFS लेटेंसी को 10–50 ms तक लाने के लिए डेडिकेटेड गेटवे को CDN एज के साथ जोड़ें।

“IPFS धीमा है” — यह डेवलपर्स की सबसे आम शिकायतों में से एक है — और साथ ही सबसे आसानी से ठीक होने वाली भी। समस्या लगभग हमेशा एक्सेस करने के तरीके में होती है, न कि प्रोटोकॉल में। यह गाइड चार तकनीकें बताती है जो प्रोडक्शन में IPFS लेटेंसी को समाप्त करती हैं।

IPFS Ninja

त्वरित संदर्भ: गति के अनुसार IPFS एक्सेस मेथड्स#

एक्सेस मेथडसामान्य TTFBकब उपयोग करें
पब्लिक गेटवे (ipfs.io, dweb.link)2–15 सेकंडकेवल डेवलपमेंट और टेस्टिंग
डेडिकेटेड गेटवे (पिन्ड कंटेंट)50–200 msसभी प्रोडक्शन ट्रैफ़िक
डेडिकेटेड गेटवे + CDN एज10–50 msवैश्विक यूज़र बेस
इमेज ऑप्टिमाइज़ेशन एंडपॉइंट<100 ms (वार्म)सभी इमेज कंटेंट

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

पब्लिक गेटवे धीमे क्यों होते हैं#

पब्लिक गेटवे हर उस CID के लिए DHT (Distributed Hash Table) लुकअप करते हैं जिसे उन्होंने हाल ही में नहीं देखा है। DHT लुकअप का मतलब है नेटवर्क में दर्जनों पीयर्स से पूछना कि कंटेंट किसके पास है — यह राउंड-ट्रिप कोल्ड रिक्वेस्ट पर 2–15 सेकंड लेता है।

कैश हिट पर भी, पब्लिक गेटवे लाखों यूज़र्स को सर्व करते हैं। आपकी हाल ही में पिन की गई फ़ाइल की कैश प्राथमिकता कम होती है और रिक्वेस्ट के बीच में एविक्ट हो सकती है।

समाधान 1: डेडिकेटेड गेटवे#

डेडिकेटेड गेटवे आपके अकाउंट के लिए प्राइवेट होता है। आपके पिन किए गए फ़ाइलें उस गेटवे पर तुरंत कैश हो जाती हैं — किसी भी रिक्वेस्ट पर, चाहे कोल्ड हो या वार्म, DHT लुकअप नहीं होता।

# पहले: पब्लिक गेटवे, धीमा और अविश्वसनीय
curl https://ipfs.io/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

# बाद में: डेडिकेटेड गेटवे, तेज़ और निर्धारित
curl https://my-app.gw.ipfs.ninja/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

अपने IPFS.NINJA डैशबोर्ड में एक गेटवे बनाएं और स्लग को अपने प्रोजेक्ट के अनुसार सेट करें। गेटवे स्लग रेस्ट्रिक्टेड एक्सेस मोड (टोकन आवश्यक) या पब्लिक स्टैटिक असेट्स के लिए ओपन मोड को सपोर्ट करते हैं।

समाधान 2: रीड टाइम पर नहीं, राइट टाइम पर पिन करें#

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

# एक ही स्टेप में अपलोड और पिन करें
curl -X POST https://api.ipfs.ninja/upload/new \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
  -H "Content-Type: application/json" \
  -d '{
    "content": {
      "data": "BASE64_ENCODED_CONTENT",
      "type": "image/png"
    },
    "description": "Product hero image v2"
  }'

# रिस्पॉन्स — CID स्टोर करें, url तुरंत सर्व करें
# {
#   "cid": "bafy...",
#   "sizeMB": 0.24,
#   "uris": {
#     "ipfs": "ipfs://bafy...",
#     "url": "https://ipfs.ninja/ipfs/bafy..."
#   }
# }

अगर आपके पास किसी अन्य नोड या पिनिंग सर्विस के मौजूदा CID हैं, तो बिना रीअपलोड किए रीपिन करें:

curl -X POST https://api.ipfs.ninja/pin \
  -H "X-Api-Key: bws_a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4" \
  -H "Content-Type: application/json" \
  -d '{"cid": "bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi"}'

पूर्ण अपलोड API संदर्भ के लिए IPFS पर फ़ाइलें कैसे अपलोड करें देखें।

समाधान 3: गेटवे के सामने CDN#

डेडिकेटेड गेटवे एक निश्चित क्षेत्र से सर्व करते हैं। अगर आपके यूज़र कई महाद्वीपों में फैले हैं, तो सबसे नज़दीकी पॉइंट ऑफ प्रेज़ेंस से सर्व करने के लिए CDN एज लेयर जोड़ें।

चूंकि IPFS कंटेंट-एड्रेस्ड है — एक दिए गए CID हमेशा समान बाइट्स में रिज़ॉल्व होते हैं — आप हमेशा के लिए कैश कर सकते हैं:

Cache-Control: public, max-age=31536000, immutable

Cloudflare उदाहरण (फ्री टियर अधिकांश स्टैटिक-असेट वर्कलोड को कवर करता है):

  1. अपने गेटवे सबडोमेन (my-app.gw.ipfs.ninja) को Cloudflare प्रॉक्सीड CNAME के रूप में जोड़ें।
  2. एक Page Rule बनाएं: my-app.gw.ipfs.ninja/ipfs/*Cache Everything, Edge Cache TTL: एक महीना
  3. पहली रिक्वेस्ट गेटवे से जाती है और नज़दीकी एज PoP पर कैश हो जाती है। सभी बाद की रिक्वेस्ट Cloudflare से सर्व होती हैं।

परिणाम: वैश्विक TTFB 50–200 ms से घटकर 10–50 ms हो जाता है।

समाधान 4: इमेज ऑप्टिमाइज़ेशन API#

पूर्ण रेज़ोल्यूशन पर सर्व की गई रॉ IPFS इमेज पेजों को धीमा करती हैं और Core Web Vitals को नुकसान पहुंचाती हैं। एज पर रीसाइज़ करने और आधुनिक फॉर्मेट सर्व करने के लिए इमेज ऑप्टिमाइज़ेशन एंडपॉइंट का उपयोग करें:

# ओरिजिनल (गेटवे के ज़रिए पूर्ण रेज़ोल्यूशन)
https://my-app.gw.ipfs.ninja/ipfs/bafy...

# 800 px चौड़ा रीसाइज़ किया, WebP में कन्वर्ट किया
https://api.ipfs.ninja/image/bafy...?w=800&format=webp

# स्क्वेयर थम्बनेल
https://api.ipfs.ninja/image/bafy...?w=200&h=200&fit=cover

React में:

function IPFSImage({ cid, width }) {
  return (
    <img
      src={`https://api.ipfs.ninja/image/${cid}?w=${width}&format=webp`}
      width={width}
      loading="lazy"
      decoding="async"
    />
  );
}

ऑप्टिमाइज़ेशन एंडपॉइंट प्रत्येक (cid, width, format) कॉम्बिनेशन को कैश करता है — समान पैरामीटर वाली बाद की रिक्वेस्ट ओरिजिन को पूरी तरह स्किप करती हैं।

चेकलिस्ट#

  • पब्लिक गेटवे से डेडिकेटेड गेटवे पर स्विच करें
  • रीड टाइम पर नहीं, राइट टाइम पर (अपलोड पर) कंटेंट पिन करें
  • गेटवे रिस्पॉन्स पर Cache-Control: immutable सेट करें
  • वैश्विक ट्रैफ़िक के लिए गेटवे के सामने CDN जोड़ें
  • रॉ गेटवे URL के बजाय ऑप्टिमाइज़ेशन एंडपॉइंट के ज़रिए इमेज सर्व करें

उपलब्धता के लिए — न केवल गति के लिए — पिनिंग क्यों ज़रूरी है, इस पर पृष्ठभूमि के लिए IPFS पिनिंग क्या है देखें।


पिनिंग शुरू करने के लिए तैयार हैं? मुफ़्त अकाउंट बनाएं — 50 फ़ाइलें, 1 GB स्टोरेज, 2 GB बैंडविड्थ/माह। कोई क्रेडिट कार्ड नहीं चाहिए।

इस लेख के बारे में: यह लेख IPFS.NINJA के कंटेंट जनरेशन वर्कफ़्लो का उपयोग करके एक AI असिस्टेंट द्वारा ड्राफ्ट किया गया था, फिर Nacho Coll द्वारा समीक्षा और अनुमोदित किया गया। सभी कोड उदाहरण लाइव IPFS.NINJA API के विरुद्ध सत्यापित किए गए थे। यदि आपको कोई अशुद्धि मिले, तो कृपया https://github.com/ipfs-ninja/feedback पर एक इशू खोलें। हम अपने कंटेंट में AI का उपयोग कैसे करते हैं और IPFS.NINJA के पीछे के लोगों से मिलें।

Nacho Coll

लेखक के बारे में

Founder & Engineer at IPFS.NINJA

Nacho founded IPFS.NINJA to make content-addressed storage feel as simple as an S3 PUT — a single API call, a permanent CID, no wallets or peer discovery to reason about. Writes about IPFS internals, decentralized storage patterns, and the pinning-service landscape from the operator side of the wire.

ब्लॉग पर वापस

संबंधित लेख