هل كثرة الاتصالات بخادم تجعله يتوقف ام فقط يتاخر في الاجابة

تجعله يتأخر وليست سبب بأن يتوقف بمعنى يتعطل!

كل طلب يصل إلى السيرفر تقوم thread باستقبال هذا الطلب والبدء بمعالجته، يحوي السيرفر على ما يسمى ب thread pool، اي مجموعة من threads بانتظار استقبال الطلبات ومعالجتها، لإن إنشاء thread جديدة عن وصول كل طلب امر مكلف نسبياً، لذلك وجد مفهوم thread pool هذا.

الآن، سيرفر مثل iis تقريبا يحوي على 5000 thread، تقوم thread بمعالجة الطلب والعودة لانتظار طلب جديد، بالتالي هناك حد معين لمعالجة الطلبات، خاصة اذا كانت المعالجة تتطلب وقت طويل نسبياً.

لو فرضنا ان تم استهلاك جميع threads ضمن thread pool بنفس اللحظة، وكانت كل thread مشغولة بمعالجة طويلة نسيباً، هنا تصبح استجابة السيرفر بطيئة، لانه سيقوم بتسجيل الطلب بانتظار انتهاء احدى threads لمعالجته.

لذلك هذه النقطة جوهرية جداً، وقد لا ينتبه لها البعض، الا لاحقاً عندما يصبح هناك ازدحام طلبات على التطبيق، لانه بالتأكيد الاستخدام العادي لا يشكل فرقاً كبيراً.

الآن نأتي للشق الثاني من السؤال async، بالتأكيد هي الحل، لكن وبما اننا كنا نتكلم عن threads وبأن كل thread مسؤولة عن استقبال الطلب ومعالجته حتى النهاية، اذا تطبيقنا حاليا عبارة عن single threaded application

والحل بأن يكون multi threaded application. وهكذا تصبح الية العمل

تقوم thread باستقبال الطلب وتمريره مباشرة الى thread اخرى لتقوم بمعالجته، وتعود هي فورا لتخديم المستخدمين او الطلبات الجديدة دون انتظار معالجة الطلب، وإنما بمجر انتهاء معالجة الطلب، تقوم thread  المخصصة للمعالجة باخبار ال thread الاساسية بأنها انتهت، لتقوم بدورها بالرد على المستخدم.

شاهد هذا المثال من بيئة ASP.NET Core
 

public class NewsController : Controller
{
    [HttpGet("news")]
    public async Task<IActionResult> News()
    {
        // Request now received by thread 1 for example.
        NewsViewModel model = new NewsViewModel();
        // Request is being processed by another thread
        // The main thread now go back to serve another request/user
        // When the processing is finish, the thread will be informed.
        // and continue after that
        await model.GetNews();

        // This code will not executed, until thread 2 finish its job
        return View(model);
    }
}

لاحظ كيف ان thread اخرى تقوم بمعالجة الطلب، واخبارنا عند انتهاءها.

بالتوفيق،،،

بتاريخ 27 دقائق مضت قال Music Hey:

هل تعني بالجزء العلوي ان هنالك thread واحدة فقط للمعالجة

وواحدة للاستقبال

 

لانه لو كان كذلك فالوضع اصبح اسوء بكثير بالنسبة لي

ماذا سيحصل لو استقبلت ال thread الاساسيةطلباو thread المعالجة كات تعالج واحدا حينها ؟

 

ولو لم يكن الامر كما ذكرت لك (2 thread)

فهل يكون هنالك عدة من threads المعالجة(ولو كان كذالك فماذا سيحصل لو استقبلت thread الاساسية طلبا وكان كل ال threads يعالجون)

 

ام يتم انشاء thread جديد في كل مرة ؟

بالطبع ليست thread واحدة، كما ذكرت Thread Pool ضمن سيرفر IIS يحوي تقريبا على 5000 thread، يمكنها استقبال الطلبات، ولكن بدل ان تنشغل إحدى هذه thread بالقراءة مثلا من قاعدة البيانات، فإنها تسليم العملية ل Thread اخرى، يتولى نظام التشغيل بإنشائها واسناد كل ما تحتاجه من مصادر. بينما تعود ال thread الاساسية إلى Thread Pool وتكون جاهزة لأداء مهمات اخرى، طبعا كل الكلام السابق يتم ضمن اجزاء من الثانية، اضف إلى ذلك ان نظام التشغيل مسؤول عن تنظيم عمل هذه ال threads لذلك يطلق عليه ايضا اسم Scheduler وهو ايضا المسوؤل عن ترتيب هذه ال threads لإدخال للمعالج لتنفيذها، لذلك يسمى ايضا Dispatcher او الموزع.

 كل ما انت بحاجة معرفته، انه من الافضل توزيع المهام على threads بحيث يمكن تسمية التطبيق عندها Multi-Threading Application

اذا عملت في برمجة تطبيقات الويندوز او سطح المكتب، وكان لديك عملية طويلة نسبيا مثل القراءة من قاعدة البيانات، ستجد ان الواجهة ستتجمد لحين انتهاء القراءة من قاعدة البيانات، والسبب هو ان التطبيق افتراضيا يملك thread واحد، هي المسوؤلة عن ادارة او تنفيذ التطبيق على CPU، بالتالي عندما تنشغل هذه  thread بالقراءة من قاعدة البيانات، لا يعود بإمكانها إدارة الواجهة، لذلك تتجمد الواجهة.

والحل بالطبع هو استخدام thread اخرى للقراءة من قاعدة البيانات، وإبقاء ال thread الاساسية مسؤولة عن عرض واجهات المستخدم فقط. بهذا الشكل يصبح التطبيق متجاوب Responsive

ملاحظة: عندما تتجمد الواجهة كما ذكرنا، ليست المشكلة في المعالج او نظام التشغيل، لانك لو شاهدت Task Manager ستجد ان المعالج مستخدم بأقل من 10%، اذا باستطاعته تنفيذ العديد من threads الأخرى بنفس اللحظة، وهي مهتمك في انشاء هذه ال threads، ومهمة نظام التشغيل والمعالج في ترتيبها وتنفيذها.

بتاريخ 36 دقائق مضت قال Music Hey:

قد سمعت بان كل طلب يتم استقباله من السيرفر 

يستهلك من الذاكرة او resources ما فهمته هو انه يستهلك من خواص السيرفر(حاسوب)

 

وانه عندما يتم استقبال طلب و تلك الخواص لا تكون موجودة على السيرفر

حينها السيرفر يتعطل

هل هذا صحيح ؟

 في علوم الحاسوب دائما يستخدم مصطلح Resources للدالة على استخدام الذاكرة واستخدام المعالج، بمعنى كل Thread  لدينا يقوم نظام التشغيل بحجز مكان لها في الذاكرة وترتيب الية دخولها إلى CPU لتنفيذها، وهذا امر طبيعي ولا يؤدي إلى عطل في السيرفر، باستثناء كان الكود الذي يتم على تنفيذه هو من يستهلك مصادر الجهاز الاخرى، مثل كتابة كمية كبيرة من البيانات على الهارد يسك، هذا يؤدي إلى بطىء بعمل النظام بشكل عام. لكن في النهاية كل ما يحدث ضمن السيرفر او اي كمبيوتر، هو مرور منظم للتيار الكهربائي وخاصة ضمن المعالج.

بتاريخ 40 دقائق مضت قال Music Hey:

وايضا سمعت بان ال cpu لها علاقة بابطاء سرعة السيرفر

ولكن ما اعرفه عن ال cpu انها وحدة مخصصة للرسم على الحاسوب لا غير

لذا هل هذا صحيح ايضا

انت تقصد GPU وهو معالج خاص بالرسوميات، لأنها تستهلك من مصادر النظام، لذلك تم فصل عمل الرسوميات بمعالج مخصص لها. وإبقاء CPU لمعالجات العمليات الأخرى.

في أنظمة مثل Linux server قد لا يكون هناك واجهة رسومية اطلاقا حتى لا يتم استهلاك مصادر الحاسوب بسبب رسوميات لا فائدة منها على السيرفر، لان المستخدم لا يتفاعل مباشرة مع السيرفر، لذلك يتم ادارة السيرفر عن طريق Shell  او Command Prompts

ايضا ضمن ويندوز سيرفر ستجد ان الواجهات ليست بالكفاءة الموجودة على الويندز العادي، لنفس السبب أيضا.

اخيراً: كل هذا التعقيد لا يفيد كثير اثناء تطويرنا للتطبيقات، لان المسؤولية الكبرى تقع على عائق إدارة السيرفر. كل ما نحتاجة هو فهم عام لألية العمل، بالإضافة لإتباع التعمليات الخاصة بكل تقنية. فدائما يوجد حل لكل مشكلة، فحتى الشركات الكبرى مثل فيسبوك، لايمكن ان يقوم سيرفر واحد بتخديم كل هؤلاء المستخدمين، وإنما يتم توزيع الفيسبوك على مجوعة من السيرفرز.

بالتوفيق،،،

تقوم thread باستقبال الطلب وتمريره مباشرة الى thread اخرى لتقوم بمعالجته، وتعود هي فورا لتخديم المستخدمين او الطلبات الجديدة دون انتظار معالجة الطلب، وإنما بمجر انتهاء معالجة الطلب، تقوم thread  المخصصة للمعالجة باخبار ال thread الاساسية بأنها انتهت، لتقوم بدورها بالرد على المستخدم.

شكرا لك صديقي

لكن هل لي ان اسئل سؤال واحد بعد

هل تعني بالجزء العلوي ان هنالك thread واحدة فقط للمعالجة

وواحدة للاستقبال

لانه لو كان كذلك فالوضع اصبح اسوء بكثير بالنسبة لي

ماذا سيحصل لو استقبلت ال thread الاساسيةطلباو thread المعالجة كات تعالج واحدا حينها ؟

ولو لم يكن الامر كما ذكرت لك (2 thread)

فهل يكون هنالك عدة من threads المعالجة(ولو كان كذالك فماذا سيحصل لو استقبلت thread الاساسية طلبا وكان كل ال threads يعالجون)

ام يتم انشاء thread جديد في كل مرة ؟

وايضا شيء اخر

لقد سمعت بان كل طلب يتم استقباله من السيرفر 

يستهلك من الذاكرة او resources ما فهمته هو انه يستهلك من خواص السيرفر(حاسوب)

وانه عندما يتم استقبال طلب و تلك الخواص لا تكون موجودة على السيرفر

حينها السيرفر يتعطل

هل هذا صحيح ؟

وايضا سمعت بان ال cpu لها علاقة بابطاء سرعة السيرفر

ولكن ما اعرفه عن ال cpu انها وحدة مخصصة للرسم على الحاسوب لا غير

لذا هل هذا صحيح ايضا

اجابتك كانت رائعة

اقدر لك مجهودك 

شكرا مجددا صديقي