কোনও ওয়েবএপিআই ক্লায়েন্টে কল প্রতি নতুন এইচটিপিপিলেট তৈরির ওভারহেড কী?


162

কোন HttpClientওয়েবএপিআই ক্লায়েন্টের আজীবন হওয়া উচিত ? একাধিক কলের জন্য
একটি উদাহরণ থাকা কি ভাল HttpClient?

HttpClientপ্রতি অনুরোধ তৈরি এবং নিষ্পত্তি করার ওভারহেড কী , যেমন নীচের উদাহরণের (থেকে নেওয়া) http://www.asp.net/web-api/overview/web-api-clients/calling-a-web-api-from- এ-নেট-ক্লায়েন্ট ):

using (var client = new HttpClient())
{
    client.BaseAddress = new Uri("http://localhost:9000/");
    client.DefaultRequestHeaders.Accept.Clear();
    client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));

    // New code:
    HttpResponseMessage response = await client.GetAsync("api/products/1");
    if (response.IsSuccessStatusCode)
    {
        Product product = await response.Content.ReadAsAsync<Product>();
        Console.WriteLine("{0}\t${1}\t{2}", product.Name, product.Price, product.Category);
    }
}

আমি নিশ্চিত নই, আপনি Stopwatchক্লাসটি এটির মানদণ্ডে ব্যবহার করতে পারেন । আমার অনুমানটি হ'ল এককটি হওয়া আরও বেশি অর্থবোধ করে HttpClient, ধরে নিবেন যে এই সমস্ত দৃষ্টান্ত একই প্রসঙ্গে ব্যবহৃত হয়েছে।
ম্যাথু

উত্তর:


215

HttpClientএকাধিক কলের জন্য পুনরায় ব্যবহার করার জন্য ডিজাইন করা হয়েছে । এমনকি একাধিক থ্রেড জুড়ে। HttpClientHandlerপ্রমাণপত্রাদি এবং কুকিজ যে পুনরায় ব্যবহার কল জুড়ে হতে উদ্দেশ্যে করা হয় হয়েছে। একটি নতুন HttpClientদৃষ্টান্ত থাকার জন্য of সমস্ত জিনিস পুনরায় সেটআপ করা দরকার। এছাড়াওDefaultRequestHeaders সম্পত্তিটিতে এমন বৈশিষ্ট্য রয়েছে যা একাধিক কল করার উদ্দেশ্যে for প্রতিটি অনুরোধে এই মানগুলি পুনরায় সেট করে পয়েন্টটি হারাতে পারে।

এর আর একটি বড় সুবিধা HttpClientহ'ল HttpMessageHandlersক্রস কাটিংয়ের উদ্বেগগুলি প্রয়োগ করার জন্য অনুরোধ / প্রতিক্রিয়া পাইপলাইনটিতে যুক্ত করার ক্ষমতা । এগুলি লগিং, অডিটিং, থ্রোটলিং, পুনর্নির্দেশ হ্যান্ডলিং, অফলাইন হ্যান্ডলিং, মেট্রিক্স ক্যাপচারের জন্য হতে পারে। সব ধরণের বিভিন্ন জিনিস। যদি প্রতিটি অনুরোধে একটি নতুন এইচটিপিপিএলিয়েন্ট তৈরি করা হয়, তবে এই সমস্ত বার্তা হ্যান্ডলারের প্রতিটি অনুরোধে সেটআপ করা দরকার এবং কোনওভাবে এই হ্যান্ডলারের অনুরোধগুলির মধ্যে ভাগ করা কোনও অ্যাপ্লিকেশন স্তরের অবস্থাও সরবরাহ করা প্রয়োজন।

আপনি যত বেশি বৈশিষ্ট্যগুলি ব্যবহার HttpClientকরবেন ততই আপনি দেখতে পাবেন যে কোনও বিদ্যমান উদাহরণ পুনরায় ব্যবহার করা অর্থবোধ করে।

যাইহোক, আমার মতে সবচেয়ে বড় সমস্যাটি হ'ল যখন কোনও HttpClientশ্রেণি নিষ্পত্তি হয়, তখন তা নিষ্পত্তি করে HttpClientHandler, যা তারপরে TCP/IPপরিচালিত সংযোগের পুলটিতে জোর করে সংযোগটি বন্ধ করে দেয় ServicePointManager। এর অর্থ হ'ল একটি নতুন সাথে প্রতিটি অনুরোধের HttpClientজন্য একটি নতুন TCP/IPসংযোগ পুনঃপ্রতিষ্ঠা করা দরকার ।

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

ইন্টারনেটে যাওয়ার অনুরোধগুলিতে, আমি একটি আলাদা গল্প দেখেছি। প্রতিবার অনুরোধটি পুনরায় খোলার কারণে 40% পারফরম্যান্স হিট করেছি।

আমি সন্দেহ করি যে কোনও HTTPSসংযোগের হিট আরও খারাপ হবে।

আমার পরামর্শ হ'ল আপনি সংযুক্ত প্রতিটি পৃথক এপিআইয়ের জন্য আপনার আবেদনের আজীবন এইচটিপিপ্লিনেন্টের একটি উদাহরণ রাখুন


5
which then forcibly closes the TCP/IP connection in the pool of connections that is managed by ServicePointManagerআপনি এই বিবৃতি সম্পর্কে কতটা নিশ্চিত? এটা বিশ্বাস করা কঠিন। HttpClientআমার কাছে কাজের একক হিসাবে দেখায় যা প্রায়শই তাত্ক্ষণিক বলে মনে হয়।
usr ডিরেক্টরির

2
@ ভ্যাকেলম্যান হ্যাঁ আপনি যদি এখনও কোনও নতুন এইচটিপিপিপ্লায়েন্টহ্যান্ডলারের সাহায্যে এটি তৈরি করে থাকেন তবে আপনি এখনও HTTPClient এর উদাহরণ পুনরায় ব্যবহার করতে পারেন। এছাড়াও মনে রাখবেন যে এইচটিটিপিপ্লিনেন্টের জন্য একটি বিশেষ নির্মাতা রয়েছে যা আপনাকে কোনও এইচটিপিপিলেয়েন্টহ্যান্ডলার পুনরায় ব্যবহার করতে এবং সংযোগটি না মেরে এইচটিটিপিপ্লিনেন্টকে নিষ্পত্তি করতে দেয়।
ড্যারেল মিলার

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

2
@ ড্যারেল মিলার তাই মনে হচ্ছে এই সংযোগটি এইচটিপিপ্লেইন্টহ্যান্ডলারের সাথে আবদ্ধ। আমি জানি যে স্কেল করার জন্য আমি সংযোগটি ধ্বংস করতে চাই না তাই আমার একটি HTTPClientHandler চারপাশে রাখা উচিত এবং সেই থেকে আমার এইচটিটিপিপ্লিনেন্টের সমস্ত উদাহরণ তৈরি করা বা একটি স্ট্যাটিক এইচটিটিপি ক্লিনেন্ট উদাহরণ তৈরি করা দরকার। তবে, যদি কুকি কনটেনারটি এইচটিটিপিসিলেট হ্যান্ডলারের সাথে আবদ্ধ থাকে, এবং আমার কুকিগুলির অনুরোধ অনুসারে পৃথক হওয়া দরকার, আপনি কী প্রস্তাব দিচ্ছেন? আমি প্রতিটি অনুরোধের জন্য কুকি কনটেইনারটি সংশোধন করে একটি স্ট্যাটিক এইচটিটিপিসিপ্লায়েন্টহ্যান্ডলারটিতে থ্রেড সিঙ্ক্রোনাইজেশন এড়াতে চাই।
ডেভ ব্ল্যাক

2
@ সানা ৯৯১ পরিষেবা সংগ্রহের ক্ষেত্রে এটি সিঙ্গলটন হিসাবে নিবন্ধন করা এবং সেভাবে এটি অ্যাক্সেস করা ভাল।
ড্যারেল মিলার

69

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

আমার একটি সাম্প্রতিক প্রকল্পটি ছিল কিছু নতুন সিস্টেমের জন্য ব্ল্যাক ফ্রাইডে / হলিডে ট্র্যাফিকের জন্য খুব বড় এবং সুপরিচিত অনলাইন কম্পিউটার খুচরা বিক্রেতার স্কেল সহায়তা করা। আমরা HTTPClient ব্যবহারের চারপাশে কিছু কার্য সম্পাদন সংক্রান্ত সমস্যার মধ্যে পড়েছি। যেহেতু এটি প্রয়োগ করে IDisposable, ডেভসগুলি সাধারণত একটি কাজ তৈরি করে এবং কোনও using()বিবৃতিতে রাখার মাধ্যমে আপনি সাধারণত যা করবেন তা করেছেন। একবার আমরা লোড টেস্টিং শুরু করে অ্যাপটি সার্ভারকে তার হাঁটুতে এনেছিল - হ্যাঁ, সার্ভারটি কেবল অ্যাপ্লিকেশন নয়। কারণটি হ'ল এইচটিপিপি্লিয়েন্টের প্রতিটি উদাহরণ সার্ভারে একটি পোর্ট খোলে। জিসির অ-বিবাদ-চূড়ান্তকরণের কারণে এবং আপনি একাধিক ওএসআই স্তর জুড়ে থাকা কম্পিউটার সংস্থাগুলির সাথে কাজ করছেন এই কারণে , নেটওয়ার্ক বন্দরগুলি বন্ধ করতে কিছুটা সময় নিতে পারে। আসলে উইন্ডোজ ওএস নিজেইএকটি পোর্ট বন্ধ করতে 20 সেকেন্ড পর্যন্ত সময় নিতে পারে (মাইক্রোসফ্ট প্রতি)। সেগুলি বন্ধ হওয়ার চেয়ে আমরা দ্রুত পোর্টগুলি খুলছিলাম - সার্ভার পোর্ট ক্লান্তি যা সিপিইউকে 100% করে দিয়েছে। আমার ফিক্সটি ছিল এইচটিপিপ্লেইন্টটিকে স্থির উদাহরণে পরিবর্তন করা যা সমস্যার সমাধান করেছে। হ্যাঁ, এটি একটি নিষ্পত্তিযোগ্য সংস্থান, তবে কোনও ওভারহেড পারফরম্যান্সের পার্থক্যের দ্বারা বিস্তৃত হয়। আপনার অ্যাপটি কীভাবে আচরণ করে তা দেখতে আমি আপনাকে কিছু লোড টেস্টিং করতে উত্সাহিত করি।

আপনি ডকুমেন্টেশন এবং উদাহরণের জন্য ওয়েবএপিআই গাইডেন্স পৃষ্ঠাটি https://www.asp.net/web-api/overview/advanced/calling-a-web-api-from-a-net-client এ দেখতে পারেন

এই কল-আউটটিতে বিশেষ মনোযোগ দিন:

HTTPClient একবার ইনস্ট্যান্ট করা এবং একটি অ্যাপ্লিকেশন সারা জীবন পুনরায় ব্যবহার করার উদ্দেশ্যে করা হয়। বিশেষত সার্ভার অ্যাপ্লিকেশনগুলিতে, প্রতিটি অনুরোধের জন্য একটি নতুন এইচটিপিপিপ্লায়েন্ট তৈরি করা ভারী বোঝার অধীনে উপলব্ধ সকেটের সংখ্যা নিঃশেষ করে দেবে। এর ফলে সকেটএক্সেপশন ত্রুটি হবে।

যদি আপনি দেখতে পান যে আপনাকে HttpClientবিভিন্ন শিরোনাম, বেস ঠিকানা ইত্যাদি দিয়ে একটি স্ট্যাটিক ব্যবহার করতে হবে তবে আপনাকে HttpRequestMessageনিজে যা করতে হবে তা হ'ল ম্যানুয়ালি তৈরি করা এবং মানগুলিতে সেট করা HttpRequestMessage। তারপরে, ব্যবহার করুনHttpClient:SendAsync(HttpRequestMessage requestMessage, ...)

নেট কোরের জন্য আপডেট করুন : উদাহরণগুলি IHttpClientFactoryতৈরি করতে আপনার নির্ভরশীল ইনজেকশন ব্যবহার করা উচিত HttpClient। এটি আপনার জন্য আজীবন পরিচালনা করবে এবং আপনাকে এটিকে সুস্পষ্টভাবে নিষ্পত্তি করার দরকার নেই। দেখুন ASP.NET কোর মধ্যে IHttpClientFactory ব্যবহার মেক HTTP অনুরোধ


1
যারা স্ট্রেস টেস্টিং করবেন তাদের জন্য এই পোস্টে দরকারী অন্তর্দৃষ্টি রয়েছে ..!
সানা .91

9

অন্যান্য উত্তর হিসাবে রাষ্ট্র HttpClientপুনরায় ব্যবহারের জন্য বোঝানো হয়। তবে, HttpClientএকাধিক-থ্রেড অ্যাপ্লিকেশন জুড়ে একক দৃষ্টান্ত পুনরুদ্ধারের অর্থ আপনি এর রাষ্ট্রীয় বৈশিষ্ট্যগুলির মানগুলি পরিবর্তন করতে পারবেন না, BaseAddressএবং DefaultRequestHeaders(যাতে আপনি কেবল সেগুলি ব্যবহার করতে পারেন যদি তারা আপনার অ্যাপ্লিকেশন জুড়ে স্থির থাকে)।

এই সীমাবদ্ধতা প্রায় পাবার জন্য একটা পদক্ষেপ মোড়ানো হয় HttpClientএকটি বর্গ যে সব সদৃশ সঙ্গে HttpClient(পদ্ধতি আপনি প্রয়োজন GetAsync, PostAsyncইত্যাদি) এবং তাদের প্রতিনিধিদের একটি Singleton করতে HttpClient। তবে এটি বেশ ক্লান্তিকর (আপনার সম্প্রসারণের পদ্ধতিগুলিও মুড়ে ফেলতে হবে) এবং ভাগ্যক্রমে আরও একটি উপায় রয়েছে - নতুন HttpClientউদাহরণ তৈরি করা চালিয়ে যান , তবে অন্তর্নিহিতটিকে পুনরায় ব্যবহার করুন HttpClientHandler। কেবলমাত্র আপনি হ্যান্ডলারটি নিষ্পত্তি করবেন না তা নিশ্চিত করুন:

HttpClientHandler _sharedHandler = new HttpClientHandler(); //never dispose this
HttpClient GetClient(string token)
{
    //client code can dispose these HttpClient instances
    return new HttpClient(_sharedHandler, disposeHandler: false)         
    {
       DefaultRequestHeaders = 
       {
            Authorization = new AuthenticationHeaderValue("Bearer", token) 
       } 
    };
}

2
যাওয়ার আরও ভাল উপায় হ'ল একটি HTTPClient উদাহরণ রাখা এবং তারপরে আপনার নিজস্ব স্থানীয় HttpRequestMessage উদাহরণ তৈরি করুন এবং তারপরে HTTPClient এ .SendAsync () পদ্ধতিটি ব্যবহার করুন। এইভাবে এটি এখনও থ্রেড-নিরাপদ থাকবে। প্রতিটি HTTPRequestMessage এর নিজস্ব প্রমাণীকরণ / ইউআরএল মান থাকবে।
টিম পি।

@TimP। কেন এটা ভাল? SendAsyncঅনেক কম যেমন ডেডিকেটেড পদ্ধতির চেয়ে সুবিধাজনক PutAsync, PostAsJsonAsyncইত্যাদি
ওহদ স্নাইডার

2
SendAsync আপনাকে ইউআরএল এবং অন্যান্য বৈশিষ্ট্য যেমন শিরোলেখ পরিবর্তন করতে দেয় এবং এখনও থ্রেড-নিরাপদ থাকুক।
টিম পি।

2
হ্যাঁ, হ্যান্ডলারটি মূল। যতক্ষণ না এটি এইচটিপিপিপ্লায়েন্টের মধ্যে ভাগ করা যায় আপনি ভাল আছেন। আমি আপনার আগের মন্তব্য ভুল লিখেছি।
ডেভ ব্ল্যাক

1
যদি আমরা কোনও ভাগ করা হ্যান্ডলারটি রাখি তবে কী আমাদের এখনও বাসি ডিএনএস ইস্যুটির যত্ন নেওয়া দরকার?
শান্তি

5

উচ্চ-ভলিউম ওয়েবসাইটগুলির সাথে সম্পর্কিত তবে সরাসরি এইচটিপিপ্লিয়েন্টে নয়। আমাদের সমস্ত পরিষেবাতে নীচের কোডের স্নিপেট রয়েছে।

        // number of milliseconds after which an active System.Net.ServicePoint connection is closed.
        const int DefaultConnectionLeaseTimeout = 60000;

        ServicePoint sp =
                ServicePointManager.FindServicePoint(new Uri("http://<yourServiceUrlHere>"));
        sp.ConnectionLeaseTimeout = DefaultConnectionLeaseTimeout;

Https://msdn.microsoft.com/query/dev14.query?appId=Dev14IDEF1&l=EN-US&k=k(System.Net.ServicePoint.ConnicationLeaseTimeout) ;k( টার্গেটফ্রেমকর্ম.মনাইটফ্রেমওয়ার্ক, ভার্সন ৯৩.ডিভি ৪.২.২); ট (DevLang-csharp) & য় সত্য =

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

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

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

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


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

অসমত নয়। সবকিছুই একটি ট্রেড অফ। আমাদের জন্য রি-রুটেড সিডিএন বা ডিএনএস অনুসরণ করা হ'ল ব্যাংকের অর্থ বনাম হারানো উপার্জন।
কোনও রিফান্ড নেই কোনও রিটার্নস নেই

1

আপনি এই ব্লগ পোস্টটি সাইমন টিমস দ্বারা উল্লেখ করতে চাইতে পারেন: https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/

তবে HttpClientআলাদা। যদিও এটি IDisposableইন্টারফেস প্রয়োগ করে এটি আসলে একটি ভাগ করা বস্তু। এর অর্থ হ'ল কভারগুলির নীচে এটি পুনরায় হয়) এবং থ্রেড নিরাপদ। HttpClientপ্রতিটি মৃত্যুদণ্ড কার্যকর করার জন্য একটি নতুন উদাহরণ তৈরি করার পরিবর্তে HttpClientআপনার প্রয়োগের পুরো জীবদ্দশায় একক উদাহরণ ভাগ করা উচিত । আসুন কেন তাকান।


1

একটি বিষয় উল্লেখ করতে হবে, যে "ব্লগ নোট" ব্যবহার করে না "কোনওটিই হ'ল এটি কেবল বেসএড্রেস এবং ডিফল্টহাইডার নয় যেটি আপনাকে বিবেচনা করা উচিত। একবার আপনি এইচটিটিপিপ্লায়েন্ট স্থিতিশীল করে তোলেন, এমন অভ্যন্তরীণ রাজ্য রয়েছে যা অনুরোধগুলি জুড়ে নেওয়া হবে। একটি উদাহরণ: আপনি ফেডআউথ টোকেন পাওয়ার জন্য HTTPClient এর সাথে একটি তৃতীয় পক্ষের সাথে অনুমোদন দিচ্ছেন (কেন OAuth / OWIN / ইত্যাদি ব্যবহার করবেন না তা উপেক্ষা করুন), প্রতিক্রিয়া বার্তায় ফেডআউথের জন্য সেট-কুকি শিরোনাম রয়েছে, এটি আপনার এইচটিটিপি ক্লিনেন্ট স্থিতিতে যুক্ত করা হয়েছে। আপনার এপিআইতে লগইন করার জন্য পরবর্তী ব্যবহারকারী সর্বশেষ ব্যক্তির ফেডআউথ কুকি প্রেরণ করবেন যতক্ষণ না আপনি প্রতিটি অনুরোধে এই কুকিগুলি পরিচালনা করছেন।


0

প্রথম ইস্যু হিসাবে, যদিও এই শ্রেণিটি নিষ্পত্তিযোগ্য, বয়ানটির সাথে এটি ব্যবহার করা usingসর্বোত্তম পছন্দ নয় কারণ আপনি যখন HttpClientঅবজেক্টটি নিষ্পত্তি করেন তখনও অন্তর্নিহিত সকেট অবিলম্বে প্রকাশ হয় না এবং এটি 'সকেট ক্লান্তি' নামে একটি গুরুতর সমস্যার কারণ হতে পারে।

HttpClientআপনি যখন এটি সিঙ্গলটন বা স্ট্যাটিক অবজেক্ট হিসাবে ব্যবহার করেন তখন আপনার কাছে দ্বিতীয় সমস্যা রয়েছে । এই ক্ষেত্রে, একটি সিঙ্গলটন বা স্ট্যাটিক পরিবর্তনগুলি HttpClientসম্মান করে না DNS

মধ্যে .net কোর আপনার সাথে একই কাজ করতে পারেন HttpClientFactory ভালো কিছু:

public interface IBuyService
{
    Task<Buy> GetBuyItems();
}
public class BuyService: IBuyService
{
    private readonly HttpClient _httpClient;

    public BuyService(HttpClient httpClient)
    {
        _httpClient = httpClient;
    }

    public async Task<Buy> GetBuyItems()
    {
        var uri = "Uri";

        var responseString = await _httpClient.GetStringAsync(uri);

        var buy = JsonConvert.DeserializeObject<Buy>(responseString);
        return buy;
    }
}

ConfigureServices

services.AddHttpClient<IBuyService, BuyService>(client =>
{
     client.BaseAddress = new Uri(Configuration["BaseUrl"]);
});

এখানে ডকুমেন্টেশন এবং উদাহরণ

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.