এটি কি কোনও নেটওয়ার্ক ব্যান্ডউইথ বাধা প্রমাণ করে?


14

আমি ভুলভাবে ধরে নিয়েছি যে আমার অভ্যন্তরীণ এবি পরীক্ষার অর্থ আমার সার্ভারটি প্রতি সেকেন্ডে 1k সম্মতি @ 3k হিট পরিচালনা করতে পারে।

এই মুহুর্তে আমার তত্ত্বটি হল নেটওয়ার্কটি হ'ল বাধা। সার্ভার পর্যাপ্ত পরিমাণে ডেটা প্রেরণ করতে পারে না।

১ কেজি সম্মতিতে blitz.io থেকে বাহ্যিক পরীক্ষাটি দেখায় যে আমার হিট / এসগুলি 180 এ কাটবে, সার্ভারের হিসাবে প্রতিক্রিয়া করতে পৃষ্ঠাগুলি আরও বেশি সময় নিয়েছে এবং সেকেন্ডে কেবল 180 ফেরত দিতে সক্ষম হবে।

এখানে চিত্র বর্ণনা লিখুন

আমি এনজিনেক্স থেকে একটি ফাঁকা ফাইল পরিবেশন করেছি এবং এটি বেঞ্চ করেছি: এটি একত্রে 1: 1 এর স্কেল করে sc

এখানে চিত্র বর্ণনা লিখুন

এখন আইও / মেমক্যাচড বাটোনেকসগুলি বাতিল করার জন্য (এনজিনেক্স সাধারণত মেমক্যাচ থেকে টান দেয়), আমি ফাইল সিস্টেম থেকে ক্যাশেড পৃষ্ঠার একটি স্ট্যাটিক সংস্করণ পরিবেশন করি।

এখানে চিত্র বর্ণনা লিখুন

ফলাফলগুলি আমার মূল পরীক্ষার সাথে খুব মিল; আমি প্রায় 180 টি আরপিএস এ ক্যাপড আছি।

এইচটিএমএল পৃষ্ঠাটি অর্ধেকভাগে বিভক্ত করা আমাকে আরপিএস দ্বিগুণ দেয়, সুতরাং এটি পৃষ্ঠার আকারের দ্বারা অবশ্যই সীমাবদ্ধ limited

এখানে চিত্র বর্ণনা লিখুন

যদি আমি স্থানীয় সার্ভার থেকে অভ্যন্তরীণভাবে অ্যাপাচিবেঞ্চ করি তবে আমি উচ্চ স্থানান্তর হারে পুরো পৃষ্ঠা এবং অর্ধ পৃষ্ঠা উভয়টিতে প্রায় 4k আরপিএসের ধারাবাহিক ফলাফল পেয়েছি। স্থানান্তর হার: 62586.14 [কেবিটস / সেকেন্ড] গৃহীত হয়েছে

যদি আমি বাহ্যিক সার্ভার থেকে AB করি তবে আমি প্রায় 180RPS পাই - ব্লিটজ.ইও ফলাফলের মতো।

আমি কীভাবে জানব যে এটি ইচ্ছাকৃত থ্রটলিং নয়?

যদি আমি একাধিক বাহ্যিক সার্ভারগুলি থেকে বেঞ্চমার্ক করি তবে সমস্ত ফলাফলগুলি খারাপ হয়ে যায় যা আমার বিশ্বাস করে যে সমস্যাটি আমার সার্ভারগুলি বহির্মুখী ট্র্যাফিকের মধ্যে রয়েছে, আমার বেঞ্চমার্কিং সার্ভার / ব্লিটজ.আইও সহ ডাউনলোডের গতির সমস্যা নয়।

সুতরাং আমি আমার সিদ্ধান্তে ফিরে এসেছি যে আমার সার্ভারটি ডেটা পর্যাপ্ত পরিমাণে পাঠাতে পারে না।

আমি কি সঠিক? এই ডেটা ব্যাখ্যা করার অন্যান্য উপায় আছে? একাধিক সার্ভার + লোড ব্যালেন্সিং সেট আপ করার সমাধান / অপ্টিমাইজেশন যা প্রতি সেকেন্ডে 180 টি হিট সরবরাহ করতে পারে?

আমি সার্ভার অপ্টিমাইজেশনে বেশ নতুন, তাই আমি এই ডেটার ব্যাখ্যার যে কোনও নিশ্চিতকরণের প্রশংসা করব।


আউটবাউন্ড ট্র্যাফিক

আউটবাউন্ড ব্যান্ডউইথ সম্পর্কে আরও তথ্য: নেটওয়ার্ক গ্রাফ প্রতি সেকেন্ডে সর্বোচ্চ 16 এমবি / এস: 16 মেগাবাইটের আউটপুট দেখায়। মোটেও তেমন শোনাচ্ছে না।

থ্রটলিংয়ের বিষয়ে পরামর্শের কারণে, আমি এটি সন্ধান করলাম এবং দেখতে পেলাম লিনোডের একটি 50 এমবিপিএস ক্যাপ রয়েছে (যা আমি স্পষ্টতই আঘাতের কাছেও নেই) not আমি এটি 100 এমবিপিএসে উঠিয়েছি।

যেহেতু লিনোডটি আমার ট্র্যাফিকটিকে ক্যাপ করে রাখে, এবং আমি এটির জন্যও আঘাত করি না, এর অর্থ কি আমার সার্ভারটি সত্যই 100 এমবিপিএস পর্যন্ত আউটপুট তৈরি করতে সক্ষম হওয়া উচিত তবে এটি অন্য কোনও অভ্যন্তরীণ বাধা দ্বারা সীমাবদ্ধ? আমি কেবল বুঝতে পারি না যে এই বিশাল আকারের নেটওয়ার্ক কীভাবে কাজ করে; তারা কী আক্ষরিকভাবে ডেটা প্রেরণ করতে পারে যত দ্রুত তারা এইচডিডি থেকে পড়তে পারে? নেটওয়ার্কের নল হয় যে বড়?

এখানে চিত্র বর্ণনা লিখুন


উপসংহারে

1: উপরের ভিত্তিতে, আমি ভাবছি আমি অবশ্যই এলবি এর পিছনে সার্ভারে ঠিক 180RPS এ মাল্টি এনগিনেক্স সার্ভার সেটআপের উপরে একটি এনগিনেক্স লোড ব্যালেন্সার যুক্ত করে আমার 180RPS বাড়াতে পারি

2: যদি লিনোডের 50 / 100mbit সীমা থাকে যা আমি মোটেও হিট করছি না, তবে আমার একক সার্ভার সেটআপের মাধ্যমে এই সীমাটি হিট করার জন্য আমার কিছু করতে হবে। যদি আমি স্থানীয়ভাবে ডেটাটি দ্রুত পড়তে / প্রেরণ করতে পারি এবং লিনোড এমনকি 50 এমবিট / 100 এমবিট ক্যাপ রাখার পক্ষে বিরক্ত করে তবে একটি অভ্যন্তরীণ বাধা থাকতে হবে যা আমাকে সেই ক্যাপগুলিতে আঘাত করতে দিচ্ছে না যে আমি কীভাবে সনাক্ত করব তা নিশ্চিত নই। সঠিক?

আমি বুঝতে পারি যে প্রশ্নটি এখন বিশাল এবং অস্পষ্ট, তবে আমি কীভাবে এটি ঘনীভূত করব তা নিশ্চিত নই। আমি যে কোনও উপসংহারে যে কোনও ইনপুট প্রশংসিত হয়।


1
এটি কোনও ব্যান্ডউইথ সমস্যা কিনা তা পরীক্ষা করতে আপনি আপনার এইচটিএমএল পৃষ্ঠাটি আরও বড় করে তুলতে পারেন যাতে একই ব্যান্ডউইথটি আরও কম অনুরোধের সাথে পৌঁছে যায়। যদি আপনার পৃষ্ঠাটি উদাহরণস্বরূপ 5MB বড় হয়, তবে আপনি কেবল কয়েকটি অনুরোধ / সেকেন্ডের সাহায্যে একই থ্রুপুটটিতে পৌঁছাতে সক্ষম হবেন, যার ওভারহেড খুব কম হওয়া উচিত এবং তাই আপনাকে আপনার আসল ব্যান্ডউইথ সীমাটির আরও কাছাকাছি পৌঁছে দেওয়া উচিত।
brain99

আমি মাত্র একটি পৃষ্ঠা যা 10x আকারের ঠিক পরীক্ষা করেছি। আমার আরপিএস সরাসরি পৃষ্ঠার আকারের সাথে সম্পর্কিত। 10x বৃহত্তর == 18 আরপিএস। 1x == 180. আমি আসলে মনে করি এটি সন্দেহজনকভাবে 50 এমবিটের কাছাকাছি। আমি মনে করি লিনোডের স্থিতি পর্যবেক্ষণ সর্বাধিক 24 এমবিট ভুল হতে পারে এবং আমি তাদের ক্যাপটি আসলে আঘাত করছি। আমি আবার বৃদ্ধি চাইছি এবং ফিরে রিপোর্ট করব report
যুজি টোমিটা

উত্তর:


5

বিষয়টি আমাকে ধরেই নিয়েছিল যে লিনোড ডট কম গ্রাফের শিখাগুলি সত্য পর্বত। এটি গ্রাফটি 5 মিনিটের গড় ডেটা পয়েন্টগুলি ব্যবহার করে তা প্রমাণিত করে, যখন আমি যখন 50mbit ক্যাপটি ছুঁড়েছিলাম তখন আমার চূড়াটি 24mbits হিসাবে উপস্থিত হয়।

এখন যেহেতু তারা এটি 100 এমবিটে উন্নীত করেছে, আমার মানদণ্ডগুলি তত্ক্ষণাত্ নতুন বহির্মুখী ট্র্যাফিক সীমাতে চলে গেছে।

আগে যদি আমি খেয়াল করতাম! আমার প্রচুর যুক্তি এই ধারণার সাথে জড়িত যে আমি সেই গ্রাফের কারণে বহির্মুখী ট্র্যাফিক সীমাটিকে আঘাত করছি না।

এখন, আমি প্রতি সেকেন্ডে ৩0০ টি অনুরোধে পৌঁছেছি, যা 100 এমবিপিএসের ঠিক নীচে রয়েছে যেখানে আমি অনুরোধগুলির একটি "ব্যাকলগ" পেতে শুরু করি এবং প্রতিক্রিয়া সময়গুলি বাড়তে শুরু করে।

এখানে চিত্র বর্ণনা লিখুন

পৃষ্ঠাটি সঙ্কুচিত করে আমি এখন সর্বাধিক সম্মতি বাড়াতে পারি; জিজিপ সক্ষম সহ আমি 600 আরপিএস পাই।

এখানে চিত্র বর্ণনা লিখুন

আমি হঠাৎ করেই সমস্যার মধ্যে পড়ি যখন আমি হঠাৎ করে শীর্ষে উঠি এবং মুলতুবি থাকা অনুরোধগুলির ব্যাকলগ (ব্যান্ডউইথ দ্বারা সীমাবদ্ধ) জমে শুরু হয় তবে এটি অন্যরকম প্রশ্নের মতো মনে হয়।

এখানে চিত্র বর্ণনা লিখুন

এটি অনুকূলিতকরণ / এই ডেটাটি পড়া / সম্ভাব্য সমস্যাগুলি সঙ্কুচিত করার একটি দুর্দান্ত পাঠ হয়েছে। আপনার ইনপুট জন্য আপনাকে অনেক ধন্যবাদ!


4

কিছুটা দেরি হয়ে গেছে যে আপনি এটি বের করে ফেলেছেন ... তবে সম্ভবত আপনার সময়ে সময়ে সার্ভারফল্ট ব্লগটি পড়া উচিত।

আমি এই পোস্টটির বিশেষত চিন্তা করছি , যেখানে তারা আলোচনা করে যে এক দ্বিতীয় ভোটের ব্যবধান কেন সময়ে সময়ে তা কেটে না দেয়, আপনার যেটির সাথে খুব একই রকম সমস্যা সম্পর্কিত ...

আমরা আবিষ্কার করেছি যে আমরা আমাদের গিগাবাইট / এস ইন্টারফেসে কেবল 10-30 এমবিট / সেকেন্ডের হারে প্যাকেটগুলি প্রায়শই ঘনঘন করছি যা আমাদের কার্যকারিতা ক্ষতিগ্রস্থ করে। এর কারণ এটি হ'ল 10-30 এমবিট / এস হারটি সত্যই 5 মিনিট প্রতি এক মিনিটে রূপান্তরিত বিটের সংখ্যা। আমরা যখন ওয়্যারশার্কের সাথে খনন করেছিলাম এবং এক মিলিসেকেন্ড আইও গ্রাফিং ব্যবহার করি, আমরা দেখেছিলাম আমরা প্রায়শই তথাকথিত 1 জিবিট / এস ইন্টারফেসের প্রতি মিলিসেকেন্ড হারে 1 এমবিট বিস্ফোরিত করব।

নিশ্চয়ই আমাকে ভাবিয়ে তুলেছে। এবং আমি কেবল জানি যে আমি আমার প্রথম সুযোগটি আমার দোকানে অন্য এসএ-এর দিকে ঝুলিয়ে দিচ্ছি এবং যখন আমরা এই সমস্যাটি দেখি তখন মন্দভাবে উজ্জ্বল এবং বোধশক্তি দেখাব।

কে জানে, আমি এমনকি তাদের কিছু গোপনে রাখতে পারি। :)


ভাল যুক্তি! আকর্ষণীয় তারা 5 মিনিটের গ্রাফ @ 1 সেকেন্ড রেটও এনেছে ... আমি ডেটা নিয়ে তুলনামূলকভাবে আরামদায়ক কারণ আমার 1k সমবর্তী পরীক্ষাটি ইতিমধ্যে খারাপ অবস্থানে রয়েছে (আমার মনে হয় ..)। Second 600 ব্যবহারকারী প্রতি সেকেন্ডে একটি পৃষ্ঠা লোড করছে == ~ 2m একটি ঘন্টা হিট করে, যা আমরা এমনকি কাছেও পাই না। আমি কেবল কিছুক্ষণের প্রথম কয়েক মিনিটের মধ্যে ছিটকে পড়তে চাইনি।
যুজি টোমিটা

0

এটি নেটওয়ার্কের মাধ্যমে সীমাবদ্ধ হতে পারে তবে কেবল ব্যান্ডউইথের প্রশ্ন নয়। আপনার দূরবর্তী পরীক্ষা ইউনিটের স্বচ্ছলতা কোনও নির্দিষ্ট সময়ে মুলতুবি থাকা সংযোগের সংখ্যার (স্থানীয়ভাবে স্বীকৃতিগুলির জন্য 50ms অপেক্ষা করা) পাশাপাশি সংযোগের অগ্রগতির সাথে সাথে উইন্ডো মাপের সমঝোতা এবং স্থিতিশীলতার উপর প্রভাব ফেলবে। আপনি সম্ভবত কিছু পরিমাণ প্যাকেট ক্ষতির মুখোমুখি হয়ে পড়েছেন - হয় যানজটের কাজ হিসাবে বা আপনার বাহকের (বা যারা উজানের) অংশে ব্যান্ডউইথ সীমাবদ্ধতার ব্যবস্থা হিসাবে।

আমি একটি বুদ্ধিমান বেসলাইন আঁকার জন্য সমীকরণ থেকে যতটা সম্ভব মুছে ফেলার পরামর্শ দেব। সাধারণ ইন্টারনেটের কয়েকটি পয়েন্টে আপনার সার্ভার থেকে পিক ব্যান্ডউইদথ, বিলম্ব এবং প্যাকেট হ্রাস পরিমাপ করুন। এটি যতই শোনাচ্ছে অসম্ভব, "ভিওআইপি ট্র্যাফিক পরীক্ষা" বা এর মতো সন্ধানের চেষ্টা করুন। ভিওআইপি পরিষেবাদির বেশ কয়েকটি সরবরাহকারীর কাছে এমন অ্যাপ্লিকেশন রয়েছে যা এই ধরণের নিদর্শনগুলি (দ্বিদ্বারূপে) যথাযথভাবে সঠিকতার সাথে পরিমাপ করতে পারে। আপনার লিঙ্কটির আসল দরকারী গতি হিসাবে একবারে আপনার যদি কিছু বৈধ অভিজ্ঞতামূলক ডেটা হয়ে যায় তবে আপনার ফলাফলগুলি যথাযথভাবে বৈধ হতে পারে।

ব্যান্ডউইথ পরীক্ষার পাশাপাশি অতিরিক্ত সংখ্যক ফেরত পাঠানোর জন্য সাব-পার ওয়েব ওয়েব ট্র্যাফিকের প্যাকেট ক্যাপচারটি দেখার পাশাপাশি আপনার সার্ভারের অনুরোধগুলির প্রতিক্রিয়া জানাতে আপাত সময় পরিমাপ করাও কার্যকর হতে পারে (..এটি যদি এটি হয়) সংযোগের ফাংশন হিসাবে মানটি যথেষ্ট পরিমাণে বাড়ছে, এটি একটি বড় চিহ্ন cl

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.