উচ্চ-ফ্রিকোয়েন্সি প্রকাশনার যুগে ফ্রন্ট-এন্ড ডেলিভারির জন্য ক্যাশিং এবং কম্প্রেশন সহযোগিতাকে পুনরায় ডিজাইন করতে হবে
যেহেতু সম্পদগুলি আরও বেশি করে খণ্ডিত হয়ে যাচ্ছে এবং সংস্করণগুলি আরও ঘন ঘন হয়ে আসছে, এটি প্রায়শই কম্প্রেশন রেট নয় যা সত্যিই প্রথমে নিয়ন্ত্রণের বাইরে চলে যায়, তবে ক্যাশে কী, অভিধান সংস্করণ এবং রিটার্ন-টু-অরিজিন খরচের রিলিজ ছন্দ।
একবার ফ্রন্ট-এন্ড রিসোর্স একটি উচ্চ-ফ্রিকোয়েন্সি রিলিজ ছন্দে প্রবেশ করলে, পারফরম্যান্সের সমস্যাগুলি শীঘ্রই “ব্রটলি চালু” করার মতো সহজ হবে না। প্রথম স্ক্রীনটি ধীর হয়ে যায়, ব্যাক-টু-অরিজিন ট্রাফিক বৃদ্ধি পায় এবং এজ নোড CPU ধাক্কা দেয়। পৃষ্ঠের উপর, মনে হচ্ছে কম্প্রেশন যথেষ্ট আক্রমণাত্মক নয়। আরও গভীরে তাকালে, এটি প্রায়শই ক্যাশিং এবং কম্প্রেশন যা আলাদাভাবে অপ্টিমাইজ করা হয় এবং অবশেষে প্রকাশনার লিঙ্কে একে অপরকে দুর্বল করে।
এই ধরনের সমস্যা সাধারণত প্রথম সংস্করণে প্রকাশ করা হয় না। শুরুতে, দলটি শুধুমাত্র কিছু বিক্ষিপ্ত সংকেত দেখতে পাবে: একটি ছোট পরিবর্তন স্ট্যাটিক রিসোর্সের আঘাতের হারে বিঘ্ন ঘটায়, একটি বড় প্রচারের প্রাক্কালে প্রান্ত কম্প্রেশন CPU-তে অস্বাভাবিক বৃদ্ধি এবং গ্রেস্কেল পর্যায়ে রিটার্ন প্যাকেটের পরিমাণ অফিসিয়াল ট্র্যাফিকের সাথে মেলেনি। আপনি যদি পরীক্ষা চালিয়ে যান, ক্লুগুলি সাধারণত একই জিনিসে একত্রিত হয়: যদিও সম্পদের বিষয়বস্তু শুধুমাত্র সামান্য পরিবর্তিত হয়েছে, ক্যাশে কী, খণ্ড বিভাজন এবং সংকুচিত ইনপুট জিনিসগুলির একটি ভিন্ন সেটে পরিণত হয়েছে এবং পরিবহন স্তরটি আবার পুরো খরচটি গ্রাস করতে বাধ্য হয়েছে।
রিসোর্স হ্যাশ স্থিতিশীল না হওয়া পর্যন্ত, কম্প্রেশন সুবিধাগুলি কেবল অক্ষম।
ফ্রন্ট-এন্ড প্রজেক্টগুলি একাধিক পৃষ্ঠা, একাধিক রুট এবং একাধিক টিমের সাথে সমান্তরালভাবে প্রকাশ করার পরে, সবচেয়ে সহজে উপেক্ষিত দিক হল ফাইলের নাম স্থায়িত্ব। যতক্ষণ পর্যন্ত খণ্ড বিভাজন সামান্য প্রবাহিত হয়, এমনকি যদি ব্যবসায়িক কোড শুধুমাত্র একটি বোতামের অনুলিপি পরিবর্তন করে, চূড়ান্ত পণ্যটি পাবলিক বান্ডেলের একটি সিরিজের হ্যাশ পুনরায় লিখতে পারে। ক্যাশিং সিস্টেম যা দেখে তা হল একেবারে নতুন বস্তুর একটি ব্যাচ, এবং কম্প্রেশন সিস্টেম যা দেখে তা হল ইনপুটগুলির একটি ব্যাচ যা প্রথমবার প্রদর্শিত হয়।
এই সময়ে, সংকোচনের হার যতই বেশি হোক না কেন, এটি আঘাতের হারকে পতন থেকে বাঁচাতে পারে না। পুরানো ফাইলগুলি এখনও প্রান্ত নোডগুলিতে পড়ে রয়েছে এবং নতুন ফাইলগুলি পুনরায় কী করা হয়েছে; ব্রাউজারের স্থানীয় ক্যাশে সম্পূর্ণরূপে অবৈধ, এবং CDN-কে উত্সটি পুনরায় টানতে হবে, পুনরায় সংকুচিত করতে হবে এবং পুনরায় বিতরণ করতে হবে। সম্পূর্ণ ট্রান্সমিশন লিঙ্কের জন্য একটি ছোট ব্যবসায়িক পরিবর্তনকে বারবার কাজে পরিণত করা হয়।
সত্যিই দরকারী ক্রিয়াটি সাধারণত কম্প্রেশন স্তর সামঞ্জস্য করা চালিয়ে যাওয়া নয়, তবে প্রথমে প্রকাশিত পণ্যের স্থায়িত্ব নিয়ন্ত্রণ করা:
- ব্যবসায়িক পরিবর্তনগুলি কমাতে এবং হ্যাশ পরিবর্তনের জন্য মৌলিক প্যাকেজগুলিকে একত্রিত করতে পাবলিক নির্ভরতাগুলিকে আলাদা স্তরে কাটা হয়৷
- উচ্চ-ফ্রিকোয়েন্সি পরিবর্তনগুলি যেমন টাইমস্ট্যাম্প এবং বিল্ড নম্বর সরাসরি পণ্য সামগ্রীতে মিশ্রিত করা এড়িয়ে চলুন
- প্রতিবার কম্পাইল করার সময় রদবদল না করে একই রুটের কাছাকাছি কোডটিকে যতটা সম্ভব স্থিতিশীল অংশে পড়তে দিন।
শুধুমাত্র যখন রিসোর্স আইডেন্টিটি স্থিতিশীল হয় তখন ক্যাশে ক্রমাগত পুনঃব্যবহার করা যায় এবং কম্প্রেশন ফলাফলের ক্রমবর্ধমান মান থাকে।
উচ্চ-ফ্রিকোয়েন্সি প্রেস কনফারেন্স কম্প্রেশন সমস্যাটিকে একটি অভিধান সংস্করণের সমস্যায় পুনর্লিখন করে
সংস্থানগুলি আরও বেশি করে খণ্ডিত হওয়ার সাথে সাথে একক-ফাইল ব্রটলি বা জিজিপ এখনও গুরুত্বপূর্ণ, তবে এটি আর সবকিছু নয়। আসল খরচ ডুপ্লিকেট টুকরোগুলির দিকে স্থানান্তরিত হতে শুরু করে: ফ্রেমওয়ার্ক রানটাইম কোড, স্টাইল টেমপ্লেট, ইন্টারফেস টাইপ ডিক্লেয়ারেশন, প্যাকেজিং লেয়ার প্যাকেজর দ্বারা তৈরি করা হয়, প্রায়শই সংস্করণের ব্যাচের মধ্যে অত্যন্ত মিল থাকে। দ্রুত রিলিজ টেম্পো সহ, এই রিফগুলি বারবার স্থানান্তরিত হবে।
সমস্যা হল যে কম্প্রেশন ডিকশনারি সহজেই অপ্টিমাইজেশান থেকে ব্যাঘাতে পরিণত হতে পারে যদি এটি রিলিজ ক্যাডেন্সের সাথে পরিচালিত না হয়। যদি অভিধানটি আগে থেকে পরিবর্তন করা হয়, পুরানো পৃষ্ঠার দ্বারা উল্লেখ করা নতুন অভিধানটি অমিল হবে; অভিধানটি অনেকগুলি টুকরো টুকরো করা হয়েছে, এবং প্রান্ত নোডগুলি দ্বারা রক্ষণাবেক্ষণ করা সংস্করণগুলির সংখ্যা তীব্রভাবে বৃদ্ধি পায়; অভিধান আপডেট অনলাইন রিসোর্সের সাথে সিঙ্ক্রোনাইজ করা হয় না, এবং যে বস্তুগুলিকে আঘাত করা উচিত ছিল তা সম্পূর্ণ ট্রান্সমিশনে ফিরে আসে।
সাম্প্রতিক ফ্রন্ট-এন্ড ডেলিভারিতে এটি একটি খুব বাস্তব পরিবর্তন: ক্যাশিং কৌশল এবং কম্প্রেশন প্রোটোকল আর বিভিন্ন দল দ্বারা বজায় রাখা যায় না। রিসোর্স সংস্করণ, অভিধান সংস্করণ, এবং ক্যাশে কী স্পেস মূলত একই প্রকাশনার সমস্যা।
নীচের মত একটি শ্রেণীবিন্যাস পদ্ধতি সাধারণত “সম্পূর্ণ সাইটের জন্য ইউনিফাইড শক্তিশালী কম্প্রেশন” এর চেয়ে বেশি স্থিতিশীল:
const policy = {
immutableAssets: 'public, max-age=31536000, immutable',
releaseManifest: 'public, max-age=60, stale-while-revalidate=30',
sharedDictionary: 'versioned-by-release-train'
}
মূলটি এই তিনটি লাইনের কনফিগারেশন নয়, তবে এটি যে সীমাবদ্ধতাগুলি প্রকাশ করে: দীর্ঘ জীবন চক্র সংস্থান, সংক্ষিপ্ত জীবন চক্রের তালিকা এবং সংকুচিত অভিধান সংস্করণ একই প্রকাশের ছন্দ অনুসারে একসাথে বিকাশ করা উচিত।
উত্সে ফিরে আসার চাপ প্রায়শই ফাইলটি খুব বড় নয়, তবে ব্যর্থতার পদ্ধতিটি খুব রুক্ষ।
আরেকটি খুব সাধারণ ভুল ধারণা হল ব্যান্ডউইথ বৃদ্ধিকে সরাসরি পৃষ্ঠার ওজনের জন্য দায়ী করা। পৃষ্ঠাগুলি অবশ্যই ভারী হয়ে উঠছে, তবে অনলাইনে আরও বিপজ্জনক amps সাধারণত যাওয়ার উপায়।
আপনি যদি প্রতিবার প্রকাশ করার সময় ডিরেক্টরি, উপসর্গ বা এমনকি সমগ্র সাইটটি পরিষ্কার করেন, ক্যাশে স্তরটি তাত্ক্ষণিকভাবে তার মেমরি হারাবে৷ এই সময়ে, ফাইলের আকার বাড়তে না পারলেও, রিটার্ন-টু-অরিজিন পিক ভ্যালু নিজে থেকেই বেড়ে যাবে। উত্সটি ফেরত দেওয়ার সাথে সাথে, প্রান্তগুলি পুনরায় সংকুচিত করা হয়, বস্তুগুলিকে পুনরায় উষ্ণ করা হয় এবং ব্রাউজারটি পুনরায় ডাউনলোড করা হয়। প্রকাশনা উইন্ডোটি একটি ছোট ধাপ পরিবর্তন থেকে সম্পূর্ণ সাইট স্থানান্তরে পরিবর্তিত হবে।
এই ধরনের পরিস্থিতিতে, সবচেয়ে মূল্যবান জিনিস হল নিয়ন্ত্রণযোগ্য ব্যর্থতা ব্যাসার্ধ:
- শুধুমাত্র ম্যানিফেস্ট, এইচটিএমএল এবং পরিবর্তনযোগ্য সংস্থানগুলিকে বাতিল করুন যা আসলে পরিবর্তিত হয়েছে৷
- হ্যাশ দিয়ে স্ট্যাটিক ফাইলগুলিকে পরিষ্কার না করার চেষ্টা করুন এবং প্রাকৃতিক স্যুইচিংয়ের জন্য তাদের নতুন রেফারেন্সে হস্তান্তর করুন৷
- রিলিজটিকে “প্রথমে নতুন রিসোর্স আপলোড করুন, তারপর রেফারেন্স কাটুন, তারপরে পুরানো রিসাইকেল রিসাইকেল করুন” এর ক্রমানুসারে ভাগ করুন
স্থানান্তর খরচ সম্পর্কে যেটি সত্যিই সংবেদনশীল তা কেবল ফাইলের আকারই নয়, তবে সিস্টেম কীভাবে সিদ্ধান্ত নেয় কোন বিষয়বস্তু পুনরায় আনতে হবে।
প্রযোজ্য সীমানা রিসোর্স স্কেল এবং রিলিজ ফ্রিকোয়েন্সি সহ একসাথে নির্ধারিত হয়।
সব সাইটের জন্য সহ-ডিজাইনের এই সেটের প্রয়োজন নেই। অল্প সংখ্যক স্ট্যাটিক পেজ, একটি ছোট রিসোর্স প্যাকেজ এবং সাপ্তাহিক বা এমনকি মাসিক রিলিজ ফ্রিকোয়েন্সি সহ প্রজেক্টের জন্য প্রথাগত হ্যাশ ফাইলের নাম প্লাস ব্রোটলি প্রি-কম্প্রেশন সাধারণত যথেষ্ট স্থিতিশীল।
ক্যাশিং এবং কম্প্রেশন একসাথে দ্রুত একটি ডেলিভারি অবকাঠামো হয়ে ওঠে একবার এই বৈশিষ্ট্যগুলি স্থানান্তরিত হয়:
- গ্রেস্কেল, রোলব্যাক বা আঞ্চলিক লঞ্চ সহ দিনে একাধিকবার মুক্তি পায়৷
- ফ্রন্ট-এন্ড পণ্যটি আকারে বড়, অনেকগুলি পাবলিক নির্ভরতা রয়েছে এবং জটিল অংশের সম্পর্ক রয়েছে।
- CDN, অবজেক্ট স্টোরেজ, এজ কম্প্রেশন এবং ব্রাউজার ক্যাশিং একই সাথে ট্রান্সমিশন লিঙ্কে অংশগ্রহণ করে
- ট্র্যাফিক এত বেশি যে ক্যাশে হিট রেট এবং রিটার্ন-টু-অরিজিন পিক ভ্যালু সরাসরি খরচ এবং স্থায়িত্বকে প্রতিফলিত করবে।
ফ্রন্ট-এন্ড ডেলিভারি এই পর্যায়ে প্রবেশ করার পরে, কম্প্রেশন আর কেবল “ফাইলগুলিকে ছোট করা” নয় এবং ক্যাশিং আর কেবল “সামগ্রীর আরও কপি সংরক্ষণ করা” নয়। দুজনে মিলে যা সিদ্ধান্ত নেয় তা হল: একটি ছোট ব্যবসায়িক পরিবর্তনের জন্য, এটি কেবল আরও একটি অংশ পাঠানোর জন্য, বা সম্পূর্ণ ট্রান্সমিশন লিঙ্কটি আবার চালানোর প্রয়োজন কিনা। আপনি যত ঘন ঘন প্রকাশ করবেন, এই পার্থক্য তত বেশি ব্যয়বহুল হবে।
What to read next
Want more posts about Frontend?
Posts in the same category are usually the best next step for reading more on this topic.
View same categoryWant to keep following #Frontend?
Tags are useful for related tools, specific problems, and similar troubleshooting notes.
View same tagWant to explore another direction?
If you are not sure what to read next, return to the homepage and start from categories, topics, or latest updates.
Back home