কীভাবে সার্ভারের সমস্যা নির্ধারণ করবেন, দ্রুত সমস্যার সমাধান করবেন, সার্ভারের পারফর্ম্যান্স উন্নত করবেন এবং রিগ্রেশন প্রতিরোধ করবেন।
এক নজরে
এই নির্দেশিকা আপনাকে ৪টি ধাপে ওভারলোড হওয়া সার্ভার ঠিক করার পদ্ধতি দেখায়:
- মূল্যায়ন: সার্ভারের বাধা নির্ধারণ করুন।
- স্থিতিশীল করা: প্রভাব কমানোর জন্য দ্রুত সমাধান প্রয়োগ করা।
- উন্নত করা: সার্ভারের ক্ষমতা বৃদ্ধি ও অপ্টিমাইজ করা।
- মনিটর করা: ভবিষ্যতে সমস্যা এড়াতে অটোমেটেড টুল ব্যবহার করুন।
মূল্যায়ন করা
ট্রাফিক কোনও সার্ভারকে ওভারলোড করলে, নিম্নলিখিতগুলির মধ্যে এক বা একাধিক বাধা হয়ে দাঁড়াতে পারে: সিপিইউ, নেটওয়ার্ক, মেমরি বা ডিস্ক I/O। এর মধ্যে কোনটি বাধা সৃষ্টি করছে তা শনাক্ত করতে পারলে, সবচেয়ে প্রভাবশালী উপশমের উপর ফোকাস করা সম্ভব হয়।
- সিপিইউ: সিপিইউ ব্যবহার একটানা ৮০%-এর বেশি হলে তা খতিয়ে দেখে সমস্যার সমাধান করতে হবে। CPU-এর ব্যবহার ~৮০-৯০% হয়ে গেলে সার্ভারের পারফর্ম্যান্স প্রায়ই কমে যায় এবং ব্যবহার ১০০%-এর কাছাকাছি হয়ে গেলে আরও বেশি কমে যায়। একটি অনুরোধের জন্য CPU-এর ব্যবহার নগণ্য, তবে ট্রাফিক স্পাইকের সময় যে স্কেলে এটি করা হয় তা কখনও কখনও সার্ভারকে ওভারলোড করতে পারে। অন্য পরিকাঠামোতে অফলোডিং পরিষেবা, ব্যয়বহুল অপারেশন কমানো এবং অনুরোধের পরিমাণ সীমিত করা হলে CPU ব্যবহার কমবে।
- নেটওয়ার্ক: ট্রাফিক বেশি থাকার সময়, ব্যবহারকারীর অনুরোধ পূরণ করার জন্য প্রয়োজনীয় নেটওয়ার্ক থ্রুপুট, ক্ষমতার চেয়ে বেশি হতে পারে। হোস্টিং প্রদানকারীর উপর নির্ভর করে কিছু সাইট, মোট ডেটা ট্রান্সফারের সীমাও অতিক্রম করতে পারে। সার্ভারে এবং সার্ভার থেকে ট্রান্সফার করা ডেটার সাইজ এবং পরিমাণ কমালে এই বাধা দূর হবে।
- মেমরি: সিস্টেমে পর্যাপ্ত মেমরি না থাকলে, ডেটা স্টোরেজের জন্য ডিস্কে অফলোড করতে হবে। মেমোরির তুলনায় ডিস্ক অ্যাক্সেস করার গতি অনেক কম এবং এর ফলে সম্পূর্ণ অ্যাপ্লিকেশন স্লো হয়ে যেতে পারে। মেমরি সম্পূর্ণভাবে শেষ হয়ে গেলে, মেমরি শেষ হয়ে গেছে (OOM) সংক্রান্ত সমস্যা হতে পারে। মেমরি অ্যালোকেশন অ্যাডজাস্ট করা, মেমরি লিক ঠিক করা এবং মেমরি আপগ্রেড করার মাধ্যমে এই বাধা দূর করা যেতে পারে।
- ডিস্ক I/O: ডিস্ক থেকে ডেটা রিড বা রাইট করার হার ডিস্কের দ্বারাই সীমাবদ্ধ থাকে। ডিস্ক I/O যদি বাধা হয়ে দাঁড়ায়, তাহলে মেমরিতে ক্যাশে করা ডেটার পরিমাণ বাড়িয়ে এই সমস্যা কমানো যেতে পারে (এর ফলে মেমরির ব্যবহার বেড়ে যাবে)। এতে কাজ না হলে, আপনার ডিস্ক আপগ্রেড করতে হতে পারে।
এই গাইডে উল্লেখ করা কৌশলগুলি সিপিইউ এবং নেটওয়ার্কের বাধা দূর করার উপর ফোকাস করে। অধিকাংশ সাইটের ক্ষেত্রে, ট্রাফিক স্পাইকের সময় CPU ও নেটওয়ার্ক সবচেয়ে প্রাসঙ্গিক বাধা হয়ে দাঁড়ায়।
প্রভাবিত সার্ভারে top রান করা হল বাধাগুলি তদন্ত করার জন্য একটি ভাল শুরুর জায়গা। উপলভ্য থাকলে, আপনার হোস্টিং প্রদানকারী বা মনিটরিং টুলিং থেকে পাওয়া ঐতিহাসিক ডেটা দিয়ে এটি সম্পূর্ণ করুন।
স্থির করুন
ওভারলোড হওয়া সার্ভার দ্রুত সিস্টেমের অন্য কোথাও ক্যাসকেডিং ব্যর্থতার কারণ হতে পারে। তাই, আরও গুরুত্বপূর্ণ পরিবর্তন করার চেষ্টা করার আগে সার্ভারকে স্থিতিশীল করা গুরুত্বপূর্ণ।
রেট লিমিটিং
ইনকামিং অনুরোধের সংখ্যা সীমিত করে রেট লিমিটিং ইনফ্রাস্ট্রাকচারকে সুরক্ষিত করে। সার্ভারের পারফর্ম্যান্স খারাপ হতে থাকলে এটি আরও গুরুত্বপূর্ণ হয়ে ওঠে: রেসপন্স টাইম বেড়ে গেলে, ব্যবহারকারীরা বারবার পৃষ্ঠা রিফ্রেশ করতে থাকেন - যার ফলে সার্ভারের লোড আরও বেড়ে যায়।
এর সমাধান করুন
অনুরোধ বাতিল করার খরচ তুলনামূলকভাবে কম হলেও, আপনার সার্ভারকে সুরক্ষিত রাখার সবচেয়ে ভালো উপায় হল, আপস্ট্রিমে কোথাও রেট লিমিট করা - যেমন, লোড ব্যালেন্সার, রিভার্স প্রক্সি বা CDN-এর মাধ্যমে।
নির্দেশাবলী:
আরও পড়ুন:
HTTP ক্যাশিং
আরও বেশি করে কন্টেন্ট ক্যাশে করার উপায় খুঁজুন। কোনও রিসোর্স HTTP ক্যাশে (ব্রাউজার ক্যাশে বা CDN) থেকে সার্ভ করা গেলে, অরিজিন সার্ভার থেকে সেটির জন্য অনুরোধ করার প্রয়োজন হয় না, যার ফলে সার্ভারের লোড কমে যায়।
Cache-Control, Expires ও ETag-এর মতো HTTP হেডার থেকে বোঝা যায় যে HTTP ক্যাশে কীভাবে রিসোর্স ক্যাশে করা উচিত। এইসব হেডার অডিট ও ঠিক করলে ক্যাশিং উন্নত হবে।
যদিও সার্ভিস ওয়ার্কার ক্যাশিংয়ের জন্যও ব্যবহার করা যেতে পারে, তারা একটি আলাদা ক্যাশে ব্যবহার করে এবং সঠিক HTTP ক্যাশিংয়ের জন্য প্রতিস্থাপনের পরিবর্তে একটি পরিপূরক। এই কারণে, ওভারলোড হওয়া সার্ভার ম্যানেজ করার সময়, HTTP ক্যাশিং অপ্টিমাইজ করার উপর জোর দেওয়া উচিত।
ডায়াগনসিস করা
Lighthouse রান করুন এবং দক্ষ ক্যাশে নীতির মাধ্যমে স্ট্যাটিক অ্যাসেট পরিবেশন করুন অডিট দেখুন যাতে কম থেকে মাঝারি লাইভ থাকার সময় (TTL) সহ রিসোর্সের তালিকা দেখা যায়। তালিকাভুক্ত প্রতিটি রিসোর্সের জন্য, TTL বাড়ানো উচিত কিনা তা বিবেচনা করুন। মোটামুটি নির্দেশিকা হিসেবে:
- স্ট্যাটিক রিসোর্স দীর্ঘ TTL (১ বছর) সহ ক্যাশে করা উচিত।
- ডায়নামিক রিসোর্সকে ছোট TTL (৩ ঘণ্টা) সহ ক্যাশে করতে হবে।
এর সমাধান করুন
Cache-Control হেডারের max-age নির্দেশিকা উপযুক্ত সেকেন্ডের সংখ্যায় সেট করুন।
নির্দেশাবলী:
সাবলীল অবনমন
গ্রেসফুল ডিগ্রেডেশন হল এমন একটি স্ট্র্যাটেজি যার মাধ্যমে সিস্টেমের উপর থেকে অতিরিক্ত লোড কমানোর জন্য সাময়িকভাবে কার্যকারিতা কমিয়ে দেওয়া হয়। এই ধারণাটি বিভিন্ন উপায়ে প্রয়োগ করা যেতে পারে: যেমন, সম্পূর্ণ ফিচারযুক্ত অ্যাপ্লিকেশনের পরিবর্তে স্ট্যাটিক টেক্সট পৃষ্ঠা দেখানো, সার্চ বন্ধ করা বা কম সার্চ ফলাফল দেখানো অথবা নির্দিষ্ট কিছু ব্যয়বহুল বা অপ্রয়োজনীয় ফিচার বন্ধ করা। ব্যবসায় ন্যূনতম প্রভাব ফেলে নিরাপদে ও সহজে সরানো যায় এমন কার্যকারিতা সরানোর উপর জোর দিতে হবে।
উন্নত করুন
কন্টেন্ট ডেলিভারি নেটওয়ার্ক (CDN) ব্যবহার করুন
স্ট্যাটিক অ্যাসেট পরিবেশন করার কাজ আপনার সার্ভার থেকে কন্টেন্ট ডেলিভারি নেটওয়ার্কে (CDN) অফলোড করা যেতে পারে, যার ফলে লোড কমে যায়।
CDN-এর প্রাথমিক কাজ হল ব্যবহারকারীদের কাছাকাছি অবস্থিত সার্ভারের একটি বড় নেটওয়ার্ক প্রদান করে ব্যবহারকারীদের কাছে দ্রুত কন্টেন্ট পৌঁছে দেওয়া। তবে, বেশিরভাগ CDN কম্প্রেশন, লোড ব্যালেন্সিং ও মিডিয়া অপ্টিমাইজেশনের মতো পারফর্ম্যান্স-সম্পর্কিত অতিরিক্ত ফিচারও অফার করে।
CDN সেট-আপ করা
CDN স্কেল থেকে উপকৃত হয়, তাই আপনার নিজস্ব CDN পরিচালনা করার খুব কমই অর্থ হয়। একটি বেসিক CDN কনফিগারেশন সেট-আপ করতে খুব বেশি সময় লাগে না (~৩০ মিনিট) এবং CDN-এ পয়েন্ট করার জন্য ডিএনএস রেকর্ড আপডেট করতে হয়।
CDN-এর ব্যবহার অপ্টিমাইজ করুন
ডায়াগনসিস করা
WebPageTest রান করে এমন রিসোর্স শনাক্ত করুন যা CDN থেকে পরিবেশন করা হচ্ছে না (কিন্তু করা উচিত)। ফলাফলের পৃষ্ঠায়, CDN থেকে পরিবেশন করা উচিত এমন রিসোর্সের তালিকা দেখতে 'CDN-এর কার্যকর ব্যবহার' বিকল্পের উপরে থাকা বর্গক্ষেত্রে ক্লিক করুন।
এর সমাধান করুন
CDN কোনও রিসোর্স ক্যাশে না করলে, নিম্নলিখিত শর্তগুলি পূরণ করা হয়েছে কিনা তা চেক করুন:
- এতে
Cache-Control: publicহেডার আছে। - এতে
Cache-Control: s-maxage,Cache-Control: max-ageবাExpiresহেডার আছে। - এতে
Content-Length,Content-RangeবাTransfer-Encoding headerআছে।
কম্পিউট রিসোর্স স্কেল করুন
কম্পিউট রিসোর্স স্কেল করার সিদ্ধান্তটি সাবধানে নেওয়া উচিত। যদিও কম্পিউট রিসোর্স স্কেল করা প্রায়শই প্রয়োজন হয়, তবে সময়ের আগে এটি করলে অপ্রয়োজনীয় আর্কিটেকচারাল জটিলতা ও আর্থিক খরচ হতে পারে।
ডায়াগনসিস করা
Time To First Byte (TTFB) বেশি হলে, এটি ইঙ্গিত করে যে সার্ভার তার ক্ষমতার কাছাকাছি পৌঁছে গেছে। আপনি Lighthouse সার্ভার রেসপন্স টাইম (TTFB) কমান অডিটে এই তথ্য খুঁজে পাবেন।
আরও তদন্ত করতে, সিপিইউ-এর ব্যবহার মূল্যায়ন করার জন্য একটি মনিটরিং টুল ব্যবহার করুন। বর্তমান বা প্রত্যাশিত CPU ব্যবহার ৮০% ছাড়িয়ে গেলে, আপনার সার্ভার বাড়ানোর কথা বিবেচনা করা উচিত।
এর সমাধান করুন
লোড ব্যালেন্সার যোগ করলে, একাধিক সার্ভার জুড়ে ট্রাফিক ডিস্ট্রিবিউট করা সম্ভব হয়। লোড ব্যালেন্সার সার্ভারের পুলের সামনে থাকে এবং উপযুক্ত সার্ভারে ট্রাফিক রুট করে। ক্লাউড প্রদানকারীরা তাদের নিজস্ব লোড ব্যালেন্সার (GCP, AWS, Azure) অফার করে অথবা আপনি HAProxy বা NGINX ব্যবহার করে নিজের লোড ব্যালেন্সার সেট-আপ করতে পারেন। লোড ব্যালেন্সার সেট-আপ করা হয়ে গেলে, অতিরিক্ত সার্ভার যোগ করা যেতে পারে।
লোড ব্যালেন্সিং ছাড়াও, বেশিরভাগ ক্লাউড পরিষেবা প্রদানকারী অটোস্কেলিং (GCP, AWS, Azure) অফার করে। অটোস্কেলিং লোড ব্যালেন্সিংয়ের সাথে কাজ করে - অটোস্কেলিং অটোমেটিক কম্পিউট রিসোর্সকে নির্দিষ্ট সময়ে নির্দিষ্ট চাহিদার ভিত্তিতে স্কেল আপ ও ডাউন করে। তবে, অটোস্কেলিং কোনও ম্যাজিক নয় - নতুন ইনস্ট্যান্স অনলাইন হতে সময় লাগে এবং এর জন্য অনেক কনফিগারেশন প্রয়োজন হয়। অটোস্কেলিংয়ের সাথে অতিরিক্ত জটিলতা যুক্ত থাকে, তাই প্রথমে আরও সহজ লোড ব্যালেন্সার-ভিত্তিক সেট-আপ বিবেচনা করা উচিত।
কম্প্রেশন চালু করুন
টেক্সট-ভিত্তিক রিসোর্স gzip বা brotli ব্যবহার করে কম্প্রেস করা উচিত। Gzip এইসব রিসোর্সের ট্রান্সফার সাইজ ~৭০% কমাতে পারে।
ডায়াগনসিস করা
কোন রিসোর্স কম্প্রেস করা উচিত তা শনাক্ত করতে Lighthouse টেক্সট কম্প্রেশন চালু করুন অডিট ব্যবহার করুন।
এর সমাধান করুন
আপনার সার্ভার কনফিগারেশন আপডেট করে কম্প্রেশন চালু করুন। নির্দেশাবলী:
ছবি ও মিডিয়া অপ্টিমাইজ করা
বেশিরভাগ ওয়েবসাইটের ফাইল সাইজের বেশিরভাগ অংশই ছবি দিয়ে তৈরি হয়; ছবি অপ্টিমাইজ করলে দ্রুত এবং উল্লেখযোগ্যভাবে সাইটের সাইজ কমানো যেতে পারে।
ডায়াগনসিস করা
Lighthouse-এ বিভিন্ন ধরনের অডিট আছে যা সম্ভাব্য ইমেজ অপ্টিমাইজেশন ফ্ল্যাগ করে। অন্যভাবে, আরেকটি কৌশল হল DevTools ব্যবহার করে সবচেয়ে বড় ছবির ফাইলগুলি শনাক্ত করা - এই ছবিগুলি অপ্টিমাইজেশনের জন্য ভাল প্রার্থী হতে পারে।
প্রাসঙ্গিক লাইটহাউস অডিট:
- ছবির সাইজ ঠিক করা
- অফস্ক্রিন ছবি ডিফার করা
- দক্ষতার সাথে ছবি এনকোড করুন
- নেক্সট-জেন ফর্ম্যাটে ছবি দেখান
- অ্যানিমেটেড কন্টেন্টের জন্য ভিডিও ফর্ম্যাট ব্যবহার করুন
Chrome DevTools ওয়ার্কফ্লো:
- লগ নেটওয়ার্ক অ্যাক্টিভিটি
- ছবি নয় এমন রিসোর্স ফিল্টার করে বাদ দিতে Img-এ ক্লিক করুন
- ছবির ফাইল সাইজ অনুযায়ী সাজাতে সাইজ কলামে ক্লিক করুন
এর সমাধান করুন
আপনার কাছে সীমিত সময় থাকলে…
বড় এবং ঘন ঘন লোড করা ছবি শনাক্ত করার জন্য সময় দিন এবং Squoosh-এর মতো টুল ব্যবহার করে ম্যানুয়ালি সেগুলি অপ্টিমাইজ করুন। অনেক বড় ছবি প্রায়ই অপ্টিমাইজেশনের জন্য ভালো ক্যান্ডিডেট।
যেসব বিষয় মনে রাখতে হবে:
- সাইজ: ছবি যেন প্রয়োজনের চেয়ে বড় না হয়।
- কম্প্রেশন: সাধারণত, ৮০-৮৫ কোয়ালিটি লেভেল থাকলে ছবির কোয়ালিটির উপর ন্যূনতম প্রভাব পড়বে এবং ফাইলের সাইজ ৩০-৪০% কমে যাবে।
- ফর্ম্যাট: ফটোর জন্য PNG-এর পরিবর্তে JPEG ব্যবহার করুন; অ্যানিমেটেড কন্টেন্টের জন্য GIF-এর পরিবর্তে MP4 ব্যবহার করুন।
আপনার কাছে আরও সময় থাকলে…
আপনার সাইটের একটি উল্লেখযোগ্য অংশ যদি ছবি হয়, তাহলে একটি ছবি CDN সেট-আপ করার কথা বিবেচনা করুন। ইমেজ CDN-এর ডিজাইন করা হয়েছে ছবি পরিবেশন ও অপ্টিমাইজ করার জন্য এবং এটি অরিজিন সার্ভার থেকে ছবি পরিবেশনের কাজ অফলোড করবে। ইমেজ CDN সেট-আপ করা সহজ, তবে এর জন্য বর্তমান ইমেজ URL আপডেট করে ইমেজ CDN-এ পয়েন্ট করতে হবে।
আরও পড়ুন:
JS ও CSS ছোট করুন
ছোট করার মাধ্যমে JavaScript ও CSS থেকে অপ্রয়োজনীয় অক্ষর সরিয়ে দেওয়া হয়।
ডায়াগনসিস করা
কোন কোন রিসোর্স ছোট করা প্রয়োজন তা শনাক্ত করতে CSS ছোট করুন এবং জাভাস্ক্রিপ্ট ছোট করুন Lighthouse অডিট ব্যবহার করুন।
এর সমাধান করুন
আপনার কাছে সীমিত সময় থাকলে, জাভাস্ক্রিপ্ট ছোট করার উপর ফোকাস করুন। বেশিরভাগ সাইটে CSS-এর চেয়ে বেশি JavaScript থাকে, তাই এটি আরও বেশি প্রভাবশালী হবে।
মনিটর করা
সার্ভার মনিটর করার টুল ডেটা সংগ্রহ, ড্যাশবোর্ড এবং সার্ভারের পারফর্ম্যান্স সংক্রান্ত সতর্কতা প্রদান করে। এগুলি ব্যবহার করলে ভবিষ্যতে সার্ভারের পারফর্ম্যান্স সংক্রান্ত সমস্যা প্রতিরোধ ও সমাধান করা যেতে পারে।
মনিটরিং সেট-আপ যতটা সম্ভব সহজ রাখা উচিত। অতিরিক্ত ডেটা সংগ্রহ ও সতর্ক করার জন্য খরচ হয়: ডেটা সংগ্রহের পরিধি বা ফ্রিকোয়েন্সি যত বেশি হবে, তা সংগ্রহ ও স্টোর করার খরচও তত বেশি হবে; অতিরিক্ত সতর্ক করার ফলে অনিবার্যভাবে পৃষ্ঠাগুলি উপেক্ষা করা হয়।
সতর্কতা দেখানোর জন্য এমন মেট্রিক ব্যবহার করা উচিত যা ধারাবাহিকভাবে এবং সঠিকভাবে সমস্যা শনাক্ত করে। সার্ভার রেসপন্স টাইম (লেটেন্সি) হল এমন একটি মেট্রিক যা এর জন্য বিশেষভাবে কাজ করে: এটি বিভিন্ন ধরনের সমস্যা শনাক্ত করে এবং ব্যবহারকারীর অভিজ্ঞতার সাথে সরাসরি সম্পর্কযুক্ত। সিপিইউ ব্যবহারের মতো নিম্ন-স্তরের মেট্রিক্সের উপর ভিত্তি করে সতর্কতা একটি দরকারী পরিপূরক হতে পারে তবে এটি সমস্যার একটি ছোট উপসেটকে ধরবে। এছাড়াও, গড় পারফর্ম্যান্সের পরিবর্তে, টেল পারফর্ম্যান্সের (অন্য কথায় ৯৫তম বা ৯৯তম পার্সেন্টাইল) উপর ভিত্তি করে সতর্কতা পাঠানো উচিত। অন্যথায়, গড় হিসেব করলে, সব ব্যবহারকারীকে প্রভাবিত করে না এমন সমস্যাগুলি সহজেই আড়াল হয়ে যেতে পারে।
এর সমাধান করুন
সব প্রধান ক্লাউড প্রদানকারী তাদের নিজস্ব মনিটরিং টুলিং (GCP, AWS, Azure) অফার করে। এছাড়াও, Netdata হল একটি চমৎকার ফ্রি এবং ওপেন-সোর্স বিকল্প। আপনি যে টুলই বেছে নিন না কেন, আপনি যে সার্ভার মনিটর করতে চান তার প্রত্যেকটিতে টুলের মনিটরিং এজেন্ট ইনস্টল করতে হবে। সম্পূর্ণ হয়ে গেলে, অ্যালার্ট সেট-আপ করতে ভুলবেন না।
নির্দেশাবলী: