اگر از کاربران سرویس‌های آنلاین باشید، قطعاً انتظار دارید در کسری از ثانیه به اپلیکیشن و یا وب‌سایت محبوب خود متصل شوید و استفاده از آن را آغاز کنید. اما همان‌طور که می‌دانید به هیچ عنوان در این مسیر تنها نیستید و هزاران کاربر دیگر هم سعی دارند هم‌زمان با شما به سرویس مورد نظر خود متصل شوند. این «درخواست‌های هم‌زمان» (Concurrent Requests) در صورت مدیریت صحیح، تجربه‌ای روان و بی‌وقفه برای مخاطبان رقم می‌زنند و در غیر این صورت، به یکی از گلوگاه‌های اصلی سرویس‌‌ها تبدیل می‌شوند.

در این مطلب، قصد داریم نگاهی به سازوکار درخواست‌های هم‌زمان بیندازیم، محدودیت‌های آن را بررسی کنیم و با معرفی برترین روش‌ها و ابزارهای مدیریت Concurrent Requests، راه بهینه‌سازی و پایداری سرویس‌های شما را هموار کنیم.

نگاهی به چرخه درخواست (Request Lifecycle) در فضای وب

پیش از آن که به مفهوم درخواست‌های هم‌زمان (Concurrent Requests) بپردازیم، ابتدا باید با چرخه درخواست در فضای وب آشنا شویم. در معماری درخواست وب، تعامل میان کاربر و سیستم از طریق پروتکل HTTP انجام می‌شود. هنگامی که کاربر عملیاتی مانند باز کردن یک صفحه یا ارسال فرم را انجام می‌دهد، یک HTTP Request ایجاد و به سرور ارسال می‌شود. این درخواست توسط وب‌سرورها (مانند Nginx، Apache و…) دریافت می‌شود و منابع و سرویس‌های پردازشی مناسب به آنها اختصاص پیدا می‌کند.

در مرحله بعد، وب‌سرور وظیفه دارد درخواست را به لایه اپلیکیشن منتقل کند، جایی که تصمیم‌گیری درباره نحوه پردازش داده‌ها انجام می‌شود و سپس برای انجام عملیات‌های لازم مانند پرس‌وجو از پایگاه‌داده، نتیجه آماده در قالب HTTP Response  به وب‌سرور بازگردانده می‌شود. در پایان، پاسخ از طریق اپلیکیشن موبایل، مرورگر و… به کاربر نمایش داده می‌شود. این چرخه سریع و به‌ظاهر ساده، قلب عملکرد تمامی سرویس‌های آنلاین است و تضمین می‌کند که تعاملات کاربران با سیستم‌های دیجیتال به شکل قابل‌اعتماد، امن و کارآمد انجام شود.

درخواست همزمان (Concurrent Requests) چیست؟

در بخش قبل، به این نکته اشاره کردیم که چرخه درخواست وب با ارسال درخواست از جانب کاربر به وب‌سرور آغاز می‌شود. حال اگر وب‌سرور هم‌زمان با بیش از یک درخواست از جانب کاربران روبه‌رو ‌شود، شرایط «درخواست هم‌زمان» یا به‌اصطلاح «Concurrent Requests» رخ می‌دهد. این وضعیت در سرویس‌های آنلاین پرمخاطب بسیار رایج است، زیرا کاربران متعددی تلاش می‌کنند درآن‌واحد به یک وب‌سایت یا سرویس دسترسی پیدا کنند.

حال که درخواست‌ها توسط وب‌سرور دریافت شده‌اند، نوبت به پردازش درخواست‌ها می‌رسد. در مواجهه با این وضعیت، دو رویکرد کلی وجود دارد که آنها را تحت عنوان درخواست‌های ترتیبی و درخواست‌های هم‌زمان می‌شناسیم.

در حالت ترتیبی، هر درخواست می‌بایست در صف انتظار منتظر بماند تا به درخواست قبلی رسیدگی شود. این رویکرد برای سیستم‌های محدود و کوچک‌مقیاس تا حد زیادی کاربردی است؛ اما در سیستم‌هایی با مقیاس بزرگ‌‌تر منجر به تشکیل صف‌های بلند انتظار می‌شود و عملکرد سیستم را با چالش‌های جدی رو‌به‌رو می‌کند.

در رویکرد هم‌زمان، همانگونه که از نام آن پیداست، چندین درخواست مختلف به‌صورت هم‌زمان پردازش می‌شوند که باعث می‌شود بهره‌وری به‌طور قابل‌توجهی افزایش پیدا کند. در روش هم‌زمان، معماری Asynchronous از اهمیت بالایی برخوردار است و عملیات ورود و خروج را بدون توقف پردازش می‌کند. این مدل با استفاده از فراخوانی‌های غیر مسدود کننده (non-blocking calls)، سرور را از انتظار اجباری برای اتمام یک عملیات رها می‌کند. علاوه بر این، Asynchronous اجازه می‌دهد تا یک پورت واحد بتواند هم‌زمان چندین درخواست را دریافت و مدیریت کند، چرا که هر درخواست به‌صورت مستقل و بدون مسدودکردن thread اصلی سرویس‌دهی می‌شود.

تفاوت بین «درخواست هم‌زمان» و «درخواست موازی» چیست؟ 

در طراحی و پیاده‌سازی سامانه‌های نرم‌افزاری مقیاس‌پذیر، درک صحیح از تفاوت میان درخواست هم‌زمان (Concurrent) و درخواست موازی (Parallel) اهمیتی بنیادین دارد. این دو اصطلاح اگرچه گاه به‌صورت مترادف استفاده می‌شوند، اما در سطح معماری سیستم، مدل محاسباتی و الگوی استفاده از منابع پردازشی تفاوت‌های اساسی با یکدیگر دارند. شناخت این فاصله مفهومی به مهندسان نرم‌افزار کمک می‌کند تا بر اساس ماهیت بار پردازشی و نیازمندی‌های سامانه، معماری مناسب را انتخاب کنند.

• درخواست‌های هم‌زمان (Concurrent Requests)

درخواست‌های هم‌زمان به توانایی سیستم برای مدیریت چندین وظیفه در یک بازه زمانی واحد اشاره دارد، بدون آنکه لزوماً تمام این وظایف به شکل فیزیکی و در یک لحظه مشخص روی پردازنده اجرا شوند. در این رویکرد، تمرکز بر مدیریت وظایف و جلوگیری از انسداد جریان پردازش است. معماری مبتنی بر async I/O و مدل event-loop در پلتفرم‌هایی نظیر Node.js نمونه‌های شناخته‌شده‌ای از این نوع الگوها به‌حساب می‌آیند. 

• درخواست‌های موازی (Parallel Requests)

در مقابل، درخواست‌های موازی به اجرای واقعی و هم‌زمان چندین وظیفه روی منابع پردازشی جداگانه مانند هسته‌های متعدد CPU اشاره دارد. این روش به طور ویژه برای پردازش‌های سنگین و محاسباتی مناسب است که نیازمند تقسیم بار پردازشی و اجرای هم‌زمان رشته‌های مستقل یا فرایندهای متعدد هستند. نمونه‌های بارز این دسته، پیاده‌سازی‌های چندپردازشی و چندرشته‌ای است که در زبان‌هایی همچون Java و Python قابل‌مشاهده هستند.

در انتخاب میان پردازش موازی و هم‌زمان، این ماهیت پروژه‌ها است که بهترین گزینه را تعیین می‌کند. برای مواردی مانند مدیریت درخواست‌های شبکه، خواندن و نوشتن فایل‌ها و همچنین تعامل با پایگاه داده، معماری هم‌زمان معمولاً بازده بسیار بالاتری دارد. در طرف مقابل، برای فعالیت‌های CPU محور مانند پردازش تصویر، رمزنگاری و یا تحلیل داده‌های حجیم، بهره‌گیری از پردازش موازی می‌تواند انتخابی ایده‌آل باشد؛ چرا که امکان بهره‌برداری بهینه از چندین هسته پردازشی را فراهم می‌کند و توان پردازشی را به طور چشمگیری بهبود می‌بخشد.

محدودیت‌های درخواست‌های هم‌زمان (Concurrent Requests) در سامانه‌های وب 

 هرچند که رویکرد پردازش درخواست‌ها به‌صورت هم‌زمان در فرایند مدیریت concurrent requests، امروزه از محبوبیت بالایی برخوردار است؛ اما همچنان محدودیت‌ها و چالش‌های مختص به خود را دارد که آشنایی با آن‌ها برای مهندسان و توسعه‌دهندگان ضروری است.

1. محدودیت منابع سرور

پردازش هم‌زمان به معنای اجرای هم‌زمان درخواست‌ها بر روی CPU نیست؛ بلکه به مدیریت چند درخواست در یک بازه زمانی خاص اشاره دارد. در این رویکرد، هر درخواست نیازمند منابعی مانند حافظه، کانکشن‌های باز و Thread های مدیریتی است. وقتی تعداد درخواست‌ها از ظرفیت سرور فراتر رود، احتمال مواجهه با Memory Exhaustion یا Connection Saturation افزایش می‌یابد و عملکرد سیستم دچار افت می‌شود.

2. پیچیدگی مدیریت خطا و زمان‌بندی

در معماری هم‌زمان، مدیریت خطا و ترتیب اجرای درخواست‌ها پیچیده‌تر از مدل ترتیبی است. وقتی چند درخواست به‌صورت هم‌زمان در جریان هستند، هرگونه خطای غیرمنتظره ممکن است بر سایر درخواست‌ها تأثیر بگذارد. همچنین، زمان‌بندی درخواست‌ها و اطمینان از اینکه هیچ درخواستی برای مدت طولانی در صف انتظار نماند، نیازمند طراحی دقیق الگوریتم‌های queueing و timeout است.

3. محدودیت در پردازش CPU-bound

پردازش هم‌زمان برای درخواست‌های I/O-heavy بسیار مؤثر است، اما وقتی بار کاری CPU-bound باشد، این رویکرد نمی‌تواند چندان کاربردی ظاهر شود. در چنین شرایطی، نیاز به استفاده از روش پردازش موازی و بهره‌گیری از CPU های چندهسته‌ای احساس می‌شود.

بیشتر بخوانید: تفاوت‌ها و کاربردهای API و SDK چیست؟

درصورتی‌که توسعه‌دهندگان و مهندسان نرم‌افزار بتوانند این محدودیت‌ها را در فرایند انتخاب الگوریتم‌ها و تخصیص منابع در نظر بگیرند، می‌توانند سامانه‌ای پایدار و مقیاس‌پذیر ایجاد کنند. 

ابزارها و روش‌های مانیتورینگ Concurrent Requests در سامانه‌های وب

تا به اینجا با مفهوم «درخواست‌های هم‌زمان» آشنا شدیم و به اهمیت مدیریت concurrent requests پی بردیم. حال در این بخش، برخی از روش‌های کلیدی مانیتورینگ داده‌ها را بررسی می‌کنیم و به معرفی برترین ابزارهای موجود در این حوزه می‌پردازیم.

کاربردی‌ترین روش‌ها برای مانیتورینگ درخواست‌های هم‌زمان (Concurrent Requests)

برای اینکه مانیتورینگ کاربردی بر روی درخواست‌های هم‌زمان داشته باشیم، لازم است که متریک‌‌های زیر را با دقت رصد کنیم:

 Active Connections / Active Requests

اولین شاخص، تعداد درخواست‌های در حال پردازش است که به‌عنوان پایه‌ای‌ترین شاخص برای نظارت بر ترافیک هم‌زمان هم شناخته می‌شود.

Throughput (RPS)

این شاخص نشان‌دهنده میزان داده‌ای است که می‌‌تواند طی مدت زمانی خاص در شبکه منتقل شود. اگر مقدار RPS از Active Requests بالاتر باشد، یعنی سیستم می‌تواند به‌خوبی از عهده پاسخگویی بر بیاید؛ اما اگر هر دو این شاخص‌ها بالا باشند، نشان‌دهنده این است که به سقف پردازشی نزدیک می‌شویم.

Queue Length

زمان انتظار در صف، یکی دیگر از شاخص‌های مهمی است که برای نظارت بر درخواست‌های هم‌زمان مورداستفاده قرار می‌گیرد. بالا بودن مدت زمان در صف ماندن درخواست‌ها، نشان‌دهنده گلوگاه‌هایی است می‌بایست شناسایی و در اسرع وقت رفع شوند 

 Latency Percentiles (p50 / p95 / p99)

برای ارزیابی کیفیت پاسخ‌دهی یک سرویس، تنها اندازه‌گیری میانگین زمان پاسخ‌گویی کافی نیست؛ بلکه این میانگین عملکرد درخواست‌هاست که می‌تواند دید روشنی به توسعه‌دهندگان بدهد. در شاخص‌های اندازه‌گیری میانگین، عدد P95 از اهمیت ویژه‌ای برخوردار است؛ چرا که به پیدا کردن زمان کندی سرویس، تشخیص مشکلات هم‌زمانی درخواست‌‌ها و یافتن endpoint های سنگین کمک شایانی می‌کند. 

 Error Rates (429 / 503 / Timeout)

زمانی که خطاهای 429 (Too Many Requests) و 503 (Service Unavailable) به نمایش در می‌آیند، یکی از نشانه‌های آن است که Concurrent Requests به سقف مجاز خود رسیده و نیازمند رسیدگی فوری است.

متریک‌های دیگری هم برای مانیتورینگ درخواست‌های هم‌زمان وجود دارد، اما با پایش همین شاخص‌ها می‌توانید تا حد زیادی از چالش‌های مرتبط با Concurrent Requests جلوگیری کنید.

ابزارهای تخصصی مانیتورینگ درخواست‌های همزمان (Concurrent Requests)

برای نظارت بر وضعیت سرویس و متریک‌هایی که در بخش قبل به آنها اشاره کردیم، به ابزارهای پایش لحظه‌ای رفتار بار سیستم نیاز داریم. برخی از ابزارهای رایج و قدرتمند مدیریت concurrent requests عبارت‌اند از:

 Prometheus و Grafana

ابزار Prometheus یکی از پرطرفدارترین سیستم‌های مانیتورینگ سرویس‌هاست که به‌صورت فعالانه وظیفه Scrape سرورها را برعهده دارد. متریک‌هایی که توسط Prometheus جمع‌آوری می‌شوند اغلب از جنس داده‌های سری زمانی هستند و شاخص‌هایی مانند میزان مصرف CPU، تعداد درخواست‌های در حال پردازش هم‌زمان، مدت‌زمان اجرای هر درخواست، تعداد خطاها در بازه‌های زمانی مختلف و… را محاسبه می‌کند.

هرچند که Prometheus در جمع‌آوری و ذخیره‌سازی داده‌ها قدرتمند ظاهر می‌شود؛ اما برای نمایش این داده‌ها در قالب نمودار و گراف‌های لحظه‌ای، نیاز به ابزارهای تخصصی دیگری دارد. اینجاست که Grafana وارد میدان می‌شود و وظیفه نمایش بصری داده‌های گردآوری شده را برعهده می‌گیرد. طی سال‌های اخیر، ترکیب این دو ابزار به استانداردی فراگیر نزد بسیاری از شرکت‌ها تبدیل شده و بسیاری از توسعه‌دهندگان برای پایش درخواست‌های هم‌زمان از این ترکیب استفاده می‌کنند.

New Relic و Datadog

برخلاف ابزارهایی مانند Prometheus که بیشتر بر جمع‌آوری داده‌های سری زمانی متمرکز هستند، دو ابزار New Relic و Datadog نقش یک ناظر همه‌جانبه را ایفا می‌کنند و تمامی تراکنش‌های سیستم را مورد بررسی قرار می‌دهند. این دو ابزار حرفه‌ای به‌منظور ردیابی توزیع شده (Distributed Tracing)، Throughput، Latency، مانیتورینگ کاربر واقعی (RUM) و تحلیل ظرفیت (Capacity Analysis) مورد استفاده قرار می‌گیرند. کاربرد دیگر این سرویس‌ها ارائه دید کاملاً Real-time از رفتار سیستم در مقیاس بزرگ است. در شرایطی که ترافیک بالا می‌رود یا بخشی از سیستم زیر فشار قرار می‌گیرد، New Relic و Datadog این امکان را دارند که با تحلیل‌های هوشمند، ریشه مشکلات را مشخص کنند. 

ELK Stack

این ابزار که از سه بخش Elasticsearch، Logstash و Kibana تشکیل شده، یک سیستم مشاهده‌پذیری مبتنی بر لاگ (Log) است که تمامی تراکنش‌های صورت گرفته را به یک منبع بزرگ برای خطایابی، بهبود امنیت و تحلیل رفتار سیستم تبدیل می‌کند. در سیستم ELK Stack، لاگ‌های خام در ابتدا وارد Logstash می‌شوند و سپس به موتور جستجوی Elasticsearch انتقال پیدا می‌کنند. در آخر، تمامی اطلاعات مورد نیاز بر روی Kibana به‌صورت بصری به نمایش در می‌آید. 

بیشتر بخوانید: پایگاه داده برداری Vector Database چیست؟ 

به‌طورکلی، تمامی این ابزارها می‌توانند به‌صورت مکمل و هم‌افزا در کنار یکدیگر فعالیت کنند. به طور مثال، ترکیب Prometheus  و Grafana برای پایش لحظه‌ای و شاخص‌های سری زمانی، همراه با ELK Stack برای تحلیل دقیق لاگ‌ها و ردیابی رخدادهای سیستم، یک دید کامل و جامع از وضعیت سرویس ارائه می‌دهد. در همین حال،  Newrelic و Datadog می‌توانند به‌عنوان لایه‌های بالاتر عمل کنند و رفتار سیستم در مقیاس بزرگ و توزیع‌شده را مورد رصد قرار دهند.

بررسی تأثیر Concurrent Request در APIهای هوش مصنوعی

امروزه بسیاری از کسب‌وکارها و توسعه‌دهندگان از API های هوش مصنوعی برای ارائه خدمات هوشمند به کاربران خود استفاده می‌کنند. از تحلیل متن و پردازش زبان طبیعی گرفته تا بینایی ماشین و تشخیص گفتار، این API ها نقش حیاتی در تجربه کاربری و عملکرد سیستم دارند. از آنجایی که این API ها اغلب پاسخگوی چندین درخواست به‌صورت هم‌زمان هستند، اهمیت مدیریت concurrent requests در این سرویس‌ها دوچندان می‌شود.

هر API محدودیت‌هایی در پردازش هم‌زمان درخواست‌ها دارد و این محدودیت‌ها می‌توانند ناشی از ظرفیت سرورها، پهنای باند شبکه، معماری سیستم یا حتی سیاست‌های ارائه‌دهنده سرویس باشند. وقتی تعداد درخواست‌های هم‌زمان از توان سیستم فراتر می‌رود، درخواست‌ها نمی‌توانند بلافاصله پردازش شوند و این امر باعث ایجاد صف و افزایش زمان انتظار می‌شود. رخ‌دادن چنین شرایطی می‌تواند عملکرد API را با چالش‌های جدی رو‌به‌رو کند و تجربه کاربری مخاطبان را به‌شدت تحت‌تأثیر قرار دهد.

یکی از اثرات جانبی افزایش درخواست‌های هم‌زمان، فشار فزاینده بر روی منابع سیستمی است. هر چه تعداد درخواست‌هایی که به‌صورت هم‌زمان توسط سرویس دریافت می‌شوند بیشتر باشد، مصرف CPU، حافظه دیسک و پردازنده‌های گرافیکی هم افزایش پیدا می‌کند. این فرایند در ابتدا باعث کاهش کارایی API و بروز خطاهای موقتی می‌شود و در صورت تشدید این روند، ممکن است برخی درخواست‌ها به‌طور کامل رد شوند و کاربران نتوانند با سرویس ارتباط برقرار کنند. در نتیجه، پیش‌بینی و مدیریت حجم درخواست‌های هم‌زمان و اجرای استراتژی‌های بهینه‌سازی در طراحی سیستم‌های مبتنی بر هوش مصنوعی، نه فقط یک فرایند جانبی مفید، بلکه بخشی ضروری و حیاتی برای صحت عملکرد پروژه به‌شمار می‌رود. 

جمع‌بندی

نظارت مداوم و مدیریت concurrent requests، به‌خصوص در API های مبتنی بر هوش مصنوعی نه‌تنها از بروز اختلال‌های عملکردی جلوگیری می‌کند، بلکه تضمین می‌کند که سیستم تحت فشار ترافیک بالا نیز پاسخگو و پایدار باقی بماند. با پایش مداوم شاخص‌هایی مانند زمان پاسخ‌دهی، تعداد خطاها و مصرف منابع، توسعه‌دهندگان می‌توانند نقاط ضعف سیستم را شناسایی و با استفاده از استراتژی‌هایی مانند صف‌بندی درخواست‌ها، محدودسازی نرخ درخواست‌ها (Rate Limiting) و مقیاس‌پذیری خودکار منابع، بار هم‌زمان را کنترل کنند. این اقدامات باعث می‌شوند تجربه کاربری بهینه حفظ شود، ریسک ازدست‌رفتن داده‌ها یا خطاهای بحرانی کاهش یابد و API بتواند به‌صورت پایدار و قابل‌اعتماد در مقیاس‌های بزرگ عمل کند.