SRE: কর্মক্ষমতা বিশ্লেষণ। Go-তে একটি সাধারণ ওয়েব সার্ভার ব্যবহার করে কনফিগারেশন পদ্ধতি

কর্মক্ষমতা বিশ্লেষণ এবং টিউনিং ক্লায়েন্টদের জন্য কর্মক্ষমতা সম্মতি যাচাই করার জন্য একটি শক্তিশালী হাতিয়ার।

কর্মক্ষমতা বিশ্লেষণ টিউনিং পরীক্ষাগুলি পরীক্ষা করার জন্য একটি বৈজ্ঞানিক পদ্ধতি প্রয়োগ করে একটি প্রোগ্রামে বাধাগুলি পরীক্ষা করতে ব্যবহার করা যেতে পারে। এই নিবন্ধটি একটি উদাহরণ হিসাবে একটি Go ওয়েব সার্ভার ব্যবহার করে কর্মক্ষমতা বিশ্লেষণ এবং টিউনিংয়ের একটি সাধারণ পদ্ধতির সংজ্ঞায়িত করে৷

Go এখানে বিশেষভাবে ভালো কারণ এতে প্রোফাইলিং টুল রয়েছে pprof স্ট্যান্ডার্ড লাইব্রেরিতে।

কৌশল

আমাদের কাঠামোগত বিশ্লেষণের জন্য একটি সারাংশ তালিকা তৈরি করা যাক। আমরা অন্তর্দৃষ্টি বা অনুমানের উপর ভিত্তি করে পরিবর্তন করার পরিবর্তে সিদ্ধান্ত নেওয়ার জন্য কিছু ডেটা ব্যবহার করার চেষ্টা করব। এটি করার জন্য আমরা এটি করব:

• আমরা অপ্টিমাইজেশান সীমানা নির্ধারণ করি (প্রয়োজনীয়তা);
• আমরা সিস্টেমের জন্য লেনদেনের লোড গণনা করি;
• আমরা পরীক্ষা সঞ্চালন (ডেটা তৈরি);
• আমরা পর্যবেক্ষণ করি;
• আমরা বিশ্লেষণ করি - সমস্ত প্রয়োজনীয়তা পূরণ হয়?
• আমরা এটি বৈজ্ঞানিকভাবে সেট আপ করি, একটি হাইপোথিসিস করি;
• আমরা এই অনুমান পরীক্ষা করার জন্য একটি পরীক্ষা সঞ্চালন.

সাধারণ HTTP সার্ভার আর্কিটেকচার

এই নিবন্ধটির জন্য আমরা গোলং-এ একটি ছোট HTTP সার্ভার ব্যবহার করব। এই নিবন্ধ থেকে সমস্ত কোড পাওয়া যাবে এখানে.

অ্যাপ্লিকেশানটি বিশ্লেষণ করা হচ্ছে একটি HTTP সার্ভার যা প্রতিটি অনুরোধের জন্য Postgresql পোল করে। উপরন্তু, অ্যাপ্লিকেশন এবং সিস্টেম মেট্রিক্স সংগ্রহ ও প্রদর্শনের জন্য প্রমিথিউস, নোড_এক্সপোর্টার এবং গ্রাফানা রয়েছে।

সহজ করার জন্য, আমরা বিবেচনা করি যে অনুভূমিক স্কেলিং (এবং গণনা সরলীকরণ) জন্য প্রতিটি পরিষেবা এবং ডাটাবেস একসাথে স্থাপন করা হয়েছে:

লক্ষ্য নির্ধারণ করা

এই ধাপে, আমরা লক্ষ্য নির্ধারণ করি। আমরা কি বিশ্লেষণ করার চেষ্টা করছি? এটা শেষ করার সময় আমরা কিভাবে জানি? এই নিবন্ধে, আমরা কল্পনা করব যে আমাদের ক্লায়েন্ট আছে এবং আমাদের পরিষেবা প্রতি সেকেন্ডে 10 অনুরোধ প্রক্রিয়া করবে।

В গুগল এসআরই বই নির্বাচন এবং মডেলিং পদ্ধতি বিস্তারিত আলোচনা করা হয়. আসুন একই কাজ করি এবং মডেলগুলি তৈরি করি:

• লেটেন্সি: 99% অনুরোধ 60ms এর কম সময়ে সম্পন্ন করা উচিত;
• খরচ: পরিষেবাটি ন্যূনতম পরিমাণ অর্থ গ্রহণ করা উচিত যা আমরা মনে করি যুক্তিসঙ্গতভাবে সম্ভব। এটি করার জন্য, আমরা থ্রুপুট সর্বাধিক করি;
• ক্যাপাসিটি প্ল্যানিং: সামগ্রিক স্কেলিং কার্যকারিতা সহ অ্যাপ্লিকেশনটির কতগুলি দৃষ্টান্ত চালানোর প্রয়োজন হবে এবং প্রাথমিক লোড এবং বিধানের প্রয়োজনীয়তাগুলি পূরণ করার জন্য কতগুলি দৃষ্টান্তের প্রয়োজন হবে তা বোঝা এবং নথিভুক্ত করা প্রয়োজন অপ্রয়োজনীয়তা n+1.

লেটেন্সির জন্য বিশ্লেষণ ছাড়াও অপ্টিমাইজেশনের প্রয়োজন হতে পারে, কিন্তু থ্রুপুট পরিষ্কারভাবে বিশ্লেষণ করা প্রয়োজন। SRE SLO প্রক্রিয়া ব্যবহার করার সময়, বিলম্বের অনুরোধটি গ্রাহক বা ব্যবসার কাছ থেকে আসে, পণ্যের মালিক দ্বারা প্রতিনিধিত্ব করা হয়। এবং আমাদের পরিষেবা এই বাধ্যবাধকতাটি প্রথম থেকেই কোনও সেটিংস ছাড়াই পূরণ করবে!

একটি পরীক্ষার পরিবেশ স্থাপন করা হচ্ছে

একটি পরীক্ষার পরিবেশের সাহায্যে, আমরা আমাদের সিস্টেমে একটি পরিমাপিত লোড স্থাপন করতে সক্ষম হব। বিশ্লেষণের জন্য, ওয়েব পরিষেবার কার্যকারিতার উপর ডেটা তৈরি করা হবে।

লেনদেন লোড

এই পরিবেশ ব্যবহার করে Vegeta থামানো পর্যন্ত একটি কাস্টম HTTP অনুরোধের হার তৈরি করতে:

$ make load-test LOAD_TEST_RATE=50
echo "POST http://localhost:8080" | vegeta attack -body tests/fixtures/age_no_match.json -rate=50 -duration=0 | tee results.bin | vegeta report

পর্যবেক্ষক

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

প্রোফাইলিং

প্রোফাইলিং হল এক ধরণের পরিমাপ যা আপনাকে দেখতে দেয় যে যখন একটি অ্যাপ্লিকেশন চলছে তখন CPU সময় কোথায় যাচ্ছে। এটি আপনাকে ঠিক কোথায় এবং কতটা প্রসেসর সময় ব্যয় করে তা নির্ধারণ করতে দেয়:

এই ডেটা বিশ্লেষণের সময় নষ্ট CPU সময় এবং সঞ্চালিত অপ্রয়োজনীয় কাজ সম্পর্কে অন্তর্দৃষ্টি পেতে ব্যবহার করা যেতে পারে। Go (pprof) প্রোফাইল তৈরি করতে পারে এবং সরঞ্জামগুলির একটি মান সেট ব্যবহার করে শিখা গ্রাফ হিসাবে তাদের কল্পনা করতে পারে। আমি নিবন্ধে পরে তাদের ব্যবহার এবং সেটআপ গাইড সম্পর্কে কথা বলব।

নির্বাহ, পর্যবেক্ষণ, বিশ্লেষণ।

একটি পরীক্ষা করা যাক. আমরা পারফরম্যান্সে সন্তুষ্ট না হওয়া পর্যন্ত আমরা পারফর্ম করব, পর্যবেক্ষণ করব এবং বিশ্লেষণ করব। প্রথম পর্যবেক্ষণের ফলাফল পেতে এটি প্রয়োগ করার জন্য আমাদের একটি নির্বিচারে কম লোড মান নির্বাচন করা যাক। প্রতিটি পরবর্তী ধাপে আমরা একটি নির্দিষ্ট স্কেলিং ফ্যাক্টর দিয়ে লোড বাড়াব, যা কিছু ভিন্নতার সাথে বেছে নেওয়া হয়েছে। প্রতিটি লোড টেস্টিং রান সামঞ্জস্য করা অনুরোধের সংখ্যার সাথে সঞ্চালিত হয়: make load-test LOAD_TEST_RATE=X.

প্রতি সেকেন্ডে 50টি অনুরোধ

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

আসুন খরচের দিকটি দেখে নেওয়া যাক:

প্রতি সেকেন্ডে 10000 অনুরোধ / সার্ভার প্রতি 50টি অনুরোধ = 200 সার্ভার + 1

আমরা এখনও এই পরিসংখ্যান উন্নত করতে পারেন.

প্রতি সেকেন্ডে 500টি অনুরোধ

লোড প্রতি সেকেন্ডে 500টি অনুরোধে পৌঁছালে আরও আকর্ষণীয় জিনিসগুলি ঘটতে শুরু করে:

আবার, উপরের বাম গ্রাফে আপনি দেখতে পাচ্ছেন যে অ্যাপ্লিকেশনটি স্বাভাবিক লোড রেকর্ড করছে। যদি এটি না হয়, যে সার্ভারে অ্যাপ্লিকেশনটি চলছে সেখানে একটি সমস্যা রয়েছে। প্রতিক্রিয়া লেটেন্সি গ্রাফটি উপরের ডানদিকে অবস্থিত, এটি দেখায় যে প্রতি সেকেন্ডে 500টি অনুরোধের ফলে 25-40ms এর প্রতিক্রিয়া বিলম্বিত হয়েছে। 99তম পার্সেন্টাইল এখনও উপরে বেছে নেওয়া 60ms SLO-তে সুন্দরভাবে ফিট করে।

খরচের দিক থেকে:

প্রতি সেকেন্ডে 10000 অনুরোধ / সার্ভার প্রতি 500টি অনুরোধ = 20 সার্ভার + 1

সবকিছু এখনও উন্নত করা যেতে পারে।

প্রতি সেকেন্ডে 1000টি অনুরোধ

দুর্দান্ত লঞ্চ! অ্যাপ্লিকেশনটি দেখায় যে এটি প্রতি সেকেন্ডে 1000টি অনুরোধ প্রক্রিয়া করেছে, কিন্তু SLO দ্বারা লেটেন্সি সীমা লঙ্ঘন করা হয়েছে৷ উপরের ডানদিকের গ্রাফে p99 লাইনে এটি দেখা যাবে। p100 লাইন অনেক বেশি হওয়া সত্ত্বেও, প্রকৃত বিলম্ব সর্বোচ্চ 60ms এর চেয়ে বেশি। অ্যাপ্লিকেশনটি আসলে কী করে তা জানতে প্রোফাইলিংয়ে ডুব দেওয়া যাক।

প্রোফাইলিং

প্রোফাইলিংয়ের জন্য, আমরা প্রতি সেকেন্ডে 1000 অনুরোধে লোড সেট করি, তারপর ব্যবহার করুন pprof অ্যাপ্লিকেশনটি কোথায় CPU সময় ব্যয় করছে তা খুঁজে বের করতে ডেটা ক্যাপচার করতে। এটি HTTP এন্ডপয়েন্ট সক্রিয় করে করা যেতে পারে pprof, এবং তারপর, লোডের অধীনে, কার্ল ব্যবহার করে ফলাফলগুলি সংরক্ষণ করুন:

$ curl http://localhost:8080/debug/pprof/profile?seconds=29 > cpu.1000_reqs_sec_no_optimizations.prof

ফলাফল এই মত প্রদর্শিত হতে পারে:

$ go tool pprof -http=:12345 cpu.1000_reqs_sec_no_optimizations.prof

গ্রাফটি দেখায় কোথায় এবং কত অ্যাপ্লিকেশন CPU সময় ব্যয় করে। থেকে বর্ণনা থেকে ব্রেন্ডন গ্রেগ:

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

বিশ্লেষণ - অনুমান

টিউনিংয়ের জন্য, আমরা নষ্ট CPU সময় খুঁজে বের করার চেষ্টা করার উপর ফোকাস করব। আমরা অকেজো খরচের বৃহত্তম উত্সগুলি সন্ধান করব এবং সেগুলি সরিয়ে ফেলব। ঠিক আছে, যে প্রোফাইলিংটি খুব সঠিকভাবে প্রকাশ করে যে অ্যাপ্লিকেশনটি তার প্রসেসরের সময় ঠিক কোথায় ব্যয় করছে, আপনাকে এটি বেশ কয়েকবার করতে হতে পারে, এবং আপনাকে অ্যাপ্লিকেশন সোর্স কোড পরিবর্তন করতে হবে, পরীক্ষাগুলি পুনরায় চালাতে হবে এবং দেখতে হবে যে কর্মক্ষমতা লক্ষ্যের কাছে পৌঁছেছে।

ব্রেন্ডন গ্রেগের সুপারিশ অনুসরণ করে, আমরা চার্টটি উপরে থেকে নীচে পড়ব। প্রতিটি লাইন একটি স্ট্যাক ফ্রেম (ফাংশন কল) প্রদর্শন করে। প্রথম লাইন হল প্রোগ্রামের প্রবেশ বিন্দু, অন্য সব কলের মূল (অন্য কথায়, অন্য সব কলের স্ট্যাকে এটি থাকবে)। পরবর্তী লাইন ইতিমধ্যেই ভিন্ন:

আপনি যদি গ্রাফে একটি ফাংশনের নামের উপর কার্সারটি ঘোরান, ডিবাগিংয়ের সময় এটি স্ট্যাকে থাকা মোট সময় প্রদর্শিত হবে। HTTPServe ফাংশন ছিল 65% সময়, অন্যান্য রানটাইম ফাংশন runtime.mcall, mstart и gc, বাকি সময় গ্রহণ. মজার ঘটনা: মোট সময়ের 5% DNS প্রশ্নে ব্যয় করা হয়:

প্রোগ্রামটি যে ঠিকানাগুলি সন্ধান করে তা Postgresql-এর অন্তর্গত। ক্লিক করুন FindByAge:

মজার বিষয় হল, প্রোগ্রামটি দেখায় যে, নীতিগতভাবে, তিনটি প্রধান উত্স রয়েছে যা বিলম্ব যোগ করে: সংযোগ খোলা এবং বন্ধ করা, ডেটা অনুরোধ করা এবং ডাটাবেসের সাথে সংযোগ করা। গ্রাফটি দেখায় যে ডিএনএস অনুরোধ, খোলা এবং বন্ধ সংযোগগুলি মোট কার্যকরী সময়ের প্রায় 13% সময় নেয়।

অনুমান: পুলিং ব্যবহার করে সংযোগগুলি পুনঃব্যবহারের ফলে একটি একক HTTP অনুরোধের সময় হ্রাস করা উচিত, যা উচ্চতর থ্রুপুট এবং কম বিলম্বের অনুমতি দেয়.

অ্যাপ্লিকেশন সেট আপ - পরীক্ষা

আমরা সোর্স কোড আপডেট করি, প্রতিটি অনুরোধের জন্য Postgresql-এর সাথে সংযোগ সরানোর চেষ্টা করুন। প্রথম বিকল্পটি ব্যবহার করা হয় সংযোগ পুল আবেদন স্তরে। এই পরীক্ষায় আমরা এটা সেট আপ করা যাক যাওয়ার জন্য sql ড্রাইভার ব্যবহার করে সংযোগ পুলিং:

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)

if err != nil {
   return nil, err
}

নির্বাহ, পর্যবেক্ষণ, বিশ্লেষণ

প্রতি সেকেন্ডে 1000 অনুরোধের সাথে পরীক্ষাটি পুনরায় চালু করার পরে, এটা স্পষ্ট যে p99-এর লেটেন্সি লেভেল 60ms এর SLO সহ স্বাভাবিক অবস্থায় ফিরে এসেছে!

খরচ কি?

প্রতি সেকেন্ডে 10000 অনুরোধ / সার্ভার প্রতি 1000টি অনুরোধ = 10 সার্ভার + 1

এর আরও ভালো করা যাক!

প্রতি সেকেন্ডে 2000টি অনুরোধ

লোড দ্বিগুণ করা একই জিনিস দেখায়, উপরের বাম গ্রাফটি দেখায় যে অ্যাপ্লিকেশনটি প্রতি সেকেন্ডে 2000টি অনুরোধ প্রক্রিয়া করতে পরিচালনা করে, p100 60ms এর চেয়ে কম, p99 SLO-কে সন্তুষ্ট করে।

খরচের দিক থেকে:

প্রতি সেকেন্ডে 10000 অনুরোধ / সার্ভার প্রতি 2000টি অনুরোধ = 5 সার্ভার + 1

প্রতি সেকেন্ডে 3000টি অনুরোধ

এখানে অ্যাপ্লিকেশনটি 3000ms এর কম p99 লেটেন্সি সহ 60টি অনুরোধ প্রক্রিয়া করতে পারে। SLO লঙ্ঘন করা হয় না, এবং খরচ নিম্নরূপ গ্রহণ করা হয়:

প্রতি সেকেন্ডে 10000 অনুরোধ / সার্ভার প্রতি 3000 অনুরোধ = 4 সার্ভার + 1 (লেখক রাউন্ড আপ করেছেন, প্রায়. অনুবাদক)

এর বিশ্লেষণ আরেকটি রাউন্ড চেষ্টা করা যাক.

বিশ্লেষণ - অনুমান

আমরা প্রতি সেকেন্ডে 3000 অনুরোধে অ্যাপ্লিকেশন ডিবাগ করার ফলাফল সংগ্রহ এবং প্রদর্শন করি:

এখনও 6% সময় সংযোগ স্থাপনে ব্যয় করা হয়। পুল সেট আপ করার ফলে কর্মক্ষমতা উন্নত হয়েছে, কিন্তু আপনি এখনও দেখতে পাচ্ছেন যে অ্যাপ্লিকেশনটি ডাটাবেসের সাথে নতুন সংযোগ তৈরির কাজ চালিয়ে যাচ্ছে।

অনুমান: সংযোগগুলি, একটি পুলের উপস্থিতি সত্ত্বেও, এখনও বাদ দেওয়া এবং পরিষ্কার করা হয়েছে, তাই অ্যাপ্লিকেশনটিকে সেগুলি পুনরায় সেট করতে হবে৷ পুল আকারে মুলতুবি থাকা সংযোগের সংখ্যা সেট করা অ্যাপ্লিকেশনটি একটি সংযোগ তৈরিতে যে সময় ব্যয় করে তা কমিয়ে বিলম্বে সহায়তা করা উচিত.

অ্যাপ্লিকেশন সেট আপ - পরীক্ষা

ইন্সটল করার চেষ্টা করছি MaxIdleCons পুলের আকারের সমান (এছাড়াও বর্ণিত এখানে):

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)
db.SetMaxIdleConns(8)
if err != nil {
   return nil, err
}

নির্বাহ, পর্যবেক্ষণ, বিশ্লেষণ

প্রতি সেকেন্ডে 3000টি অনুরোধ

p99 উল্লেখযোগ্যভাবে কম p60 সহ 100ms এর কম!

শিখা গ্রাফ পরীক্ষা করে দেখায় যে সংযোগটি আর লক্ষণীয় নয়! এর আরো বিস্তারিত চেক করা যাক pg(*conn).query — আমরা এখানে সংযোগ স্থাপন করা লক্ষ্য করি না।

উপসংহার

গ্রাহকের প্রত্যাশা এবং অ-কার্যকরী প্রয়োজনীয়তা পূরণ হচ্ছে তা বোঝার জন্য কর্মক্ষমতা বিশ্লেষণ গুরুত্বপূর্ণ। গ্রাহকের প্রত্যাশার সাথে পর্যবেক্ষণের তুলনা করে বিশ্লেষণ কোনটি গ্রহণযোগ্য এবং কোনটি নয় তা নির্ধারণ করতে সাহায্য করতে পারে। Go স্ট্যান্ডার্ড লাইব্রেরিতে তৈরি শক্তিশালী টুল সরবরাহ করে যা বিশ্লেষণকে সহজ এবং অ্যাক্সেসযোগ্য করে তোলে।

উত্স: www.habr.com