আমি Rust Conf থেকে ফিরছি। Unconf-এ, আমরা অ্যাসিঙ্ক অ্যাপ্লিকেশন ডিবাগিং এবং বেঞ্চমার্কিং নিয়ে একটি ফলপ্রসূ আলোচনা করেছি। অনেক আকর্ষণীয় অন্তর্দৃষ্টি শেয়ার করা হয়েছে। আমি এখানে সেগুলোর কিছু তালিকাভুক্ত করার চেষ্টা করছি, সাথে আমার নিজের কিছু অভিজ্ঞতাও। এটি সেরা অনুশীলনের একটি জীবন্ত নথি হয়ে ওঠার আশায় আমার প্রথম খসড়া। নির্দ্বিধায় একটি issue ফাইল করুন বা একটি PR খুলুন। আমি আগামী দিনগুলোতে একটি নমুনা অ্যাপ যোগ করারও আশা করছি যা এই সমস্যাগুলো এবং dial9 trace কেমন দেখায় তা প্রদর্শন করবে।— Russell

Tokio রানটাইমে ভালো পারফর্ম করে এমন কোড লেখার জন্য খুব কম কঠোর ও নির্দিষ্ট নিয়ম আছে; এত প্রশ্নের উত্তর হলো "এটা নির্ভর করে"। একটি ওয়ার্কলোডের পারফরম্যান্স নির্ভর করে সেই মুহূর্তে রানটাইমে আর কী চলছে তার উপর। এজন্যই এত সমস্যা শুধু প্রোডাকশনে দেখা যায়! ভালো পারফর্ম করে এমন অ্যাসিঙ্ক অ্যাপ্লিকেশন লেখা হলো fairness এবং batching, contention এবং isolation-এর মধ্যে একটি ভারসাম্য। এই পোস্টটি কিছু সাধারণ নীতি তুলে ধরে এবং যেখানে সম্ভব ব্যতিক্রমগুলো কভার করে। এটি Tokio-র work-stealing রানটাইমের সাথে মৌলিক পরিচিতি ধরে নেয়; একটি উচ্চ-স্তরের সারসংক্ষেপ পরিশিষ্টে অন্তর্ভুক্ত আছে।

সাধারণ নীতিমালা

প্রথমে, নির্ধারণ করুন আপনার সত্যিই কোনো সমস্যা আছে কি না। আপনি যদি একটি Tokio অ্যাপ্লিকেশনে red flags খুঁজতে শুরু করেন, আপনি সেগুলো পাবেন। আমি যত প্রায় প্রতিটি বাস্তব অ্যাপ্লিকেশন দেখেছি, তার polls 10-100 মাইক্রোসেকেন্ড-এর চেয়ে অনেক বেশি, যা Alice Ryhl তার অসাধারণ পোস্ট What is Blocking?-এ সুপারিশ করেছেন। এই সমস্যাগুলো আপনার আসলে যে অ্যাপ্লিকেশন মেট্রিক্স বা আচরণ নিয়ে চিন্তা করেন তা প্রভাবিত করতে পারে বা নাও পারে। আপনি যে বাস্তব মেট্রিক উন্নত করার চেষ্টা করছেন তা থেকে পিছনে কাজ করা গুরুত্বপূর্ণ। উদাহরণস্বরূপ, একটি অ্যাপ্লিকেশনে দীর্ঘ polls থাকতে পারে যা সম্পূর্ণ নিরীহ; সেগুলো "ঠিক" করলে ব্যবহারকারী-মুখী মেট্রিক্সে পরিমাপযোগ্য প্রভাব পড়বে না। আমি যে বিপুল সংখ্যাগরিষ্ঠ সমস্যার মুখোমুখি হয়েছি, সমস্যাটি ছিল অ্যাপ্লিকেশন কোডেই, প্রায়শই একটি বিতরণকৃত সিস্টেমের একাধিক কম্পোনেন্টের মধ্যে মিথস্ক্রিয়ায় (এবং আসলে Tokio-তে নয়)। dial9 Tokio-তে অনেক দৃশ্যমানতা দিয়েছে; অন্তত যতবার এটি একটি Tokio সমস্যা খুঁজে পায়, ততবারই এটি আসলে স্পষ্টভাবে এর অনুপস্থিতি প্রদর্শন করে। অবশ্যই, মাঝে মাঝে এটি Tokio-র সমস্যা। Tokio মেট্রিক্সের ক্ষেত্রে, সবচেয়ে উপযোগী হলো সম্প্রতি যোগ করা schedule latency histogram। Schedule latency হলো আপনার টাস্ক চালানোর জন্য প্রস্তুত হওয়া এবং Tokio আসলে future-টি poll করার মধ্যে সময়ের পরিমাণ। যদিও এটি আপনাকে কারণ কী তা বলবে না, scheduling latency হলো Tokio এবং আপনার কোডের মধ্যে দুর্বল মিথস্ক্রিয়ার সবচেয়ে সাধারণ লক্ষণ।

লেটেন্সির জন্য ভাগ করুন, থ্রুপুটের জন্য ব্যাচ করুন। লেটেন্সি অপ্টিমাইজ করতে আরও ঘন ঘন yield করুন। অনেক রিকোয়েস্ট জুড়ে কম লেটেন্সির জন্য সংযোগগুলোর মধ্যে fairness প্রয়োজন। Redis (বা request pipelining সমর্থন করে এমন যেকোনো অ্যাপ্লিকেশন) বিবেচনা করুন। একটি naive বাস্তবায়ন সরাসরি সংযোগ থেকে ডেটা পড়বে যতক্ষণ আরও ডেটা উপলব্ধ থাকে। যখন রিকোয়েস্টগুলো pipelined হয়, পুরো pipelined রিকোয়েস্ট একটি ইন-মেমরি বাফারে শেষ হবে। যখন আপনি এটি থেকে frames পড়েন, প্রতিটি Poll::Ready হবে নেটওয়ার্কে ফিরে না গিয়েই। এটি দীর্ঘ polls এবং ক্লায়েন্টদের মধ্যে unfairness উভয়ই তৈরি করে। থ্রুপুটে প্রভাব সাধারণত ছোট: একই সংখ্যক রিকোয়েস্ট প্রক্রিয়া করা হয়। তবে লেটেন্সি নাটকীয়ভাবে পরিবর্তিত হয় কারণ একটি সম্পূর্ণ pipeline অন্যটির পিছনে অপেক্ষা করতে পারে। এই উদাহরণে প্রতিটি রিকোয়েস্টের পরে স্পষ্টভাবে yield করলে লেটেন্সি প্রায় 10× কমতে পারে। আপনি শুধুমাত্র কয়েকটি ধারাবাহিক তাৎক্ষণিকভাবে-প্রস্তুত reads-এর পরে yield করে আরও ভালো করতে পারেন।

মূল সত্তা: কোম্পানি: Tokio, Redis | ব্যক্তি: Russell, Alice Ryhl | স্থান: Rust Conf