পূর্ববর্তী ইনস্টলমেন্টে আমি টপিক্স এবং আপনার Redis ইনস্ট্যান্স স্লো হয়ে যাওয়া থেকে বাধা দিতে আপনাকে আপনার রিচেটস এবং অপ্রোচ দিয়ে আলোচনা করেছিলাম। এখন সময় পারফরম্যান্স মাপার উপায়গুলো পরীক্ষা করার।
কী মাপব
এই ইনস্টলমেন্টে, আমরা কমান্ড ল্যাটেন্সি এবং এর কম্পোনেন্টগুলো দেখব। কেন? কারণ আপনি একটি Redis সার্ভার/লাইব্রেরির মাধ্যমে কতগুলো কমান্ড পুশ করতে পারবেন সেটি প্রতিটি কমান্ডের স্পিডের একটি ফলাফল।
কুইক এবং ইজি: CLI
আপনার কমান্ড ল্যাটেন্সি চেক করার প্রথম উপায় হলো কমান্ড লাইন ক্লায়েন্ট redis-cli ব্যবহার করা। এটি কুইক এবং আপনাকে একটি ইমিডিয়েট চেকপয়েন্ট দেয় শুরু করার জন্য। এখানে উদাহরণগুলো localhost ব্যবহার করবে সিম্পলিসিটির জন্য, কিন্তু আপনার সেটআপে আপনার -h <host> অপশন এবং যদি দরকার হয় -a <auth> এবং -p <port> ব্যবহার করা উচিত।
বেসিক ল্যাটেন্সি
বেসিক ল্যাটেন্সি রেজাল্ট পেতে redis-cli --latency রান করুন। এটি একটি সেট নম্বর আউটপুট করবে মিন, ম্যাক্স, এভারেজ, এবং ইটেরেশন সংখ্যা নির্দেশ করে। এই ইটেরেশনগুলো একটি ওপেন কানেকশন এর বিরুদ্ধে Redis কমান্ড PING রান করার கொண்டিস্ট। ফলস্বরূপ এতে সার্ভারের সাথে কানেক্ট করার টাইম ইনক্লুড করা নেই। আপনার কোড যদি প্রতিটি কমান্ডে কানেক্ট করে, আপনি এই কমান্ড ইন্ডিকেট করবে এর চেয়ে খুব খারাপ পারফরম্যান্স।
এই কমান্ডটি তখনও চলবে যতক্ষণ না আপনি এটিকে কিল করেন — সহজে CTRL-C দিয়ে করা যায়। ল্যাটেন্সি নম্বরগুলো মিলিসেকেন্ডে। তাই একটি ফলাফল:
min: 0, max: 1, avg: 0.11 (11369 samples)
মানে মিনিমাম ল্যাটেন্সি ১ মিলিসেকেন্ডের কম, ম্যাক্সিমাম ১ মিলিসেকেন্ড, এভারেজ প্রতি-PING ল্যাটেন্সি ০.১১ মিলিসেকেন্ড। হ্যাঁ, এটি একটি লোকালহোস্ট কানেকশন। এই নম্বরগুলো ১১,৩৬৯ "স্যাম্পল" বা PING কমান্ড থেকে কম্পিউটেড।
বিকল্পভাবে, আপনি --latency-history ব্যবহার করতে পারেন। এই অপশনটি আপনাকে টেম্পোরাল স্লাইসে ব্রেক আউট করতে দেয়। redis-cli --latency-history রান করলে ১৫ সেকেন্ডের একটি ডিফল্ট উইন্ডো ব্যবহার করবে। ফলাফল এমন দেখাবে:
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-এর যেকোনো ভার্সনের বিরুদ্ধে কাজ করা উচিত।
ইনট্রিনসিক ল্যাটেন্সি
প্রথম নজরে, নামটি আপনাকে বিশ্বাস করতে পারে ইনট্রিনসিক ল্যাটেন্সি মোড সার্ভারের ইনট্রিনসিক ল্যাটেন্সি মাপছে। এটি নয়। আপনি যদি redis-cli সোর্স GitHub-এ দেখেন আপনি পাবেন এটি সার্ভারের সাথে কথা বলে না:
start = ustime(); compute_something_fast(); end = ustime(); latency = end-start;
ইনট্রিনসিক ল্যাটেন্সি মোড-র সোর্স কমেন্ট অনুযায়ী:
একটি রানিং প্রসেসের ম্যাক্স ল্যাটেন্সি মাপুন যা সিসক্যালস থেকে রেজাল্ট হয় না। বেসিক্যালি এই সফ্টওয়্যারটি একটি হিন্ট দিতে পারে কতটুকু টাইম কার্নেল প্রসেসকে ছাড়া রেখে চলে রান করার সুযোগ ছাড়া।
এটি যা করছে আপনার ক্লায়েন্ট হোস্টে ইনট্রিনসিক ল্যাটেন্সি টেস্ট করছে। এটি জানতে উপযোগী যে সমস্যাটি আসলে ক্লায়েন্ট সাইডে কিনা সার্ভারের চেয়ে।
তাই যদিও উপযোগী এটা সম্ভবত আপনার ল্যাটেন্সি চেক করার প্রথম ধাপে থাকা উচিত নয়। আপডেট: সালভাটোরের সাথে কথা বলার পর তিনি কনফার্ম করেছেন উদ্দেশ্য হলো এই কমান্ডটি সার্ভার থেকে রান করা। এর মানে এটি উপযোগী হতে পারে আপনার শেল অ্যাক্সেস থাকলে আপনার Redis সার্ভারের, কিন্তু অন্যথায় উপযোগী নয় — যা সাধারণ কেস আপনি যদি একটি Redis সার্ভিস প্রোভাইডার ব্যবহার করেন।
Commissar ব্যবহার করা
Commissar একটি ছোট স্যুট যা আমি কাজ করছি Redis ল্যাটেন্সি এবং ওভারঅল পারফরম্যান্স ট্র্যাক এবং টেস্ট করার জন্য। সতর্কতা: এটি ডেভেলপমেন্টে আজও অর্লি এবং অনেক কিছু পরিবর্তন হতে পারে। এই কারণেই, শুধু ব্যবহার করুন যদি আপনি নন-প্রোডাকশন কোয়ালিটি সফ্টওয়্যার ব্যবহার করতে কমফরটেবল ফীল করেন। Commissar Github Commissar Repository-তে রয়েছে।
এই আর্টিকেলের জন্য স্পেসিফিক্যালি আমরা ল্যাটেন্সি টুল/ডিরেক্টরিতে দেখব।
এই টুল, এনভায়রনমেন্ট ভেরিয়েবল দিয়ে কনফিগারড, একটি দিয়ে যেওয়া Redis ইনস্ট্যান্সের সাথে কানেক্ট করবে এবং সেম "time the PING command" মেকানিজম রান করবে যা redis-cli করে। আমি এটা করলাম টেস্টের parody মেইনটেইন করার জন্য। যেখানে এটি ডিফার করে সেটি হলো এর অ্যাবিলিটি আরও ইনফরমেশন আউটপুট করতে এবং (বর্তমানে) MongoDB-এ স্টোর করতে — আরও স্টোর আসছে।
latency-এর একটি রান এমন দেখতে পারে, যদিও আউটপুট সম্ভবত পরিবর্তন হয়েছে যেন এই আর্টিকেল লেখা হয়েছিল:
./latency
Connected to
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
লক্ষ্য করুন টেম্পোরাল ইউনিট 'us' (অর্থাৎ মাইক্রোসেকেন্ড) এই রানে। এছাড়া, আপনি দেখতে পাচ্ছেন এটি পেরসেন্টাইল ব্রেকআউট দেবে। এটি আপনাকে ল্যাটেন্সি কেমন দেখাচ্ছে সেটির একটি ভালো ছবি দেয় একটি সিম্পল মিন/ম্যাক্স/এভারেজের চেয়ে। এই কনটেক্সটে 'Jitter' হলো স্যাম্পলের স্ট্যান্ডার্ড ডেভিয়েশন।
এই আউটপুট আমাকে বলে যে ওভারঅল আমরা খুব ভালো দেখছি। এই নির্দিষ্ট উদাহরণ একটি প্রাইভেট নেটওয়ার্কের ওভার। আমরা দেখতে পাচ্ছি পিক অনেক বেশি মিনের চেয়ে, কিন্তু ৯৫% ইটেরেশন ৬৪০ মাইক্রোসেকেন্ড বা কমে আসছে। এটা আমাদের কী বলে?
এটা বোঝাতে পারে একটি স্পোরাডিক নেটওয়ার্ক ইস্যু, একটি স্পোরাডিক সার্ভার-সাইড ডিলে, বা এমনকি টেস্ট ক্লায়েন্টে গার্বেজ কন্ট্রোল আউটপুটকে প্রভাবিত করছে। এটিই কারণ রিকোয়েস্টের ডিস্ট্রিবিউশন উপলব্ধ করা হয়েছে: যাতে আপনি দেখতে পারেন কত কমন একটি "উচ্চ" ফলাফল।
সমস্যা কোথায় সেটি নির্ধারণ করতে, আপনি প্রথমে দেখতে চাবেন সার্ভারে কমান্ডগুলো কতক্ষণ লাগছে। এটা আমাদের বলবে সার্ভার কি সমস্যা।
এই কেসে, উদাহরণস্বরূপ, আপনি redis info আউটপুট চেক করতে চাইতে পারেন, স্পেসিফিক্যালি Commandstats সেকশনে:
redis-cli info commandstats
# Commandstats
cmdstat_ping:calls=32497193,usec=22213723,usec_per_call=0.68
এখানে আমরা দেখতে পাচ্ছি PING এক্সিকিউট করার সার্ভারে এভারেজ টাইম ০.৬৮ মাইক্রোসেকেন্ড। স্পষ্টভাবে পিং কমান্ডই কালপ্রিট নয়। যাইহোক, টেস্ট চলাকালীন অন্য কমান্ড এক্সিকিউট হতে পারে যেগুলো Redis প্রসেসকে ব্যাক আপ করছে ডিলে সৃষ্টি করে।
latency টুলে একটি সাম্প্রতিক অ্যাডিশন হলো কনকারেন্ট ল্যাটেন্সি টেস্ট রান করার ক্ষমতা। LATENCY_CLIENTCOUNT এনভায়রনমেন্ট ভেরিয়েবল সেট করে, আপনি আপনার Redis সার্ভারের সাথে একাধিক কানেকশন রান করতে পারেন এবং দেখতে পারেন কনকারেন্সি কতটুকু আপনার ল্যাটেন্সি রেজাল্টকে প্রভাবিত করে। উদাহরণস্বরূপ আপনি পার্থক্য দেখতে পারেন একটি সিম্পল Redis PING কমান্ড ১০ ক্লায়েন্ট বনাম ১০০, অথবা এমনকি ১০০০ কনকারেন্ট ক্লায়েন্টের সাথে কী দেখে। এটি উপযোগী হতে পারে ডেভেলপমেন্ট/স্টেজিং এবং প্রোডাকশনের মধ্যে পার্থক্য দেখতে যা আপনি এক্সপেরিয়েন্স করছেন।
কন্টেইনার থেকে টেস্ট করা
Docker কন্টেইনার থেকে আপনার টেস্ট রান করতে পছন্দ করুন? আমি এখন বিল্ট Docker কন্টেইনার পশ করি যেগুলো শুধু golatency টুল থাকে সেগুলো পাবলিক Docker রেজিস্ট্রিতে। আপনি যদি docker pull therealbill/golatency করেন আপনি ইমেজটি পাবেন, কয়েক সেকেন্ডে রান করার জন্য রেডি (এটি বর্তমানে ৪MB ইমেজ সাইজের নিচে ওজন করে)।
সিম্পলি docker run কল করুন এনভায়রনমেন্ট ভেরিয়েবলস দিয়ে কানেক্ট এবং কনফিগার করার জন্য ReadMe ইন্ডিকেট করে। তারপর, আউটপুট টানুন stdout থেকে বা, যদি ডেমন হিসেবে রান করা হয়, docker logs দিয়ে, এবং আপনাকে কিছু বিল্ড করতে হবে না। যেকোনো সিগনিফিক্যান্ট চেঞ্জ আমি টুলে করলে, Docker রেপো আপডেট হয়ে যায় একটি নিউ ইমেজের সাথে। বিকল্পভাবে, রেপোতে একটি Dockerfile রয়েছে, আপনাকে কাস্টোমাইজ করতে দেয় আপনার ইচ্ছামত।
চূড়ান্ত চিন্তা
Redis-র সাথে পারফরম্যান্স বিশ্লেষণ করা ট্রিকি হতে পারে। সৌভাগ্যয়, ল্যাটেন্সি এবং থ্রুপুট এবং কীভাবে সেগুলো আপনার অ্যাপ্লিকেশনকে প্রভাবিত করে সেটি বুঝতে পারলে, আপনি আরও ফোকাস করতে পারেন আপনার অ্যাপ্লিকেশনর Redis ব্যবহার বিশ্লেষণ করার ওপর বরং Redis নিজে। আপনি আপনার ব্যবহার এবং বুঝ উন্নত করবেন কীভাবে সেরা Redis ব্যবহার করতে হয় "Zen of Redis"-র ফ্রেজ "The key to performance is not slowing Redis down" মনে রেখে, নেটওয়ার্ক ইস্যু এবং ডেটা স্ট্রাকচার অল্টারনেটিভ আইসোলেট করে, স্মার্টার, আরও ইফিশিয়েন্ট অ্যাপ্লিকেশন প্রডিউস করে, বেটার পারফরম্যান্স ফলাফলে।
