ভূমিকা
আমি কিছু সময়ের জন্য HAProxy টিউন করে চলেছি এবং এর উপর অনেকগুলি পরীক্ষার টেস্ট করেছি। 100 টি HTTP অনুরোধ / গুলি থেকে 50,000 এইচটিটিপি অনুরোধ / গুলি।
প্রথম পরামর্শটি হ্যাপ্রোক্সিতে পরিসংখ্যান পৃষ্ঠা সক্ষম করা । আপনি পর্যবেক্ষণ প্রয়োজন, ব্যতিক্রম। আপনি যদি 10,000 টি অনুরোধ / গুলি অতীত করতে চান তবে আপনার সূক্ষ্ম সুরকরণেরও প্রয়োজন হবে।
সময়সীমাগুলি একটি বিভ্রান্তিকর প্রাণী কারণ তাদের সম্ভাব্য মানগুলির বিশাল পরিসর রয়েছে, তাদের বেশিরভাগেরই কোনও পর্যবেক্ষণযোগ্য পার্থক্য নেই। 5% কম বা 5% উচ্চতর কারণে আমি এখনও কিছু ব্যর্থ দেখতে পাচ্ছি। 10000 বনাম 11000 মিলিসেকেন্ড, কে চিন্তা করে? সম্ভবত আপনার সিস্টেম না।
কনফিগারেশন
আমি সবার বিবেকের জন্য 'সর্বকালের সেরা সময়সীমা' হিসাবে কয়েকটি নম্বর দিতে পারি না।
পরিবর্তে আমি যা বলতে পারি তা হ'ল বেশিরভাগ আক্রমণাত্মক সময়সীমা যা HTTP (এস) লোড ভারসাম্যের জন্য সর্বদা গ্রহণযোগ্য। আপনি যদি এর চেয়ে কম মুখোমুখি হন তবে আপনার লোড ব্যালেন্সারটিকে পুনরায় কনফিগার করার সময়।
timeout connect 5000
timeout check 5000
timeout client 30000
timeout server 30000
সময়সীমা ক্লায়েন্ট:
নিষ্ক্রিয়তার সময়সীমা প্রযোজ্য যখন ক্লায়েন্টটি ডেটা স্বীকৃতি বা প্রেরণ প্রত্যাশিত হয়। এইচটিটিপি মোডে, এই সময়সীমাটি প্রথম পর্যায়ে, যখন ক্লায়েন্ট অনুরোধটি প্রেরণ করে এবং প্রতিক্রিয়ার সময় এটি সার্ভারের মাধ্যমে প্রেরিত ডেটা পড়ার সময় বিবেচনা করা বিশেষভাবে গুরুত্বপূর্ণ।
পড়ুন : ক্লায়েন্টের কাছ থেকে এইচটিটিপি অনুরোধ শিরোনাম পাওয়ার সর্বোচ্চ সময় ।
3 জি / 4 জি / 56 কে / স্যাটেলাইট সময়ে ধীর হতে পারে। তবুও, তাদের 30 টি নয়, কয়েক সেকেন্ডের মধ্যে HTTP শিরোনাম প্রেরণে সক্ষম করা উচিত।
কারও সাথে যদি এমন সংযোগ থাকে যে কোনও পৃষ্ঠার অনুরোধ করার জন্য 30 এর বেশি প্রয়োজন (তবে 10 এম্বেড করা চিত্র / সিএসএস / জেএসের অনুরোধের জন্য 10 * 30 এর বেশি), আমি বিশ্বাস করি যে এটি তাকে প্রত্যাখ্যানযোগ্য it
সময়সীমা সার্ভার:
নিষ্ক্রিয়তার সময়সীমাটি প্রযোজ্য হয় যখন সার্ভারটি ডেটা স্বীকৃতি বা প্রেরণের প্রত্যাশা করে। এইচটিটিপি মোডে, এই সময়সীমাটি সার্ভারের প্রতিক্রিয়াটির প্রথম পর্যায়ে বিবেচনা করা বিশেষভাবে গুরুত্বপূর্ণ, যখন এটি শিরোনাম পাঠাতে হয়, কারণ এটি অনুরোধের জন্য সরাসরি সার্ভারের প্রক্রিয়াজাতকরণের সময় উপস্থাপন করে। সেখানে কী কী মূল্য দিতে হবে তা সন্ধান করার জন্য, অগ্রহণযোগ্য প্রতিক্রিয়ার সময় হিসাবে বিবেচিত হবে তা দিয়ে প্রায়শই শুরু করা ভাল, তারপরে প্রতিক্রিয়ার সময় বিতরণ পর্যবেক্ষণ করতে লগগুলি চেক করুন এবং সেই অনুযায়ী মানটি সামঞ্জস্য করুন।
পড়ুন : সার্ভারের থেকে HTTP প্রতিক্রিয়া শিরোনামগুলি পাওয়ার জন্য এটি সর্বোচ্চ সময় (এটির সম্পূর্ণ ক্লায়েন্টের অনুরোধ পাওয়ার পরে)। মূলত, এটি আপনার সার্ভারগুলির প্রক্রিয়াজাতকরণের সময়, প্রতিক্রিয়া প্রেরণ শুরু করার আগে।
যদি আপনার সার্ভারটি এত ধীর গতিতে থাকে যে এর উত্তর দেওয়া শুরু করতে 30s এরও বেশি প্রয়োজন, তবে আমি বিশ্বাস করি এটি মৃত হিসাবে বিবেচনাযোগ্য is
বিশেষ কেস : খুব ভারী প্রক্রিয়াকরণ করছে এমন কিছু বিরল পরিষেবাগুলির একটি উত্তর দিতে পুরো মিনিট বা তার বেশি সময় লাগতে পারে। এই নির্দিষ্ট ব্যবহারের জন্য এই টাইমআউটটি অনেক বাড়ানোর প্রয়োজন হতে পারে। (দ্রষ্টব্য: এটি খারাপ ডিজাইনের ক্ষেত্রে হতে পারে, একটি অ্যাসিঙ্ক স্টাইল যোগাযোগ ব্যবহার করুন বা HTTP ব্যবহার করবেন না all)
সময়সীমা সংযোগ:
কোনও সার্ভারে সংযোগের চেষ্টাটির জন্য সাফল্যের জন্য অপেক্ষা করতে সর্বোচ্চ সময় নির্ধারণ করুন।
পড়ুন : কোনও সার্ভারের সর্বাধিক সময় টিসিপি সংযোগ গ্রহণ করতে হয়।
সার্ভারগুলি HAProxy এর মতো একই ল্যানে রয়েছে তাই এটি দ্রুত হওয়া উচিত। এটি কমপক্ষে 5 সেকেন্ড দিন কারণ কোনও অপ্রত্যাশিত ঘটনা ঘটলে এটি কতক্ষণ সময় নিতে পারে (ট্রান্সপোর্টে স্পাইক করে নতুন অনুরোধ গ্রহণের জন্য একটি সার্ভার একটি নতুন প্রক্রিয়া জোর করে বলছে, ট্রান্সপোর্টে নতুন প্রক্রিয়াকরণ করার জন্য একটি সার্ভার) rans
বিশেষ কেস : সার্ভারগুলি যখন অন্য কোনও ল্যানে থাকে বা কোনও অবিশ্বস্ত লিঙ্কের ওপরে থাকে। এই সময়সীমাটি অনেক বাড়ানোর প্রয়োজন হতে পারে। (দ্রষ্টব্য: এটি সম্ভবত খারাপ স্থাপত্যের ক্ষেত্রে হতে পারে।)
সময়সীমা পরীক্ষা:
অতিরিক্ত চেক টাইমআউট সেট করুন, তবে কেবল কোনও সংযোগ ইতোমধ্যে প্রতিষ্ঠিত হওয়ার পরে।
অতিরিক্ত চেক টাইমআউট সেট করুন, তবে কেবল কোনও সংযোগ ইতিমধ্যে স্থাপন করা থাকলে সেট করা থাকলে, হ্যাপ্রোক্সি চেকের জন্য সংযোগের সময়সীমার হিসাবে কম ("টাইমআউট সংযোগ", "আন্ত") এবং অতিরিক্ত পড়ার সময়সীমা হিসাবে "টাইমআউট চেক" ব্যবহার করে। "মিনিট" ব্যবহার করা হয় যাতে খুব দীর্ঘ "টাইমআউট সংযোগ" দিয়ে দৌড়ানো লোকেরা (যেমন: সারি বা টারপাইটের কারণে যাদের এটি দরকার ছিল) তাদের চেকগুলি ধীর না করে। (দয়া করে নোট করুন যে এত দীর্ঘ সংযোগের সময়সীমা থাকার কোনও বৈধ কারণ নেই, কারণ এটি এড়ানোর জন্য "টাইমআউট সারি" এবং "টাইমআউট ট্যারিপিট" সর্বদা ব্যবহার করা যেতে পারে)।
পড়ুন : স্বাস্থ্য পরীক্ষা করার সময় সার্ভারকে প্রতিক্রিয়া timeout connectজানাতে সংযোগটি গ্রহণ করতে হবে accepttimeout check
সমস্ত সার্ভারের একটি HTTP (এস) স্বাস্থ্য পরীক্ষা কনফিগার করা আবশ্যক। সার্ভার উপলব্ধ কিনা তা বোঝার ভারসাম্যের একমাত্র উপায়। স্বাস্থ্য চেক /isaliveসর্বদা উত্তর দেওয়ার একটি সহজ পৃষ্ঠা OK।
এই টাইমআউটটি কমপক্ষে 5 সেকেন্ড দিন কারণ অপ্রত্যাশিত কিছু ঘটলে এটি কতক্ষণ সময় নিতে পারে (ট্রান্সফিকের প্রবণতা বৃদ্ধি করে নতুন অনুরোধগুলি গ্রহণের জন্য একটি সার্ভার একটি নতুন প্রক্রিয়া জোরদার করার জন্য একটি সার্ভার, নতুন ট্রান্সপোর্টের জন্য চাপ দিচ্ছে) how
যুদ্ধের গল্প : প্রচুর লোক ভুলভাবে বিশ্বাস করে যে সার্ভার সর্বদা এই সাধারণ পৃষ্ঠাটির উত্তর 3 এমএসে দিতে পারে। তারা আক্রমণাত্মক ফেলওভার (2 ব্যর্থ চেক = সার্ভার ডেড) সহ একটি আক্রমণাত্মক সময়সীমা (<2000 মিমি) সেট করে। আমি পুরো ওয়েবসাইটগুলি নীচে নেমে যেতে দেখেছি। সাধারণত ট্র্যাফিকের ক্ষেত্রে সামান্য গতি থাকে, ব্যাকএন্ড সার্ভারগুলি ধীর হয়ে যায়, স্বাস্থ্য পরীক্ষাগুলি বিলম্বিত হয় ... হঠাৎ হঠাৎ এগুলি একসাথে শেষ হয়ে যায়, HAProxy মনে করে সমস্ত সার্ভার একবারে মারা গিয়েছিল এবং পুরো সাইটটি ডাউন হয়ে যায়।