Cloudflare Workers CPU परफ़ॉर्मेंस बेंचमार्क का विश्लेषण

 (blog.cloudflare.com)
1 पॉइंट द्वारा GN⁺ 2025-10-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • स्वतंत्र डेवलपर Theo Browne के बेंचमार्क में Cloudflare Workers, Vercel Node.js की तुलना में अधिकतम 3.5 गुना धीमा दिखा
  • बेंचमार्क परिणामों के कारण कई इन्फ्रास्ट्रक्चर·लाइब्रेरी सेटिंग्स और बेंचमार्क मेथडोलॉजी से जुड़ी समस्याएं थीं
  • शेड्यूलिंग एल्गोरिद्म में सुधार, V8 garbage collector tuning, OpenNext optimization सहित प्लेटफ़ॉर्म और फ़्रेमवर्क स्तर पर कई सुधार किए गए
  • प्रमुख पैचों के कारण अब ज़्यादातर बेंचमार्क में Cloudflare और Vercel के बीच परफ़ॉर्मेंस अंतर काफ़ी कम हो गया है
  • आगे भी Cloudflare पब्लिक इन्फ्रास्ट्रक्चर और फ़्रेमवर्क सुधार में योगदान देते हुए, लगातार optimization और बेंचमार्क validation जारी रखने की योजना में है

अवलोकन और बेंचमार्क विवाद

  • अक्टूबर 2023 में डेवलपर Theo Browne ने Cloudflare Workers और Vercel (AWS Lambda आधारित) की server-side JavaScript execution speed की तुलना करने वाला बेंचमार्क प्रकाशित किया
  • Cloudflare Workers भी Vercel की तरह V8 JavaScript engine पर आधारित है, फिर भी इसमें अधिकतम 3.5 गुना तक परफ़ॉर्मेंस गिरावट देखी गई
  • इन्फ्रास्ट्रक्चर micro-tuning, JavaScript लाइब्रेरी के अंतर, और टेस्ट मेथड की समस्याओं सहित कई कारणों से यह अनुचित परफ़ॉर्मेंस अंतर पैदा हुआ
  • इन समस्याओं को सुधारने की प्रक्रिया में Cloudflare Workers की कुल परफ़ॉर्मेंस बेहतर हुई
  • प्रमुख सुधारों में trigonometrical function operations की speed बढ़ाने जैसे ऐसे बदलाव भी शामिल थे जो दूसरे प्लेटफ़ॉर्मों को भी प्रभावित कर सकते हैं

बेंचमार्क मेथडोलॉजी

  • Theo का शुरुआती test client San Francisco से Webpass के जरिए एक्सेस कर रहा था, और Vercel sfo1 region में चल रहा था
  • Cloudflare ने network latency के असर को कम करने के लिए AWS us-east-1 data center के भीतर से Vercel के iad1 instance से सीधे संचार किया
  • सभी बेंचमार्क single-threaded (1 vCPU) environment में किए गए, जिससे pricing comparison भी आसान रहा
  • टेस्ट के दौरान मिले bugs को upstream में Pull Request के रूप में भेजकर ठीक कराया गया

Cloudflare प्लेटफ़ॉर्म में परफ़ॉर्मेंस सुधार

Workers Runtime में scheduling और isolation handling सुधार

  • पहले traffic को "warm" isolation (ऐसे instance जो तेज़ी से request संभाल सकें) की ओर route करने वाला एल्गोरिद्म इस्तेमाल होता था, जो बड़े apps की latency और throughput के लिए optimized था, लेकिन CPU-intensive workloads के लिए अप्रभावी था
  • जब CPU उपयोग वाले requests ज़्यादा आ जाते थे, तो queue लंबी हो जाती थी और latency बढ़ती थी; यह बात बेंचमार्क में सामने आई
  • Cloudflare Workers में billing CPU usage time के आधार पर होती है, इसलिए wait time (isolation तैयार होने की प्रतीक्षा) पर शुल्क नहीं लगता
  • एल्गोरिद्म में बदलाव कर ऐसे workloads को जल्दी पहचानने और नए isolation तेज़ी से बनाने की व्यवस्था की गई
  • इससे I/O-bound और CPU-bound दोनों तरह के workloads को अधिक कुशलता से संभाला जा सका, और यह बदलाव दुनिया भर में तुरंत लागू कर दिया गया

V8 garbage collector settings में सुधार

  • टेस्ट के दौरान यह पुष्टि हुई कि JavaScript garbage collection और memory management की समस्याओं का परफ़ॉर्मेंस गिरावट पर बड़ा असर था
  • V8 engine में "young generation" memory area का size बहुत सीमित रूप से fixed था (पुरानी recommendation 128MB के अनुसार)
  • आधुनिक V8 में यह setting उल्टा अनावश्यक रूप से बार-बार GC होने का कारण बन रही थी
  • manual tuning हटाकर V8 की अपनी heuristic-based dynamic memory allocation को अनुमति दी गई
  • इससे लगभग 25% बेंचमार्क परफ़ॉर्मेंस सुधार देखा गया, और यह सभी Workers पर लागू किया गया

OpenNext आधारित Next.js परफ़ॉर्मेंस optimization

अनावश्यक memory allocation और copying हटाना

  • विश्लेषण में पाया गया कि request processing time का 10–25% memory cleanup (GC) में खर्च हो रहा था
  • OpenNext, Next.js और React में internal data buffers को ज़रूरत से ज़्यादा copy करने वाले कई code patterns मौजूद थे
  • stream output data को पूरा का पूरा अनावश्यक रूप से copy किया जा रहा था, और Buffer.concat के जरिए केवल length मापने के लिए बड़े data copies हो रहे थे
  • संबंधित issues को OpenNext repository में Pull Request के जरिए सुधारा जा रहा है
  • योजना है कि इन्हें और बेहतर बनाकर पूरे प्लेटफ़ॉर्म में साझा परफ़ॉर्मेंस लाभ दिया जाए

अप्रभावी stream adapter optimization

  • Workers Web Streams API पर आधारित हैं, जबकि Next.js मुख्य रूप से Node.js stream API के लिए डिज़ाइन है, इसलिए conversion adapters की ज़रूरत पड़ती है
  • अनावश्यक रूप से nested adapters के उपयोग से memory copy और buffering overhead बढ़ रहा था
  • कोड को सिर्फ ReadableStream.from(chunks) तक सरल बनाकर बीच की copies हटाई गईं
  • डिफ़ॉल्ट single-value stream (highWaterMark=1) संरचना को byte stream (highWaterMark=4096 आदि) में बदलकर बड़े data processing को optimize किया गया
  • आगे Next.js और React की stream processing सुधारने वाले patches को भी upstream प्लेटफ़ॉर्मों में भेजने की योजना है

JSON.parse() परफ़ॉर्मेंस समस्या और V8 patch

  • Next.js और React में reviver option वाले JSON.parse() के उपयोग पर अत्यधिक calls हो रही थीं (100,000 से अधिक)
  • नए ECMAScript standard में reviver को तीसरा argument (source context) मिलने लगा, जिससे परफ़ॉर्मेंस और खराब हुई; यह Firefox, Chrome आदि में भी सामान्य समस्या है
  • Cloudflare Workers टीम ने V8 engine में patch दिया (33% परफ़ॉर्मेंस सुधार), जिसका लाभ Node.js, Chrome browser, Deno और पूरे ecosystem को मिलने की उम्मीद है

Node.js में trigonometric function परफ़ॉर्मेंस समस्या

  • Theo के बेंचमार्क से अलग, math trigonometric functions (sin, cos आदि) के repeated-call बेंचमार्क में Cloudflare Workers 3 गुना तेज़ पाए गए
  • वजह यह थी कि Node.js, V8 के नए/तेज़ trigonometric function path (compile-time flag) के साथ अभी तक पूरी तरह sync नहीं था
  • Cloudflare Workers में संयोग से यह flag डिफ़ॉल्ट रूप से enabled था, और Node.js के लिए Pull Request patch भेजा गया
  • चूँकि यह समस्या open source ecosystem में साझा थी, इसलिए AWS Lambda और Vercel तक इसके पहुँचने पर कुल speed stability बेहतर होने की उम्मीद है

बेंचमार्क डिज़ाइन/मापन की सीमाएँ और सीख

  • अधिकांश बेंचमार्क client-side request time (latency) measurement पर आधारित थे, न कि वास्तविक server-side CPU usage time के सीधे मापन पर
  • network path, data center location, hardware generation, multi-tenancy जैसी कई सीधे तुलना न की जा सकने वाली variables परिणामों को प्रभावित कर सकती हैं
  • यदि सिर्फ first byte arrival time (TTFB) मापा जाए, तो पूरे rendering/transfer time को समझना कठिन होता है; TTFL पर जाने से network speed differences के प्रति संवेदनशीलता और बढ़ सकती है
  • server hardware/software की विविधता, instance allocation luck जैसे कारणों से अस्थायी और आपस में जुड़े noise factors भी मौजूद रहते हैं
  • बेंचमार्क environment और workflow को सटीक बनाने तथा variables को align करने की प्रक्रिया से practical सुधार बिंदु निकले, जिनसे अपनी और अन्य कंपनियों की दोनों platforms को लाभ मिला

प्रयोग के दौरान मिली बेंचमार्क और environment setting समस्याएँ

  • Next.js में force-dynamic setting लागू न होना, cache handling logic, और response streaming के तरीक़ों के अंतर के कारण परिणामों की गलत व्याख्या का जोखिम था
  • React SSR बेंचमार्क में NODE_ENV environment variable सेट न होने से dev mode चल रहा था, जिससे वास्तविकता से धीमे परिणाम मिले
  • इन त्रुटियों को environment variables स्पष्ट रूप से सेट करके सुधारा गया

आगे की योजना और निष्कर्ष

  • Cloudflare Workers Runtime के विभिन्न परफ़ॉर्मेंस सुधार पहले ही पूरी तरह लागू किए जा चुके हैं, इसलिए users को बिना किसी अलग कार्रवाई के लाभ मिलेगा
  • Theo को test code और OpenNext optimization शामिल करने वाले Pull Requests उपलब्ध कराए गए
  • OpenNext और Vercel आधारित Next.js के बीच अंतर कम करने के लिए अतिरिक्त सुधार नियोजित हैं
  • scheduling algorithm और open source engines (V8, Node.js) में लगातार upgrades तथा community contribution जारी रखने की नीति है
  • बेहतर बेंचमार्क और profiling के ज़रिए संभावित issues जल्दी खोजकर optimization और sharing की संस्कृति बनाए रखने की योजना है

संदर्भ सामग्री और अतिरिक्त लिंक

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-16
Hacker News राय

  • यह अच्छी बात है कि CF वास्तव में अपने प्रोडक्ट को बेहतर बनाने की कोशिश कर रहा है। लेकिन बदलाव इतनी तेज़ी से होते हैं कि उनके साथ तालमेल बैठाना मुश्किल हो जाता है, और कई बार रिलीज़ गुणवत्ता से आगे निकल जाती है। उदाहरण के लिए, R2 Data Catalog में अभी भी Iceberg v3 सपोर्ट की कमी है, Wrangler भी सिर्फ कुछ महीनों में काफ़ी बदल गया, और Pages के जल्द गायब हो जाने का आभास होता है, इसलिए Workers Assets पर माइग्रेशन काफ़ी झंझट भरा लगता है। Wrangler 3 में जो config ठीक काम करती थी, वह Wrangler 4 में सही तरह लागू नहीं हुई, और लगता है कि Wrangler 5 में फिर कोई नया interaction model आ जाएगा

    • “Pages के गायब हो जाने” वाली बात पर, CF ने वास्तव में एक community post में कहा है कि जब तक Workers, Pages के बराबर स्तर तक नहीं पहुँच जाता, तब तक वे Pages को बंद नहीं करेंगे संबंधित पोस्ट आधिकारिक रूप से Pages के deprecate होने की कोई बात ढूंढना मुश्किल है, और pages.cloudflare.com तथा developer.cloudflare.com/pages दोनों सक्रिय रूप से चल रहे हैं। Reddit की एक पोस्ट Pages माइग्रेशन की ओर इशारा करती है, लेकिन उस लिंक में भी आधिकारिक बंद होने का कोई उल्लेख नहीं है बाकी राय से सहमत हूँ, और खासकर उस हिस्से पर मुझे भी हैरानी हुई Reddit संदर्भ लिंक

    • इस बात से सहमत नहीं हो सकता कि Wrangler 3 की config, Wrangler 4 में वैसे की वैसे काम नहीं करती। Wrangler 4 में config format में कोई बदलाव नहीं था, और major version bump का कारण 99.99% users के लिए प्रभावहीन था। संबंधित बदलाव यहाँ देखे जा सकते हैं। सिर्फ major version upgrade से भी असुविधा बढ़ती है, इसलिए मैंने खुद भी इसका विरोध किया था, लेकिन बहुत दुर्लभ exception cases की वजह से टीम को सावधानी बरतनी पड़ी। आगे चलकर हम ऐसे तरीक़े विकसित करेंगे जिनसे इस तरह के मुद्दों को major version bump के बिना संभाला जा सके, जैसे esbuild versions का parallel support। runtime की दृष्टि से हम backward compatibility को लेकर खास तौर पर बहुत गंभीर हैं backward compatibility पर ब्लॉग Pages गायब नहीं हो रहा है, और Workers Assets, Pages का अधिक flexible implementation version है। अगर आपको अतिरिक्त features की ज़रूरत नहीं है, तो माइग्रेट करने की कोई मजबूरी नहीं, और बाद में automatic migration भी किया जाएगा

    • यह फिर याद दिलाता है कि महत्वपूर्ण प्रोजेक्ट्स या कई साल तक चलने वाले सिस्टम बनाते समय 'boring tech' का इस्तेमाल करना बेहतर होता है

    • “Pages गायब हो जाएगा” ऐसा आधार आपने कहाँ देखा, यह जानने की जिज्ञासा है। मैं खुद कई प्रोजेक्ट्स में Pages का अच्छी तरह इस्तेमाल कर रहा हूँ

    • दिलचस्प बात यह है कि यह विवाद Cloudflare के Vercel से तेज़ होने के दावे से शुरू हुआ था। उसके बाद किसी जानकार व्यक्ति ने benchmark किया और असल में उल्टा नतीजा निकला, जिसके परिणामस्वरूप Cloudflare ने performance बढ़ाने के लिए वास्तविक सुधार कार्य किए

  • मुझे यह बहुत पसंद आया कि लेख ने प्रतियोगी को कोसने के बजाय सुधार के बिंदुओं को पहचाना और उभारा। OpenNext implementation में भी प्रगति हुई है, और यह बात प्रभावशाली है कि दूसरे vendors भी उसे दोबारा इस्तेमाल कर सकते हैं

  • मैं NextJS को Vercel पर होस्ट करता था और अब Astro/React को Cloudflare पर माइग्रेट कर रहा हूँ। हैरानी की बात यह है कि “edge” पर हर request के लिए web app render होने की स्थिति में भी response time लगभग 100-200ms है, जो लगभग static page जैसी ही गति देता है। पिछले कुछ हफ्तों में Cloudflare Worker के सुधार भी साफ़ महसूस हुए हैं; cold start लगभग गायब हो गए हैं और response speed भी कहीं अधिक स्थिर है porting के दौरान web app लिंक

    • नमस्ते! जानना चाहता हूँ कि edge environment में आप database से कैसे connect कर रहे हैं। क्या आप Cloudflare का database इस्तेमाल कर रहे हैं? application और database के बीच round trip बढ़ जाने से मुझे edge hosting में उल्टा performance गिरता हुआ मिला था। मैं खुद इसे एक बार आज़माना चाहता था

  • यह देखना दिलचस्प है कि किसी बहुत बड़े नहीं यूट्यूबर द्वारा डाला गया वीडियो इस तरह प्रभावी रूप से फैल गया, और Cloudflare की ओर से वास्तविक, अर्थपूर्ण सुधारों तथा platform issues के समाधान तक बात पहुँच गई

  • बहुत ही बेहतरीन तरह से तैयार किया गया PR है। इस पोस्ट को तैयार करने वालों की तारीफ़ बनती है

    • एक पुराने cf customer के तौर पर कहूँ तो, cf सिर्फ ब्लॉग या open source लेखन में ही शानदार नहीं है, बल्कि infra companies में service support के मामले में भी सबसे बेहतर है। team members, जिनमें kenton भी शामिल हैं, अक्सर Discord पर सीधे users की मदद करते हैं या feedback स्वीकार करते हैं, और bugs या issues पर सीधे ज़िम्मेदार engineer से बात हो जाती है। मेरे द्वारा सुझाए गए PRs और feature requests भी बिना ज़्यादा प्रक्रिया के तेज़ी से शामिल किए गए हैं। दूसरी बड़ी कंपनियों की तुलना में बहुत कम दाम पर मुझे कहीं बेहतर support मिल रहा है

    • धन्यवाद! यह PR और पोस्ट Workers टीम के engineers ने 100% पहल करके plan और तैयार किया था, और मैं भी उसका हिस्सा था

  • इस पोस्ट का लिखने का तरीका, जानकारी को तोड़कर समझाना, और खुली चर्चा—सब बहुत पसंद आया। Cloudflare workers टीम पर भरोसा बढ़ा है

  • मेरे हिसाब से SvelteKit बहुत तेज़ है, और Next.js उसके मुकाबले काफ़ी धीमा है

    • यह काफ़ी उचित निष्कर्ष है

    • उम्मीद है कि SvelteKit, Astro, TanStack जैसे व्यावहारिक frameworks जल्द ही NextJS की जटिलता की जगह ले लें

  • ऐसे उदाहरण बताते हैं कि competition और independent benchmarks क्यों ज़रूरी हैं। इससे कमज़ोर performance वाली services भी सुधार के लिए मजबूर होती हैं

    • ऐसी कोशिश तभी असरदार होती है जब आप प्रोडक्ट की सच में परवाह करते हों

    • independent benchmarks पहले से मौजूद हैं

  • Cloudflare ने नतीजों को विनम्रता से स्वीकार किया और रचनात्मक तरीके से सुधार किया, यह प्रभावशाली लगा

  • यह एक शानदार लेख है जो मुद्दे पर केंद्रित रहा और दोषारोपण नहीं किया। लेकिन यह बात हैरान करने वाली थी कि Cloudflare ने generation size जैसी चीज़ों को पहले से बेहतर monitor और tune नहीं किया था। JVM performance tuning में generation size setting को मैं एक बुनियादी चीज़ मानता रहा हूँ

    • जब भी हम कुछ ठीक करते हैं, हम हमेशा transparency को प्राथमिकता देते हैं, भले ही उससे हम थोड़े मूर्ख ही क्यों न दिखें। आगे चलकर हम इस हिस्से की logging और tracing भी और मज़बूत करेंगे। सामान्य तौर पर मेरा मानना है कि GC को यथासंभव अपने आप environment के अनुसार ढलना चाहिए। यानी अगर users को पैरामीटर हाथ से बहुत ज़्यादा सेट करने पड़ें, तो GC लेखक के नज़रिए से वह लगभग हार जैसी बात है। इस बार दिशा यह है कि जो tuning सही तरह काम नहीं कर रही थी उसे <i>हटा</i> दिया जाए, और V8 को खुद young gen size बेहतर ढंग से तय करने दिया जाए