আগের কিস্তিতে আমি আপনার রেডিস ইনস্ট্যান্সকে ধীর হওয়া থেকে রোধ করার বিষয় এবং পদ্ধতি নিয়ে আলোচনা করেছি। এখন পরিমাপ করার উপায়গুলি পরীক্ষা করার সময় কর্মক্ষমতা।
কি পরিমাপ করতে হবে
এই কিস্তির জন্য, আমরা কমান্ড লেটেন্সি এবং এর উপাদানগুলি দেখছি। কেন? কারণ রেডিস সার্ভার/লাইব্রেরির মাধ্যমে আপনি যতগুলো কমান্ড পুশ করতে পারেন তা প্রতিটি কমান্ডের গতির ফলাফল।
দ্রুত এবং সহজ:CLI
আপনার কমান্ড লেটেন্সি চেক করার প্রথম উপায় হল কমান্ড লাইন ক্লায়েন্ট redis-cli ব্যবহার করা . এটি দ্রুত এবং আপনাকে শুরু করার জন্য একটি অবিলম্বে চেকপয়েন্ট দেয়। এখানে উদাহরণগুলি সরলতার জন্য লোকালহোস্ট ব্যবহার করা হবে, তবে আপনার সেটআপে আপনার -h <host> ব্যবহার করা উচিত বিকল্প এবং প্রয়োজন হলে -a <auth> এবং -p <port> .
বেসিক লেটেন্সি
মৌলিক লেটেন্সি ফলাফল পেতে redis-cli –latency চালান। এটি সর্বনিম্ন, সর্বোচ্চ, গড় এবং পুনরাবৃত্তির সংখ্যা নির্দেশ করে সংখ্যার একটি সেট আউটপুট করবে। এই পুনরাবৃত্তিগুলি একটি খোলা সংযোগের বিরুদ্ধে Redis কমান্ড PING চালানোর সমন্বয়ে গঠিত। ফলস্বরূপ এটি সার্ভারের সাথে সংযোগ করার জন্য কোন সময় অন্তর্ভুক্ত করে না। যদি আপনার কোড প্রতিটি কমান্ডের সাথে সংযোগ করে তাহলে আপনি এই কমান্ড নির্দেশ করার চেয়ে অনেক খারাপ কর্মক্ষমতা দেখতে পাবেন।
আপনি এটিকে হত্যা না করা পর্যন্ত এই কমান্ডটি চলবে—সিটিআরএল-সি এর মাধ্যমে সহজে সম্পন্ন হয়। লেটেন্সি সংখ্যা মিলিসেকেন্ডে। এইভাবে এর ফলাফল:
min: 0, max: 1, avg: 0.11 (11369 samples)মানে ন্যূনতম বিলম্ব ছিল 1 মিলিসেকেন্ডের কম, সর্বোচ্চ ছিল 1 মিলিসেকেন্ড, গড় প্রতি PING লেটেন্সি 0.11 মিলিসেকেন্ড। হ্যাঁ, এটি একটি স্থানীয় হোস্ট সংযোগ। এই সংখ্যাগুলি 11,369 "নমুনা" বা PING কমান্ড থেকে গণনা করা ফলাফল।
বিকল্পভাবে, আপনি পরিবর্তে –latency-history ব্যবহার করতে পারেন। এই বিকল্পটি আপনাকে এটিকে টেম্পোরাল স্লাইসে বিভক্ত করতে দেয়। redis-cli –latency-history চালানো হলে 15 সেকেন্ডের একটি ডিফল্ট উইন্ডো ব্যবহার করা হবে। ফলাফলটি এরকম কিছু দেখাবে:
min: 0, max: 1, avg: 0.11 (1475 samples) -- 15.01 seconds range
min: 0, max: 1, avg: 0.10 (1474 samples) -- 15.01 seconds range-latency এর মতো, এই কমান্ডটি চলবে যতক্ষণ না আপনি এটিকে হত্যা করবেন। আপনি যদি একটি ভিন্ন বিরতি দিয়ে চালাতে চান তবে আপনি পাস করতে পারেন -i। যেমন:
redis-cli --latency-history -i 10
min: 0, max: 1, avg: 0.11 (984 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.11 (983 samples) -- 10.01 seconds range
min: 0, max: 1, avg: 0.11 (983 samples) -- 10.01 seconds rangeযেহেতু এই ক্রিয়াকলাপগুলি কেবল PING কমান্ড ব্যবহার করে এটি Redis-এর যেকোনো সংস্করণের বিরুদ্ধে কাজ করবে৷
৷ইন্ট্রিনসিক লেটেন্সি
প্রথম নজরে, নামটি আপনাকে বিশ্বাস করতে পারে যে অভ্যন্তরীণ লেটেন্সি মোড সার্ভারের অন্তর্নিহিত লেটেন্সি পরিমাপ করছে। এটা নয়। আপনি যদি GitHub-এ redis-cli উত্সটি দেখেন তবে আপনি দেখতে পাবেন এটি এমনকি সার্ভারের সাথে কথা বলে না:
start = ustime();
compute_something_fast();
end = ustime();
latency = end-start;অভ্যন্তরীণ লেটেন্সি মোডে উৎসের মন্তব্য অনুসারে:
একটি চলমান প্রক্রিয়ার সর্বাধিক লেটেন্সি পরিমাপ করুন যা syscalls এর ফলে হয় না। মূলত এই সফ্টওয়্যারটির একটি ইঙ্গিত দেওয়া উচিত যে কার্নেলটি চালানোর সুযোগ ছাড়াই কত সময় প্রক্রিয়াটি ছেড়ে যায়৷
এটি যা করছে তা হল আপনার ক্লায়েন্ট হোস্টে অভ্যন্তরীণ লেটেন্সি পরীক্ষা করা৷ . সমস্যাটি আসলে সার্ভারের পরিবর্তে ক্লায়েন্টের দিকে রয়েছে কিনা তা জানার জন্য এটি কার্যকর।
কাজেই উপকারী হলেও এটি সম্ভবত আপনার লেটেন্সি চেক করার প্রথম ধাপে থাকা উচিত নয়। আপডেট করুন :সালভাতোরের সাথে কথা বলার পর তিনি নিশ্চিত করেছেন যে সার্ভার থেকে এই কমান্ডটি চালানোর উদ্দেশ্য। এর মানে হল আপনার Redis সার্ভারে শেল অ্যাক্সেস থাকলে এটি কার্যকর হতে পারে, কিন্তু অন্যথায় এটি কার্যকর নয়—যদি আপনি একটি Redis পরিষেবা প্রদানকারী ব্যবহার করেন তবে এটি সাধারণত হয়৷
কমিসার ব্যবহার করা
কমিসার একটি ছোট স্যুট যা আমি রেডিস লেটেন্সি এবং সামগ্রিক কর্মক্ষমতা ট্র্যাকিং এবং পরীক্ষা করার জন্য কাজ করছি। সতর্কতা:এটি বিকাশের প্রথম দিকে এবং সম্ভবত অনেক পরিবর্তন হবে। এই কারণে, যদি আপনি অ-উৎপাদন মানের সফ্টওয়্যার ব্যবহার করে স্বাচ্ছন্দ্য বোধ করেন তবেই এটি ব্যবহার করুন। কমিসার গিথুব কমিসার রিপোজিটরিতে রয়েছে।
বিশেষ করে এই নিবন্ধটির জন্য আমরা লেটেন্সি টুল/ডিরেক্টরি দেখব।
এনভায়রনমেন্ট ভেরিয়েবলের মাধ্যমে কনফিগার করা এই টুলটি একটি প্রদত্ত রেডিস ইনস্ট্যান্সের সাথে সংযোগ করবে এবং redis-cli-এর মতো একই "PING কমান্ড" মেকানিজম চালাবে। আমি পরীক্ষার সমতা বজায় রাখতে এটি করেছি। যেখানে এটি আরও তথ্য আউটপুট করার ক্ষমতা এবং (বর্তমানে) মঙ্গোডিবিতে সংরক্ষণ করার ক্ষমতার মধ্যে পার্থক্য করে—আসতে আরও স্টোর সহ৷
বিলম্বের একটি দৌড় এইরকম দেখতে পারে, যদিও এই নিবন্ধটি লেখার পর থেকে আউটপুট পরিবর্তিত হওয়ার সম্ভাবনা রয়েছে:
./latency
Connected to <host:ip>
100000 iterations over 53698us, average 536us/operation
Percentile breakout:
====================
99.00%: 3,876.99us
95.00%: 640.00us
90.00%: 514.00us
75.00%: 452.00us
50.00%: 414.00us
Min: 243us
Max: 44,686us
Mean: 536.98us
Jitter: 764.37usলক্ষ্য করুন এই দৌড়ে টেম্পোরাল ইউনিট হল 'আমরা' (অর্থাৎ মাইক্রোসেকেন্ড)। এছাড়াও, আপনি দেখতে পাচ্ছেন এটি আপনাকে শতকরা ব্রেকআউট দেবে। এটি আপনাকে একটি সাধারণ মিনিট/সর্বোচ্চ/গড়ের তুলনায় লেটেন্সি কেমন দেখাচ্ছে তার একটি ভাল ছবি পেতে দেয়৷ এই প্রসঙ্গে 'জিটার' হল নমুনার আদর্শ বিচ্যুতি।
এই আউটপুটটি আমাদেরকে বলে যে সামগ্রিকভাবে আমরা বেশ ভাল দেখাচ্ছে। এই বিশেষ উদাহরণটি একটি ব্যক্তিগত নেটওয়ার্কের উপর। আমরা দেখতে পাচ্ছি পিক গড় থেকে অনেক বেশি, কিন্তু 95% পুনরাবৃত্তি 640 মাইক্রোসেকেন্ডে বা তার নিচে আসে। এটা আমাদের কি বলে?
এটি আমাদের বলতে পারে যে একটি বিক্ষিপ্ত নেটওয়ার্ক সমস্যা, একটি বিক্ষিপ্ত সার্ভার-সাইড বিলম্ব বা এমনকি পরীক্ষার ক্লায়েন্টে আবর্জনা নিয়ন্ত্রণের মতো কিছু আউটপুটকে প্রভাবিত করছে। এই কারণেই অনুরোধের বিতরণ উপলব্ধ করা হয়েছে:যাতে আপনি দেখতে পারেন একটি "উচ্চ" ফলাফল কতটা সাধারণ৷
সমস্যাটি কোথায় তা নির্ধারণ করার জন্য, আপনি প্রথমে সার্ভারের কমান্ডগুলি কতক্ষণ সময় নিচ্ছে তা দেখতে চাইবেন। সার্ভারে সমস্যা হলে এটি আমাদের বলবে৷
৷এই ক্ষেত্রে, উদাহরণস্বরূপ, আপনি redis তথ্য আউটপুট পরীক্ষা করতে চাইতে পারেন, বিশেষভাবে Commandstats বিভাগে দেখে:
redis-cli info commandstats
# Commandstats
cmdstat_ping:calls=32497193,usec=22213723,usec_per_call=0.68এখানে আমরা দেখতে পাচ্ছি যে সার্ভারে PING চালানোর গড় সময় হল 0.68 মাইক্রোসেকেন্ড। স্পষ্টতই পিং কমান্ড নিজেই সম্ভবত অপরাধী নয়। যাইহোক, পরীক্ষার সময় অন্যান্য কমান্ড কার্যকর করা হতে পারে যা রেডিস প্রক্রিয়াকে ব্যাক আপ করে যার ফলে বিলম্ব হয়।
লেটেন্সি টুলের একটি সাম্প্রতিক সংযোজন হল সমবর্তী লেটেন্সি পরীক্ষা চালানোর ক্ষমতা। LATENCY_CLIENTCOUNT এ এনভায়রনমেন্ট ভেরিয়েবল সেট করে, আপনি আপনার Redis সার্ভারে একাধিক কানেকশন চালাতে পারেন এবং দেখতে পারেন কতটা কনকারেন্সি আপনার লেটেন্সি ফলাফলকে প্রভাবিত করে। উদাহরণস্বরূপ, আপনি একটি সাধারণ রেডিস পিং কমান্ডের পার্থক্য দেখতে পারেন যখন আপনার 100 এর বিপরীতে 10টি ক্লায়েন্ট থাকে বা এমনকি 1000 সমবর্তী ক্লায়েন্ট থাকে। আপনি উন্নয়ন/মঞ্চায়ন এবং উৎপাদনের মধ্যে যে পার্থক্যটি অনুভব করছেন তা দেখতে এটি কার্যকর হতে পারে।
পাত্র থেকে পরীক্ষা করা হচ্ছে
ডকার কন্টেইনার থেকে আপনার পরীক্ষা চালাতে পছন্দ করেন? আমি এখন তৈরি করা ডকার কন্টেইনারগুলিকে পাবলিক ডকার রেজিস্ট্রিতে ঠেলে দিচ্ছি যেগুলির মধ্যে কেবলমাত্র গোলাটেন্সি টুল রয়েছে৷ আপনি যদি একটি ডকার পুল দ্য রিয়ালবিল/গোলাটেন্সি করেন তবে আপনি ছবিটি পাবেন, যা কয়েক সেকেন্ডের মধ্যে চালানোর জন্য প্রস্তুত (বর্তমানে এটির ওজন 4MB ছবির আকারের কম)।
রিডমি ইঙ্গিত অনুসারে সংযোগ এবং কনফিগার করতে এনভায়রনমেন্ট ভেরিয়েবলের সাথে ডকার রানকে কল করুন। তারপরে, stdout থেকে আউটপুট টানুন বা, যদি ডেমন হিসাবে চালানো হয়, ডকার লগের মাধ্যমে, এবং আপনাকে কিছু তৈরি করতে হবে না। যখনই আমি টুলটিতে উল্লেখযোগ্য পরিবর্তন করি, ডকার রেপো একটি নতুন চিত্রের সাথে আপডেট হয়। বিকল্পভাবে, রেপোতে একটি ডকারফাইল রয়েছে, যা আপনাকে আপনার ইচ্ছামত কাস্টমাইজ করার অনুমতি দেয়।
চূড়ান্ত চিন্তা
রেডিসের সাথে আপনার কর্মক্ষমতা বিশ্লেষণ করা কঠিন হতে পারে। সৌভাগ্যবশত, লেটেন্সি এবং থ্রুপুট এবং এগুলি কীভাবে আপনার অ্যাপ্লিকেশনকে প্রভাবিত করে তা বোঝার সাথে, আপনি Redis-এর পরিবর্তে আপনার অ্যাপ্লিকেশনের Redis-এর ব্যবহার বিশ্লেষণে আরও বেশি মনোযোগ দিতে পারেন। আপনি রেডিস-এর জেন অফ রেডিসের বাক্যাংশ "পারফরম্যান্সের মূল চাবিকাঠি রেডিসকে কমিয়ে দিচ্ছে না" মনে রেখে রেডিস কীভাবে সর্বোত্তম ব্যবহার করা যায় সে সম্পর্কে আপনার ব্যবহার এবং বোঝার উন্নতি করতে পারবেন, যখন নেটওয়ার্ক সমস্যাগুলি এবং ডেটা কাঠামোর বিকল্পগুলিকে আলাদা করে আরও স্মার্ট, আরও দক্ষ অ্যাপ্লিকেশন তৈরি করতে পারবেন। , এর ফলে ভালো পারফরম্যান্স হয়।
