২৩ সেপ, ২০২৫·5 মিনিট
ZSTD বনাম Brotli বনাম GZIP: API কম্প্রেশন নির্বাচন
API-এর জন্য ZSTD, Brotli এবং GZIP তুলনা: গতি, কমপ্রেশন অনুপাত, CPU খরচ, এবং JSON ও বাইনারি পে-লোডের জন্য প্রোডাকশনে ব্যবহারযোগ্য ডিফল্টস।
API-এর জন্য ZSTD, Brotli এবং GZIP তুলনা: গতি, কমপ্রেশন অনুপাত, CPU খরচ, এবং JSON ও বাইনারি পে-লোডের জন্য প্রোডাকশনে ব্যবহারযোগ্য ডিফল্টস।
API রেসপন্স কমপ্রেশন মানে আপনার সার্ভার রেসপন্স বডি (সাধারণত JSON) পাঠানোর আগে ছোট বাইট স্ট্রিমে এনকোড করে। ক্লায়েন্ট (ব্রাউজার, মোবাইল অ্যাপ, SDK, বা অন্য সার্ভিস) তারপর সেটি ডিকমপ্রেস করে। HTTP-এ এটি Accept-Encoding (ক্লায়েন্ট কী সমর্থন করে) এবং Content-Encoding (সার্ভার কোনটি বেছে নিয়েছে) মতো হেডার দিয়ে আলোচনা করা হয়।
কমপ্রেশন মূলত আপনাকে তিনটি জিনিস দেয়:
বিনিময় সরল: কমপ্রেশন ব্যান্ডউইথ বাঁচায় কিন্তু CPU (কমপ্রেস/ডিকমপ্রেস) এবং কখনও কখনও মেমোরি (বাফার) খরচ করে। উপযুক্ততা নির্ভর করে আপনার বটলনেকের ওপর।
কমপ্রেশন সাধারণত জ্বলে ওঠে যখন রেসপন্সগুলো:
বড় JSON তালিকা (ক্যাটালগ, সার্চ রেজাল্ট, অ্যানালিটিক্স) ফিরিয়ে দিলে কমপ্রেশন প্রায়ই সহজ যে কোনো ফল।
কমপ্রেশন সাধারণত CPU-এর দিক থেকে খারাপ ব্যবহার যখন রেসপন্সগুলো:
ZSTD vs Brotli vs GZIP বেছে নেওয়ার সময় বাস্তব সিদ্ধান্ত সাধারণত তিন জিনিসের মধ্যে ভারসাম্য:
নিচের সব কিছুই এই তিনটির ভারসাম্য নিয়ে—আপনার API এবং ট্রাফিক প্যাটার্ন অনুযায়ী।
তিনটি কিছুকিছুই পে-লোড সাইজ কমায়, কিন্তু আলাদা কনস্ট্রেইন্টে অনুকূলিত: গতি, কমপ্রেশন রেশিও, এবং সামঞ্জস্য।
ZSTD গতি: যখন আপনার API টেইল লেটেন্সির প্রতি সংবেদনশীল বা সার্ভার CPU-কনসার্ন থাকে তখন বেশ উপকারী। এটি এত দ্রুত কমপ্রেস করতে পারে যে ওভারহেড প্রায়শই নেটওয়ার্ক সময়ের তুলনায় নগণ্য—বিশেষত মধ্যম-থেকে-বড় JSON রেসপন্সে।
Brotli কমপ্রেশন রেশিও: যখন ব্যান্ডউইথ প্রধান বাধা (মোবাইল ক্লায়েন্ট, খরচবহুল egress, CDN-হেভি ডেলিভারি) এবং রেসপন্সগুলো মূলত টেক্সট হলে এটি প্রায়ই জিতে যায়। ছোট পে-লোডগুলোও মূল্যবান হতে পারে যদি কমপ্রেশন একটু বেশি সময় নেয়।
GZIP সামঞ্জস্য: যখন সর্বোচ্চ ক্লায়েন্ট সাপোর্ট দরকার এবং আলোচনা ঝুঁকি কম রাখতে হবে (পুরানো SDK, এমবেডেড ক্লায়েন্ট, লিগ্যাসি প্রক্সি) তখন উপযুক্ত। এটি সর্বদাই সুরক্ষিত বেসলাইন যদিও এটি সর্বোত্তম পারফর্মার না।
কমপ্রেশন "লেভেল" হলো প্রিসেট যা CPU টাইম বনাম আউটপুট ছোট করা-এর মধ্যে ট্রেড করে:
তিনটোর জন্যই ডিকমপ্রেশন সাধারণত অনেক সস্তা, কিন্তু খুব উচ্চ স্তরগুলো ক্লায়েন্ট CPU/ব্যাটারিতেও প্রভাব ফেলতে পারে—বিশেষত মোবাইলে।
কমপ্রেশন প্রায়ই বিক্রি করা হয় "ছোট রেসপন্স = দ্রুত API" হিসেবে। এটি অনেক সময় সত্য, বিশেষত ধীর বা খরচবহুল নেটওয়ার্কে—কিন্তু স্বয়ংক্রিয় নয়। যদি কমপ্রেশন সার্ভার-সাইডে যথেষ্ট CPU সময় যোগ করে, তাহলে আপনি কম বাইট থাকা সত্ত্বেও ধীর অনুরোধ পেতে পারেন।
এটি দুটি খরচ আলাদা করে দেখলে সুবিধা হয়:
উচ্চ কমপ্রেশন রেশিও ট্রান্সফার টাইম কমাতে পারে, কিন্তু যদি কমপ্রেশন প্রতি রেসপন্সে (উদাহরণস্বরূপ) 15–30 ms CPU যোগ করে, আপনি দ্রুত সংযোগে সময় হারাতে পারেন।
লোড বাড়লে, কমপ্রেশন পি৯৫/পি৯৯ লেটেন্সিকে গড় পি৫০-এর তুলনায় বেশি ক্ষতি করতে পারে। CPU ব্যবহার বাড়লে অনুরোধগুলো কিউতে লাগে। কিউয়িং ছোট পার‑রিকুয়েস্ট খরচগুলো বড় দেরিতে রূপান্তর করে—গড় লেটেন্সি ঠিক থাকতে পারে, কিন্তু সবচেয়ে ধীর ব্যবহারকারীরা কষ্ট পায়।
অনুমান করবেন না। A/B টেস্ট বা স্টেজড রোলআউট চালান এবং তুলনা করুন:
বাস্তব ট্র্যাফিক প্যাটার্ন ও পে-লোড দিয়ে পরীক্ষা করুন। "সেরা" কমপ্রেশন লেভেলটি সেটি যা মোট সময় কমায়, কেবল বাইট নয়।
কমপ্রেশন "ফ্রি" নয়—এটি কাজকে নেটওয়ার্ক থেকে CPU ও মেমরির দিকে সরায়। API-তে এটি রিকোয়েস্ট হ্যান্ডলিং টাইম বাড়ানো, বড় মেমরি ফুটপ্রিন্ট, এবং কখনও ক্লায়েন্ট-সাইড ধীরতা হিসেবে দেখা দেয়।
সর্বাধিক CPU খরচ হয় রেসপন্সগুলো কমপ্রেস করতে। কমপ্রেশন প্যাটার্ন খুঁজে বের করে, স্টেট/ডিকশনারি বানায়, এবং এনকোডেড আউটপুট লেখে।
ডিকমপ্রেশন সাধারণত সস্তা, কিন্তু এখনও প্রাসঙ্গিক:
যদি আপনার API আগে থেকেই CPU-বাউন্ড হয়, উচ্চ কমপ্রেশন স্তর চালু করলে টেইল লেটেন্সি বাড়তে পারে।
কিছুভাবে কমপ্রেশন মেমরি ব্যবহার বাড়াতে পারে:
কনটেইনারাইজড পরিবেশে, উচ্চ পিক মেমরি OOM কিল বা ডেন্সিটি কমায়।
কমপ্রেশন প্রতি রেসপন্সে CPU চক্র বাড়ায়, প্রতি ইন্সট্যান্স থ্রুপুট কমায়। ফলে অটোস্কেলিং তাড়াতাড়ি ট্রিগার হতে পারে এবং খরচ বাড়তে পারে। সাধারণ প্যাটার্ন: ব্যান্ডউইথ কমে, কিন্তু CPU খরচ বাড়ে—সুতরাং কোন রিসোর্স আপনার জন্য দামী তা বিবেচনা করে সিদ্ধান্ত নিন।
মোবাইল বা কম শক্তির ডিভাইসে ডিকম্প্রেশন রেন্ডারিং, JavaScript এক্সিকিউশন, এবং ব্যাটারির সাথে প্রতিযোগিতা করে। একটি ফরম্যাট যা কয়েক KB বাঁচায় কিন্তু ডিকমপ্রেস করতে বেশি সময় নেয় তা ধীর অনুভুত হতে পারে, বিশেষত যখন "ব্যবহারযোগ্য ডেটা" পর্যন্ত সময় গুরত্বপূর্ণ।
Zstandard (ZSTD) একটি আধুনিক কমপ্রেশন ফরম্যাট যা শক্তিশালী রেশিও দিতে ডিজাইন করা হয়েছে যতক্ষণ না আপনার API ধীর হয়ে যায়। অনেক JSON-ভিত্তিক API-র জন্য এটি একটি শক্তিশালী "ডিফল্ট": GZIP-র চেয়ে লক্ষণীয়ভাবে ছোট রেসপন্স একই বা নীচের লেটেন্সিতে, এবং ক্লায়েন্টে অত্যন্ত দ্রুত ডিকমপ্রেশন।
ZSTD সবচেয়ে মূল্যবান যখন আপনি এন্ড-টু-এন্ড সময় নিয়ে চিন্তা করেন, কেবল ছোট বাইট নিয়ে নয়। এটি সাধারণত দ্রুত কমপ্রেস করে এবং খুব দ্রুত ডিকমপ্রেস করে—API যেখানে প্রতিটি মিলিসেকেন্ড গুরুত্বপূর্ণ সেখানে উপকারী।
এটি বিভিন্ন পে-লোড সাইজে ভাল কাজ করে: ছোট-থেকে-মধ্যম JSON প্রায়ই লক্ষ্যনীয় লাভ দেয়, আর বড় রেসপন্স আরও উপকৃত হতে পারে।
অধিকাংশ API-র জন্য নীচু স্তর দিয়ে শুরু করুন (সাধারণত level 1–3)। এগুলো প্রায়ই লেটেন্সি/সাইজ ট্রেড-অফে সেরা।
উচ্চ স্তর ব্যবহার করুন যদি:
প্রগম্যাটিক কৌশল: একটি নীচু গ্লোবাল ডিফল্ট, তারপর নির্দিষ্ট "বড় রেসপন্স" এন্ডপয়েন্টগুলোর জন্য স্তর বাড়ান।
ZSTD স্ট্রিমিং সাপোর্ট করে, যা বড় রেসপন্সে পিক মেমরি কমাতে এবং আগেই ডাটা পাঠানো শুরু করতে সাহায্য করে।
ডিকশনারি মোড তাদের জন্য বড় লাভ করতে পারে যারা অনেক অনুরূপ অবজেক্ট ফেরত দেয় (পুনরাবৃত্তি কী, স্থিতিশীল স্কিমা)। এটি সবচেয়ে কার্যকর যখন:
সার্ভার-সাইডে সাপোর্ট বহু স্ট্যাকে সহজ, কিন্তু ক্লায়েন্ট সামঞ্জস্যই শেষ সিদ্ধান্তের কথা। কিছু HTTP ক্লায়েন্ট, প্রক্সি, এবং গেটওয়ে এখনও ডিফল্টভাবে Content-Encoding: zstd অ্যাডভারটাইস বা গ্রহণ করে না।
তৃতীয় পক্ষ কনজিউমার থাকলে একটা ফ্যালব্যাক (সাধারণত GZIP) রাখুন এবং Accept-Encoding-এ স্পষ্টভাবে থাকলে ZSTD চালু করুন।
Brotli টেক্সট হাড়ানোর জন্য ডিজাইন করা—JSON, HTML, এবং অন্যান্য "শব্দসমৃদ্ধ" পে-লোডে এটি প্রায়ই GZIP-কে হারায়, বিশেষত উচ্চ লেভেলে।
টেক্সট-ভিত্তিক রেসপন্স হল Brotli-র স্বার্থক্ষেত্র। বড় JSON ডকুমেন্ট (ক্যাটালগ, সার্চ রেজাল্ট, কনফিগ ব্লব) পাঠালে Brotli উল্লেখযোগ্যভাবে বাইট কাটতে পারে, যা ধীর নেটওয়ার্কে ও egress খরচ কমাতে সাহায্য করে।
যখন আপনি একবার কমপ্রেস করে বহুবার সার্ভ করতে পারেন (ক্যাশেবল রেসপন্স, ভার্সনড রিসোর্স), উচ্চ-লেভেল Brotli মূল্যবান—কারণ CPU খরচ বহু অনুরোধে আমর্টাইজ করা যায়।
ডাইনামিক API রেসপন্স (প্রতিটি অনুরোধে জেনারেট করা) ক্ষেত্রে Brotli-র সেরা রেশিও প্রায়ই উচ্চ স্তর চাইবে যা CPU-মহন্ত করে এবং লেটেন্সি বাড়ায়। কমপ্রেশন সময় যুক্ত করলে বাস্তব জগতের জয় ZSTD (বা ভাল-টিউন করা GZIP)-এর উপরে অপেক্ষাকৃত ছোট হতে পারে।
এটি সেইসব পে-লোডে কম আকর্ষণীয় যা ভালভাবে কমপ্রেস করে না (আগেই কমপ্রেস করা ডাটা, অনেক বাইনারি ফরম্যাট)। সে ক্ষেত্রে কেবল CPU নষ্ট হবে।
ব্রাউজার সাধারণত HTTPS-এ Brotli ভালভাবে সাপোর্ট করে, তাই ওয়েব ট্রাফিকের জন্য জনপ্রিয়। নন-ব্রাউজার API ক্লায়েন্ট (মোবাইল SDK, IoT ডিভাইস, পুরানো HTTP স্ট্যাক) এ সাপোর্ট অনিয়মিত হতে পারে—ঠিকভাবে Accept-Encoding সংবাদ বিনিময় করুন এবং একটি ফ্যালব্যাক (সাধারণত GZIP) রাখুন।
GZIP এখনও ডিফল্ট উত্তর API কম্প্রেশনের কারণ এটি সর্বজনীনভাবে সমর্থিত। প্রায় প্রতিটি HTTP ক্লায়েন্ট, ব্রাউজার, প্রক্সি, এবং গেটওয়ে Content-Encoding: gzip বুঝে, এবং এই পূর্বানুমেয়তা গুরুত্বপূর্ণ যখন আপনি সম্পূর্ণভাবে নিয়ন্ত্রণ করেন না যে আপনার সার্ভার ও ব্যবহারকারীর মধ্যে কী আছে।
সুবিধা এ না যে GZIP "সেরা"—বরং এটি খুব কমই ভুল। অনেক প্রতিষ্ঠান বছরের অভিজ্ঞতা, ওয়েব সার্ভারে সংবেদনশীল ডিফল্ট এবং কম সারপ্রাইজ নিয়ে কাজ করে।
API পে-লোডের (সাধারণত JSON) জন্য মাঝারি-থেকে-নীচু স্তরই সেরা। স্তর 1–6 সাধারণত বেশিরভাগ সাইজ হ্রাস দেয় এবং CPU যুক্তিযুক্ত রাখে।
উচ্চ স্তর (8–9) সামান্য বাড়তি সাইজ কেটে দিতে পারে, কিন্তু ডাইনামিক অনুরোধ-প্রতিস্বরের ক্ষেত্রে অতিরিক্ত CPU সাধারণত লাভজনক নয়।
আধুনিক হার্ডওয়্যারে, GZIP সাধারণত ZSTD-এর তুলনায় ধীর এবং Brotli-র সেরা রেশিও মেলাতে পারে না টেক্সট-ভিত্তিক কনটেন্টে। বাস্তব API লোডে এর অর্থ:
পুরানো ক্লায়েন্ট, এমবেডেড ডিভাইস, কর্পোরেট প্রক্সি, বা লিগ্যাসি গেটওয়ে সাপোর্ট করতে হলে GZIP নিরাপদ পছন্দ। কিছু ইন্টারমিডিয়ারি অজানা এনকোডিং স্ট্রিপ করবে, ঠিকভাবে পাস-through করবে না, বা আলোচনা ভাঙিয়ে দিতে পারে—GZIP-এ এমন সমস্যাগুলি কম দেখা যায়।
মিশ্র বা অনিশ্চিত পরিবেশে GZIP দিয়ে শুরু করে (এবং যেখানে আপনি পুরো পথটি নিয়ন্ত্রণ করেন সেখানে ZSTD/Brotli যোগ করা) সাধারণত সবচেয়ে যেখানে নিরাপদ রোলআউট কৌশল।
কমপ্রেশন জয় কেবল অ্যালগরিদমের উপর নির্ভর করে না। সবচেয়ে বড় চালক হলো আপনি কী ধরণের ডাটা পাঠান। কিছু পে-লোড ZSTD, Brotli, বা GZIP দিয়ে উল্লেখযোগ্যভাবে ছোট হয়; অন্যগুলো প্রায়ই অচল এবং কেবল CPU জ্বালায়।
টেক্সট-ভিত্তিক রেসপন্স খুব ভাল কমপ্রেস করে কারণ এতে পুনরাবৃত্ত কী, হোয়াইটস্পেস, এবং পূর্বানুমেয় প্যাটার্ন থাকে।
নিয়ম: যত বেশি পুনরাবৃত্তি ও স্ট্রাকচার, তত ভালো অনুপাত।
Protocol Buffers এবং MessagePack মতো বাইনারি ফরম্যাট JSON-র চেয়ে কমপ্যাক্ট, কিন্তু তারা "র্যান্ডম" নয়। তবুও এদের মধ্যে বারবার ট্যাগ, সাদৃশ্যপূর্ণ রেকর্ড লেআউট, এবং পূর্বানুমেয় সিকোয়েন্স থাকতে পারে।
অর্থাৎ এগুলো প্রায়ই এখনও কমপ্রেসযোগ্য, বিশেষত বড় রেসপন্স বা লিস্ট-ভিত্তিক এন্ডপয়েন্টে। একমাত্র নির্ভরযোগ্য উত্তর হলো আপনার বাস্তব ট্র্যাফিক নিয়ে পরীক্ষা করা: একই এন্ডপয়েন্টে কমপ্রেশন চালু/বন্ধ করে সাইজ এবং লেটেন্সি তুলুন।
অनेक ফরম্যাট নিজের মধ্যে আগে থেকেই কমপ্রেস করে। উপরন্তু HTTP রেসপন্সে আবার কমপ্রেস করলে সামান্যই লাভ হয় কিংবা আকার বাড়তে পারে।
এসবের জন্য সাধারণত কনটেন্ট টাইপ অনুযায়ী কমপ্রেশন ডিসেবল করা হয়।
সরল পদ্ধতি: শুধুমাত্র যখন রেসপন্স একটি ন্যূনতম আকার পেরিয়ে যায় তখন কমপ্রেশন চালু করুন।
Content-Encoding সক্ষম করা।এটি CPU-কে তাদের কাজগুলিতেই রাখে যেখানে কমপ্রেশন প্রকৃতপক্ষে ব্যয়/লাভ যোগ করে।
কমপ্রেশন তখনই মসৃণভাবে কাজ করে যখন ক্লায়েন্ট ও সার্ভার এনকোডিং নিয়ে একমত হয়। এই সম্মতি Accept-Encoding (ক্লায়েন্ট পাঠায়) এবং Content-Encoding (সার্ভার জানায়) দিয়ে হয়।
ক্লায়েন্ট কী ডিকোড করতে পারে তা বিজ্ঞাপন করে:
GET /v1/orders HTTP/1.1
Host: api.example
Accept-Encoding: zstd, br, gzip
সার্ভার একটি বেছে নিয়ে জানায়:
HTTP/1.1 200 OK
Content-Type: application/json
Content-Encoding: zstd
যদি ক্লায়েন্ট `Accept-Encoding: gzip` পাঠায় এবং আপনি `Content-Encoding: br` পাঠান, সেই ক্লায়েন্ট হয়তো বডি পার্স করতে ব্যর্থ হবে। ক্লায়েন্ট যদি `Accept-Encoding` না পাঠায়, সাধারণত নিরাপদ ডিফল্ট হলো কোন কমপ্রেশন না পাঠানো।
### সার্ভার-সাইড অগ্রাধিকারের ক্রম বেছে নেওয়া
API-র জন্য একটি ব্যবহারিক অর্ডার প্রায়ই হতে পারে:
- প্রথমে `zstd` (দ্রুত/ভালো রেশিও ব্যালান্স)
- তারপর `br` (প্রায়ই ছোট, কখনও ধীর)
- তারপর `gzip` (সর্বাধিক সামঞ্জস্য)
অর্থাত্: `zstd > br > gzip`.
এটি সার্বজনীন নয়: যদি আপনার ট্র্যাফিক প্রায়ই ব্রাউজার-ভিত্তিক হয় তবে `br`-কে বেশি অগ্রাধিকার দিতে পারেন; যদি পুরানো মোবাইল ক্লায়েন্ট বেশি থাকে, `gzip` নিরাপদে টেনে রাখুন।
### Vary: Accept-Encoding এবং ক্যাশিং
যদি একটি রেসপন্স বিভিন্ন এনকোডিংয়ে পরিবেশিত হতে পারে, যোগ করুন:
```http
Vary: Accept-Encoding
না হলে CDN বা প্রক্সি gzip (বা zstd) ভার্শন ক্যাশ করে এমন ক্লায়েন্টকে সেটাই দেবে যারা সেই এনকোডিং চায় না বা ডিকোড করতে পারে না।
কিছু ক্লায়েন্ট সাপোর্ট দাবি করে কিন্তু বাগি ডিকোডার থাকতে পারে। টেকসই থাকার জন্য:
zstd ডিকোড ত্রুটি বাড়ে তবে সাময়িকভাবে gzip-এ ফ্যালব্যাক করুন।আলোচনাকে প্রতিটি ক্লায়েন্ট ভাঙা না করা এই লক্ষ্যেই—প্রতি বাইট না কাটা।
API কমপ্রেশন শূন্যস্থান নয়। আপনার ট্রান্সপোর্ট প্রোটোকল, TLS ওভারহেড, এবং কোন CDN বা গেটওয়ে মাঝখানে আছে তা বাস্তব ফলাফল পরিবর্তন করতে পারে—বা ভুল কনফিগে ক্ষেত্রে ভেঙে দিতে পারে।
HTTP/2-এ একক TCP সংযোগে একাধিক অনুরোধ শেয়ার হয়। এটি কানেকশন ওভারহেড কমায়, কিন্তু প্যাকেট লস হলে সব স্ট্রিম স্টল হতে পারে TCP হেড‑অফ‑লাইন ব্লকিং-এর কারণে। কমপ্রেশন রেসপন্স বডি ছোট করে এই সমস্যার পরিমাণ কমাতে পারে—নেটওয়ার্ক-স্টাকেই আটকে থাকা ডাটা কমে।
HTTP/3 QUIC (UDP)-এর উপর চলে এবং স্ট্রিমগুলোর মধ্যে TCP-র মতো হেড‑অফ‑লাইন ব্লকিং এড়ায়। তবে পে-লোড সাইজ এখনও গুরুত্বপূর্ণ—হারে-ফলে লাভটা প্রায়শই ব্যান্ডউইথ সাশ্রয় ও "টাইম টু লাস্ট বাইট" তে দ্রুততা হিসেবে দেখা যায়, নাটকীয় লেটেন্সি হ্রাস নয়। বাস্তবে, কমপ্রেশন এখনও মূল্যবান।
TLS নিজেও CPU খরচ করে (হ্যান্ডশেক, এনক্রিপশন/ডিক্রিপশন)। উচ্চ স্তরের কমপ্রেশন যোগ করলে বিশেষত স্পাইক সময়ে CPU সীমা ছাড়িয়ে যেতে পারে। এজন্যই প্রোডাকশনে "দ্রুত কমপ্রেস+ভাল রেশিও" সেটিংগুলি প্রায়ই "সর্বোচ্চ রেশিও"-র চেয়ে ভাল ফল দেয়।
কিছু CDN/gateway নির্দিষ্ট MIME টাইপ অটোম্যাটিকালি কমপ্রেস করে, অন্যরা অরিজিন যা পাঠায় তা পাস করে। কিছু কনফিগারেশন ভুল হলে Content-Encoding-ই নর্মালাইজ বা রিমুভ করতে পারে।
প্রতি রুটে আচরণ যাচাই করুন, এবং নিশ্চিত করুন Vary: Accept-Encoding রাখা হয় যাতে ক্যাশ সঠিক থাকে।
এজে ক্যাশ করলে আলাদা এনকোডিং অনুযায়ী আলাদা ভ্যারিয়েন্ট স্টোর করা বিবেচনা করুন (gzip/br/zstd) যাতে প্রতি হিট‑এ আবার কমপ্রেস না করতে হয়। অরিজিনে ক্যাশ করলে ওয়াজ এজে নেগোসিয়েট করে একাধিক এনকোডিং ক্যাশ করতে পারেন।
মূল কথা: সঙ্গতি—সঠিক Content-Encoding, সঠিক Vary, এবং কে কমপ্রেশন করছে তা স্পষ্ট।
Accept-Encoding: br এডভারটাইস করলে Brotli পছন্দ করুন। ব্রাউজারগুলো সাধারণত Brotli দক্ষভাবে ডিকোড করে এবং টেক্সট রেসপন্সে সাইজ‑রিডাকশনে উপকারী।শুরুতেই এমন স্তর বেছে নিন যা পরিমাপযোগ্য ও অবাক করবে না:
যদি শক্তিশালী অনুপাত দরকার হয়, প্রোড‑লাইক নমুনা নিয়ে যাচাই করে p95/p99 মনিটর করুন।
ছোট রেসপন্সে কমপ্রেস করা CPU‑এর চেয়ে কম সাশ্রয় হয়। একটি ব্যবহারিক শুরু পয়েন্ট:
টিউন করুন: (1) বাইটস সেভড, (2) যোগ করা সার্ভার সময়, (3) এন্ড‑টু‑এন্ড লেটেন্সি পরিবর্তন তুলনা করে।
কমপ্রেশন একটি ফিচার ফ্ল্যাগ-এর পেছনে চালু করুন, তারপর per-route config দিন (উদাহরণ: /v1/search‑এ চালু, ছোট এন্ডপয়েন্টে বন্ধ)। ক্লায়েন্ট‑অপ্ট‑আউট দিন Accept-Encoding: identity দিয়ে ডিবাগিং ও এজ ক্লায়েন্টের জন্য। সর্বদা Vary: Accept-Encoding রাখুন।
যদি আপনি দ্রুত API তৈরি করে প্রোডাকশনে টিউন করেন (উদাহরণ: React frontend + Go backend), কমপ্রেশন হলো সেই "ছোট কনফিগ, বড় প্রভাব" নইব। কডার.ai-র মতো প্ল্যাটফর্মে টিমগুলো দ্রুত প্রোটোটাইপ ডেপ্লয় করে তারপর প্রোডাকশনে টিউন করে—কমপ্রেশন ও ক্যাশ হেডারের মতো সেটিংস তখনই রূপান্তর করে। বাস্তব শিক্ষা: কমপ্রেশনকে একটি পরফরম্যান্স ফিচার হিসেবে আচরণ করুন, ফ্ল্যাগের পেছনে শিপ করুন, এবং p95/p99 মেপে সিদ্ধান্ত নিন।
কমপ্রেশন চেঞ্জ সহজে শিপ করা যায় কিন্তু প্রোডে ভুল করা সহজ। এটিকে প্রোডাকশন ফিচার হিসেবে চালান: ধীরে রোলআউট, প্রভাব মাপুন, এবং রোলব্যাক সহজ রাখুন।
ক্যানারিতে শুরু করুন: নতুন Content-Encoding (যেমন zstd) ট্র্যাফিকের ছোট অংশে বা একটি অভ্যন্তরীণ ক্লায়েন্টে চালু করুন।
তারপর ধীরে র্যাম্প করুন (1% → 5% → 25% → 100%), যদি মেট্রিকগুলো খারাপ হয় থামান।
সহজ রোলব্যাক রাখুন:
gzip-এ ফ্যালব্যাক করেকমপ্রেশনকে পরফরম্যান্স ও রিলায়েবিলিটি দুটোই হিসেবে মনিটর করুন:
যখন কিছু ভেঙে যায়, সাধারণত:
Content-Encoding আছে কিন্তু বডি কমপ্রেস করা নেই (বা উল্টো)Accept-Encoding উপেক্ষা করা বা ক্লায়েন্ট না চাওয়া এনকোডিং ফেরত দেয়াContent-Length, বা প্রক্সি/CDN হস্তক্ষেপক্লিয়ারলি ডকুমেন্ট করুন সমর্থিত এনকোডিং:
Accept-Encoding: zstd, br, gzipContent-Encoding: zstd (বা ফ্যালব্যাক)যদি আপনি SDK শিপ করেন, ছোট কপি‑পেস্টযোগ্য ডিকোড উদাহরণ দিন এবং কোন মিনিমাম ভার্সন ব্রোলি/জিএসটিডি সাপোর্ট করে তা উল্লেখ করুন।
যখন রেসপন্সগুলি টেক্সট-ভিত্তিক (JSON/GraphQL/XML/HTML), মধ্যম থেকে বড় আকারের, এবং ব্যবহারকারীরা ধীর/খরচবহুল নেটওয়ার্কে থাকে বা আপনি উল্লেখযোগ্য egress খরচ দেন— তখন রেসপন্স কমপ্রেশন চালু করা যুক্তিযুক্ত।
যখন রেসপন্স খুব ছোট, আগেই কম্প্রেস করা মিডিয়া (JPEG/MP4/ZIP/PDF), অথবা আপনার সার্ভিস CPU-বাউন্ড এবং প্রতিটি অনুরোধে অতিরিক্ত কাজ করলে p95/p99 লেটেন্সি বাড়বে— সেইসব ক্ষেত্রে কমপ্রেশন বাদ দেওয়া বা উচ্চ থ্রেশহোল্ড রাখা বুদ্ধিমানের কাজ।
কারণ এটি ব্যান্ডউইথকে CPU এবং কখনও কখনও মেমোরির বিপরীতে বিনিময় করে। কমপ্রেশন সময় সার্ভারকে বাইট পাঠানো শুরু করার আগে অতিরিক্ত CPU সময় নেয় (TTFB বাড়াতে পারে), এবং লোড বাড়লে এটি কিউয়িং বাড়িয়ে দিতে পারে—ফলে পুটির-লেটেন্সি (tail latency) খারাপ হতে পারে, যদিও মোট বা গড় লেটেন্সি উন্নত হতে পারে। সুতরাং সর্বোত্তম সেটিংটি সেইটি যা সর্বসমেত "এন্ড-টু-এন্ড" সময় কমায়, কেবল বাইট নয়।
অনেক API-র জন্য ব্যবহারিক ডিফল্ট অগ্রাধিকার হতে পারে:
zstd প্রথম (দ্রুত, ভালো অনুপাত)br (টেক্সটের জন্য প্রায়ই ছোট, কিন্তু CPU বেশি লাগতে পারে)gzip (সবচেয়ে ব্যাপক সামঞ্জস্য)সবসময় ক্লায়েন্টের অনুযায়ী সিদ্ধান্ত নিন এবং একটি নিরাপদ ফ্যালব্যাক রাখুন (সাধারণত বা )।
কম শুরু করুন এবং পরিমাপ করুন।
হ্যাঁ—একটি ন্যূনতম রেসপন্স সাইজ থ্রেশহোল্ড ব্যবহার করুন যাতে আপনি খুব ছোট পে-লোডে CPU নষ্ট না করেন।
এন্ডপয়েন্ট অনুযায়ী টিউন করুন: সংরক্ষিত বাইট বনাম যোগ করা সার্ভার সময় এবং p50/p95/p99 লেটেন্সির ওপর প্রভাব তুলনা করুন।
সংরচিত ও পুনরাবৃত্তিমূলক কনটেন্ট ভাল কমপ্রেস হয়, উদাহরণ:
সংকোচন HTTP আলোচনার মাধ্যমে হওয়া উচিত:
Accept-Encoding পাঠায় (উদাহরণ: zstd, br, gzip)Content-Encoding দিয়ে উত্তর দেয়ক্লায়েন্ট যদি না পাঠায়, সাধারণত নিরাপদ ডিফল্ট হলো । এমন ফেরত দেবেন না যা ক্লায়েন্ট জানায়ইনি—তার ফলে ক্লায়েন্ট ব্যর্থ হতে পারে।
অবশ্যই যোগ করুন:
Vary: Accept-Encodingএটি CDN/proxy-কে প্রতিক্রিয়া কিভাবে ক্যাশ করতে হবে তা নির্দেশ করে—যেন একটি gzip ভ্যারিয়েন্ট ভুল করে সেই ক্লায়েন্টকে সার্ভ না করা হয় যিনি gzip ডিকোড করতে পারবেন না (বা ভিন্ন এনকোডিং চান)। যদি আপনি একাধিক এনকোডিং সাপোর্ট করেন, এই হেডারটি সঠিক ক্যাশিংয়ের জন্য অপরিহার্য।
সাধারণ ত্রুটি-মোডগুলি হলো:
ক্যানারি দিয়ে শুরু করুন: নতুন Content-Encoding (উদাহরণ: zstd) ছোট ট্র্যাফিক স্লাইসে অথবা একটি অভ্যন্তরীণ ক্লায়েন্টের জন্য চালু করুন।
তারপর ধীরে ধীরে র্যাম্প করুন (উদাহরণ: 1% → 5% → 25% → 50% → 100%), এবং যদি মূল মেট্রিকগুলো খারাপ দিকে যায় তবে বিরতি দিন।
সহজ রোলব্যাক রাখুন:
Accept-Encodinggzipidentityউচ্চ স্তরগুলো সাধারণত আকার বাড়ানোর সামান্য লাভ দেয় কিন্তু CPU বাড়ায় এবং p95/p99 খারাপ করতে পারে—পরিমাপ করে নিন।
সাধারণ পন্থা: টেক্সট-জাতীয় Content-Type-গুলোর জন্য কম্প্রেশন চালু রাখুন এবং ইতিমধ্যে কমপ্রেস করা ফরম্যাটগুলোর জন্য নিষ্ক্রিয় করুন।
Accept-EncodingContent-EncodingContent-Encoding সেট করা আছে কিন্তু বডি কমপ্রেস করা নেই বা উল্টো)Accept-Encoding উপেক্ষা করা)Content-Lengthডিবাগ করতে: কাঁচা রেসপন্স হেডারগুলো ধরুন এবং একটি পরিচিত টুল/ক্লায়েন্ট দিয়ে ডিকোমপ্রেশন যাচাই করুন।
gzip-এ ফ্যালব্যাক করে)মনিটরিং: CPU, পি৫০/পি৯৫/পি৯৯ লেটেন্সি ও TTFB, ওয়ায়ার বাইটস (কমপ্রেসড বনাম আনকমপ্রেসড), এবং এরর/টাইমআউট/ক্লায়েন্ট ডিকোড ত্রুটি লক্ষ করবেন।