এএসপি.নেট এমভিসিতে অ্যাসিঙ্ক ক্রিয়াগুলি ব্যবহার করে আমার কিছু উদ্বেগ রয়েছে। এটি কখন আমার অ্যাপ্লিকেশনগুলির কার্যকারিতা উন্নতি করে এবং কখন তা করে না ?
উত্তর:
অ্যাসিঙ্ক্রোনাস অ্যাকশন পদ্ধতিগুলি কার্যকর যখন কোনও ক্রিয়াকলাপটি বেশ কয়েকটি স্বতন্ত্র দীর্ঘ চলমান ক্রিয়াকলাপ সম্পাদন করতে পারে।
AsyncController শ্রেণীর জন্য একটি সাধারণ ব্যবহার দীর্ঘকালীন ওয়েব সার্ভিস কল।
আমার ডাটাবেস কলগুলি কি অ্যাসিঙ্ক্রোনাস হওয়া উচিত?
আইআইএস থ্রেড পুল প্রায়শই ডেটাবেস সার্ভারের চেয়ে অনেকগুলি একইসাথে অবরুদ্ধকরণ অনুরোধগুলি পরিচালনা করতে পারে। ডাটাবেসটি যদি বাধা হয় তবে অ্যাসিঙ্ক্রোনাস কলগুলি ডাটাবেস প্রতিক্রিয়াকে ত্বরান্বিত করবে না। থ্রোটলিং মেকানিজম ব্যতীত, অ্যাসিনক্রোনাস কলগুলি ব্যবহার করে দক্ষতার সাথে একটি অভিভূত ডাটাবেস সার্ভারে দক্ষতার সাথে আরও বেশি কাজ প্রেরণ করা কেবলমাত্র বোঝাটির আরও বেশি ডেটাবেসগুলিতে স্থানান্তরিত করে। আপনার ডিবি যদি বাধা হয় তবে অ্যাসিঙ্ক্রোনাস কলগুলি যাদু বুলেট হবে না।
আপনার 1 এবং 2 রেফারেন্সের দিকে নজর দেওয়া উচিত
@ পানাগিওটিসকানাভোসের মন্তব্য থেকে প্রাপ্ত:
অধিকন্তু, অ্যাসিঙ্কের অর্থ সমান্তরাল নয়। অ্যাসিঙ্ক্রোনাস এক্সিকিউশন কোনও জটিলতা বা কার্যকারিতা ব্যয় ছাড়াই বাহ্যিক সংস্থার জন্য ব্লকিং থেকে মূল্যবান থ্রেডপুলের থ্রেড মুক্ত করে fre এর অর্থ একই আইআইএস মেশিনটি আরও সমবর্তী অনুরোধগুলি পরিচালনা করতে পারে, এটি দ্রুত চালিত হবে না।
আপনার এও বিবেচনা করা উচিত যে ব্লকিং কলগুলি একটি সিপিইউ-নিবিড় স্পিনওয়েট দিয়ে শুরু হয়। স্ট্রেসের সময়ে, কলগুলি ব্লক করার ফলে বিলম্ব এবং অ্যাপ পুল পুনর্ব্যবহারের ফলাফল বাড়বে। অ্যাসিঙ্ক্রোনাস কলগুলি কেবল এটিকে এড়িয়ে চলে
আপনি এই বিষয়টিতে আমার এমএসডিএন নিবন্ধটি সহায়ক পেতে পারেন ; আপনাকে কখনasync এএসপি.এনইটি ব্যবহার করা উচিত , কেবল এএসপি.এনইটি কীভাবে ব্যবহার করবেন তা নয় এই নিবন্ধে আমি প্রচুর জায়গা নিয়েছি async।
এএসপি.নেট এমভিসিতে অ্যাসিঙ্ক ক্রিয়াগুলি ব্যবহার করে আমার কিছু উদ্বেগ রয়েছে। এটি কখন আমার অ্যাপ্লিকেশনগুলির কার্যকারিতা উন্নত করে এবং কখন - না।
প্রথমে বুঝতে হবে async/ থ্রেডগুলি মুক্ত করারawait বিষয়ে । জিইউআই অ্যাপ্লিকেশনগুলিতে, এটি মূলত জিইউআই থ্রেডটি মুক্ত করার বিষয়ে তাই ব্যবহারকারীর অভিজ্ঞতা আরও ভাল। সার্ভার অ্যাপ্লিকেশনগুলিতে (এএসপি.নেট এমভিসি সহ), এটি মূলত অনুরোধের থ্রেডটি মুক্ত করার বিষয়ে যাতে সার্ভারটি স্কেল করতে পারে।
বিশেষত, এটি করবে না:
await। awaitব্রাউজারের কাছে নয়, কেবল এএসপি.নেট থ্রেড পুলে কেবল "ফলন" হবে।প্রথম প্রশ্নটি হচ্ছে - এএসপি.নেট এমভিসির সর্বত্র অ্যাসিঙ্ক অ্যাকশনটি ব্যবহার করা ভাল?
আমি বলব যে আপনি যেখানেই I / O করছেন তা এটি ব্যবহার করা ভাল। এটি অগত্যা উপকারী নাও হতে পারে , যদিও (নীচে দেখুন)।
তবে এটি সিপিইউযুক্ত পদ্ধতিতে ব্যবহার করা খারাপ । কখনও কখনও ডেভসরা মনে করেন যে তারা asyncকেবল Task.Runতাদের নিয়ন্ত্রকগুলিতে কল করে তারা এর সুবিধা পেতে পারেন এবং এটি একটি ভয়াবহ ধারণা। কারণ এই কোডটি অন্য থ্রেড গ্রহণ করে অনুরোধের থ্রেডটি মুক্ত করে শেষ করে, তাই কোনও লাভ নেই (এবং বাস্তবে তারা অতিরিক্ত থ্রেডের স্যুইচগুলির জরিমানা নিচ্ছে)!
যখন আমি ডাটাবেসটি জিজ্ঞাসা করতে চাই তখন কী আমি async ব্যবহার করব / কীওয়ার্ডগুলির জন্য অপেক্ষা করব (EF / NHibernate / অন্যান্য ORM এর মাধ্যমে)?
আপনি উপলব্ধ যে অপেক্ষাকৃত পদ্ধতি ব্যবহার করতে পারেন। এই মুহুর্তে বেশিরভাগ প্রধান খেলোয়াড় সমর্থন করে asyncতবে কয়েকটি আছে যা তা দেয় না। যদি আপনার ওআরএম সমর্থন করে না async, তবে এটিকে Task.Runবা এর মতো কোনও কিছুতে জড়ানোর চেষ্টা করবেন না (উপরে দেখুন)।
নোট করুন যে আমি বলেছিলাম "আপনি ব্যবহার করতে পারেন"। যদি আপনি একটি একক ডাটাবেস ব্যাকএন্ডের সাথে এএসপি.নেট এমভিসি সম্পর্কে কথা বলছেন তবে আপনি (প্রায় অবশ্যই) এর থেকে কোনও স্কেলিবিলিটি সুবিধা পাবেন না async। কারণ আইআইএস এসকিউএল সার্ভারের (বা অন্যান্য ক্লাসিক আরডিবিএমএস) একক উদাহরণের চেয়ে অনেক বেশি সমবর্তী অনুরোধগুলি পরিচালনা করতে পারে। তবে, যদি আপনার ব্যাকএন্ডটি আরও আধুনিক হয় - একটি এসকিউএল সার্ভার ক্লাস্টার, অ্যাজুরে এসকিউএল, নোএসকিউএল ইত্যাদি - এবং আপনার ব্যাকএন্ড স্কেল করতে পারে এবং আপনার স্কেলিবিলিটি বাধা আইআইএস হয়, তবে আপনি এর থেকে একটি স্কেলিবিলিটি সুবিধা পেতে পারেন async।
তৃতীয় প্রশ্ন - একক ক্রিয়াকলাপ পদ্ধতিতে আমি সংখ্যক ডাটাবেসকে জিজ্ঞাসা করতে কীওয়ার্ডের জন্য অপেক্ষা করতে পারি?
আপনার পছন্দ হিসাবে অনেক। তবে নোট করুন যে অনেকগুলি ওআরএম-এর প্রতি-সংযোগের ওয়ান-অপারেশন রয়েছে। বিশেষত, EF কেবলমাত্র DbContext প্রতি একক ক্রিয়াকলাপের অনুমতি দেয়; অপারেশন সিঙ্ক্রোনাস বা অ্যাসিনক্রোনাস কিনা তা সত্য।
এছাড়াও, আপনার ব্যাকএন্ডের স্কেলিবিলিটিটি আবার মনে রাখবেন। আপনি যদি এসকিউএল সার্ভারের একক উদাহরণটি মারছেন, এবং আপনার আইআইএস ইতিমধ্যে এসকিউএল সার্ভারকে সম্পূর্ণ ক্ষমতা ধরে রাখতে সক্ষম হয়, তবে এসকিউএল সার্ভারের উপর চাপ দ্বিগুণ করা বা তিনগুণ বাড়ানো আপনাকে মোটেই সহায়তা করবে না।
এএসপি.নেট এমভিসি-তে সর্বত্র async ক্রিয়াটি ব্যবহার করা ভাল?
প্রোগ্রামিংয়ে যথারীতি এটি নির্ভর করে । কোনও নির্দিষ্ট পথে নামার সময় সর্বদা বাণিজ্য থাকে is
async-awaitএমন জায়গাগুলিতে জ্বলজ্বল করে যেখানে আপনি জানেন যে আপনি আপনার পরিষেবাদিতে একযোগে অনুরোধ পাবেন এবং আপনি ভালভাবে স্কেল করতে সক্ষম হতে চান । async-awaitস্কেলিং আউট সাহায্য কিভাবে ? আপনি যখন অ্যাসিঙ্ক আইও কলকে সিঙ্ক্রোনালি অনুরোধ করেন যেমন একটি নেটওয়ার্ক কল বা আপনার ডাটাবেস হিট করা হয় তখন বর্তমান থ্রেড যা কার্যকর করার জন্য দায়ী তা অনুরোধটি শেষ হওয়ার অপেক্ষায় অবরুদ্ধ থাকে। আপনি যখন ব্যবহার করেন async-await, আপনি আপনার জন্য একটি স্টেট মেশিন তৈরি করতে ফ্রেমওয়ার্কটি সক্ষম করে যা নিশ্চিত করে যে আইও কলটি শেষ হওয়ার পরে, আপনার পদ্ধতিটি যেখানেই ছেড়ে গেছে সেখান থেকে চালানো চালিয়ে যায়।
একটি বিষয় লক্ষণীয় যে এই রাষ্ট্রের মেশিনটির একটি সূক্ষ্ম ওভারহেড রয়েছে। একটি পদ্ধতি অ্যাসিক্রোনাস তৈরি করে তা দ্রুত সম্পাদন করে না এবং এটি বোঝার জন্য একটি গুরুত্বপূর্ণ কারণ এবং অনেকের মধ্যে একটি ভুল ধারণা রয়েছে।
ব্যবহার করার সময় আরেকটি বিষয় বিবেচনা করা উচিত async-awaitতা হ'ল এটি সমস্ত দিক থেকে অ্যাসিঙ্ক , অর্থাত আপনি অ্যাসিঙ্কটি দেখবেন আপনার পুরো কল স্ট্যাকটি প্রবেশ করবে, উপরে থেকে টু বোতাম om এর অর্থ হল যে আপনি যদি সিঙ্ক্রোনাস এপিআই প্রকাশ করতে চান, আপনি প্রায়শই নিজেকে নির্দিষ্ট পরিমাণের কোডটি নকল করে দেখবেন, কারণ অ্যাসিঙ্ক এবং সিঙ্কটি খুব ভালভাবে মেশে না।
যখন আমি ডাটাবেসটি জিজ্ঞাসা করতে চাই তখন কী আমি async ব্যবহার করব / কীওয়ার্ডগুলির জন্য অপেক্ষা করব (EF / NHibernate / অন্যান্য ORM এর মাধ্যমে)?
আপনি যদি অ্যাসিঙ্ক আইও কলগুলি ব্যবহারের পথে যেতে চান, তবে হ্যাঁ, async-awaitএকটি ভাল পছন্দ হবে, কারণ আরও বেশি সংখ্যক আধুনিক ডাটাবেস সরবরাহকারীরা ট্যাপ (টাস্ক অ্যাসিনক্রোনাস প্যাটার্ন) প্রয়োগকারী অ্যাসিঙ্ক পদ্ধতিটি প্রকাশ করে।
একক একশন পদ্ধতিতে ডেটাবেসকে অ্যাসিনক্রোনারিভাবে জিজ্ঞাসা করার জন্য আমি কতবার অপেক্ষার কীওয়ার্ডগুলি ব্যবহার করতে পারি?
আপনি যতটা চান, যতক্ষণ আপনি আপনার ডাটাবেস সরবরাহকারীর দ্বারা বর্ণিত বিধিগুলি অনুসরণ করেন। আপনি যে পরিমাণ অ্যাসিঙ্ক কল করতে পারেন তার সীমাবদ্ধতা নেই। যদি আপনার কাছে এমন প্রশ্ন থাকে যা একে অপরের থেকে স্বতন্ত্র এবং একই সাথে তৈরি করা যায় তবে আপনি প্রতিটিটির জন্য একটি নতুন টাস্ক স্পিন করতে পারেন এবং await Task.WhenAllউভয়ের সম্পূর্ণ হওয়ার জন্য অপেক্ষা করতে ব্যবহার করতে পারেন ।
scale out wellঅর্থ হতে পারে your server won't die under load। বা এটির কোনও ক্ষেত্রে হতে পারেonce burned ...
আমার 5 সেন্ট:
async/awaitআপনি যদি ডিও বা বাহ্যিক পরিষেবা ওয়েব সার্ভিসের মতো আইও অপারেশন করেন তবেই এবং ব্যবহার করুন ।PS 1 পয়েন্টের জন্য ব্যতিক্রমী কেস রয়েছে তবে এর জন্য আপনার async ইন্টার্নালগুলি সম্পর্কে ভাল ধারণা হওয়া দরকার।
অতিরিক্ত সুবিধা হিসাবে আপনি প্রয়োজনে সমান্তরালে কয়েকটি আইও কল করতে পারেন:
Task task1 = FooAsync(); // launch it, but don't wait for result
Task task2 = BarAsync(); // launch bar; now both foo and bar are running
await Task.WhenAll(task1, task2); // this is better in regard to exception handling
// use task1.Result, task2.Resultasyncক্রিয়াগুলি ডিবি বা কিছু নেটওয়ার্ক বাউন্ড কলগুলিতে কিছু আই-ও অপারেশন করলে ক্রিয়াকলাপগুলি সর্বোত্তমভাবে সহায়তা করে যখন আপনি সবেমাত্র অনুরোধ করেছিলেন ডিবি বা নেটওয়ার্ক বাউন্ড কল থেকে উত্তর পাওয়ার আগে অনুরোধটি প্রক্রিয়াকৃত থ্রেডটি বন্ধ হয়ে যাবে। এটি সর্বোত্তম আপনি তাদের সাথে প্রত্যাশিত ব্যবহার করুন এবং এটি আপনার আবেদনের প্রতিক্রিয়াটি সত্যই উন্নত করবে (কারণ কম এএসপি ইনপুট \ আউটপুট থ্রেডগুলি ডিবি বা অন্য কোনও অপারেশনের জন্য অপেক্ষা করার সময় বন্ধ হয়ে যাবে)। আমার সমস্ত অ্যাপ্লিকেশনগুলিতে যখনই ডিবি-তে অনেক কল আসে খুব প্রয়োজনীয় তখন আমি এগুলি সর্বদা অহায়াযোগ্য পদ্ধতিতে জড়িয়ে রেখেছি এবং awaitকীওয়ার্ড দিয়ে এটিকে ডাকি ।
যেমন আপনি জানেন, এমভিসি অ্যাসিক্রোনাস কন্ট্রোলারকে সমর্থন করে এবং আপনার এটির সুবিধা নেওয়া উচিত। যদি আপনার কন্ট্রোলার, একটি দীর্ঘ ক্রিয়াকলাপ সম্পাদন করে (এটি কোনও ডিস্ক ভিত্তিক I / o বা অন্য দূরবর্তী পরিষেবাতে নেটওয়ার্ক কল হতে পারে), যদি অনুরোধটি সিঙ্ক্রোনাস পদ্ধতিতে পরিচালনা করা হয় তবে আইআইএস থ্রেড পুরো সময় ব্যস্ত থাকে। ফলস্বরূপ, থ্রেডটি কেবল দীর্ঘ অপারেশনটি সম্পূর্ণ হওয়ার জন্য অপেক্ষা করছে। প্রথমে অনুরোধ করা অপারেশনটি প্রক্রিয়াধীন অবস্থায় অন্য অনুরোধগুলি পরিবেশন করার মাধ্যমে এটি আরও ভালভাবে ব্যবহার করা যেতে পারে। এটি আরও সমবর্তী অনুরোধগুলি পরিবেশন করতে সহায়তা করবে। আপনার ওয়েবসার্ভিস অত্যন্ত স্কেলযোগ্য এবং সহজেই C10k সমস্যার মধ্যে চলে না । ডিবি ক্যোয়ারির জন্য অ্যাসিঙ্ক / অপেক্ষার জন্য এটি ভাল ধারণা। এবং হ্যাঁ আপনি উপযুক্ত হিসাবে মনে করেন আপনি এগুলি বহুবার ব্যবহার করতে পারেন।
চমৎকার পরামর্শের জন্য এখানে একবার দেখুন ।
আমার অভিজ্ঞতা হ'ল আজ প্রচুর বিকাশকারীরা async/awaitনিয়ামকদের জন্য ডিফল্ট হিসাবে ব্যবহার করেন।
আমার পরামর্শটি হ'ল, এটি তখনই ব্যবহার করুন যখন আপনি জানেন যে এটি আপনাকে সাহায্য করবে ।
কারণটি হ'ল, স্টিফেন ক্লিয়ারি এবং অন্যান্যরা ইতিমধ্যে উল্লেখ করেছেন, এটি সমাধানের পরিবর্তে পারফরম্যান্সের সমস্যাগুলি প্রবর্তন করতে পারে এবং এটি আপনাকে কেবল একটি নির্দিষ্ট দৃশ্যে সহায়তা করবে:
এএসপি.নেট এমভিসি-তে সর্বত্র async ক্রিয়াটি ব্যবহার করা ভাল?
আপনি যেখানে async পদ্ধতি ব্যবহার করতে পারেন সেখানে এটি করা ভাল, বিশেষত যখন আপনার কর্মী প্রক্রিয়া স্তরে পারফরম্যান্সের সমস্যা থাকে যা প্রচুর ডেটা এবং গণনা কার্যক্রমের জন্য ঘটে। অন্যথায়, প্রয়োজন নেই কারণ ইউনিট পরীক্ষার জন্য ingালাই প্রয়োজন।
অপেক্ষমান পদ্ধতি সম্পর্কে: আমি যখন একটি ডেটাবেস (EF / NHibernate / অন্যান্য ORM- এর মাধ্যমে) জিজ্ঞাসা করতে চাই তখন কি async / কীওয়ার্ড কীওয়ার্ডগুলি ব্যবহার করব?
হ্যাঁ, কর্মী প্রক্রিয়া পর্যায়ে কর্মক্ষমতা সম্পর্কিত সমস্যাগুলি এড়াতে যতটা সম্ভব ডিবি অপারেশনের জন্য অ্যাসিঙ্ক ব্যবহার করা ভাল better নোট করুন যে EF বেশিরভাগ অপারেশনের জন্য অনেকগুলি async বিকল্প তৈরি করেছে, যেমন:
.ToListAsync()
.FirstOrDefaultAsync()
.SaveChangesAsync()
.FindAsync()একক ক্রিয়াকলাপ পদ্ধতিতে সংশ্লেষজনকভাবে ডাটাবেসটি জিজ্ঞাসা করার জন্য আমি কতবার অপেক্ষার কীওয়ার্ডগুলি ব্যবহার করতে পারি?
আকাশ সীমা