ساعت ۸:۵۹ صبح است. چندهزار دانشجو یا فراگیر در صفحه ورود نشسته‌اند. عقربه ساعت روی ۹:۰۰ قرار می‌گیرد، هجوم کلیک‌ها برای بارگذاری سوالات شروع می‌شود و در کمتر از چند ثانیه، صفحه سفید، چرخش بی‌پایان مرورگر و در نهایت خطای 502 Bad Gateway ظاهر می‌شود! تلفن‌های تیم IT زنگ می‌خورد و مدیران چاره‌ای جز ابطال آزمون نمی‌بینند.
آیا واقعاً پهنای باند کم بود یا رم سرور پاسخ نداد؟ در اغلب موارد، هیچ‌کدام! این بحران حاصل افتادن در یک تله محاسباتی در انتخاب و معماری LMS است: اشتباه گرفتن «کاربر ثبت‌نامی» با «کاربر فعال همزمان».
وقتی یک نرم‌افزار آموزشی می‌گوید «پشتیبانی از ۲۰,۰۰۰ کاربر»، از منظر دیتابیسی صرفاً یعنی ۲۰ هزار ردیف اطلاعات در جدول کاربران ذخیره شده است؛ داده‌ای که در حالت عادی هیچ فشاری به پردازنده (CPU) نمی‌آورد.
اما سناریوی آزمون آنلاین کاملاً متفاوت است:
کاربر وبینار: تنها پورت‌های استریم صوت و تصویر و پهنای باند شبکه را درگیر می‌کند.
کاربر آزمون: با هر کلیک روی «ثبت پاسخ»، یک دستور نوشتن (Write Transaction) به دیتابیس شلیک می‌کند.
وقتی ۲ هزار نفر دقیقاً در ثانیه‌ای مشترک کلیک می‌کنند، مخزن اتصالات (Connection Pool) سرریز شده و پایگاه داده به دلیل کوئری‌های همزمان دچار قفل‌شدگی متقابل (Deadlock) می‌شود. بالا بردن رم و سخت‌افزار سرور در این شرایط مسکن موقت است، نه درمان!
برای عبور از این گلوگاه، معماری سیستم باید از ارسال مستقیم درخواست به دیتابیس جلوگیری کند. سامانه‌های استاندارد مقیاس‌پذیر از لایه‌های واسط صف‌بندی (Message Broker نظیر Redis یا RabbitMQ) استفاده می‌کنند:
ثبت موقت کلیک در حافظه بافر: پاسخ دانشجو در کسری از ثانیه در RAM ذخیره و تاییدیه سریع به مرورگر ارسال می‌شود.
تخلیه کنترل‌شده به سمت دیتابیس: ورکرها با صف‌بندی منظم، داده‌ها را بدون خفه کردن دیتابیس می‌نویسند. این مکانیزم ساده و بنیادین، مصرف جهشی پردازنده (CPU Spike) را تا ۴۰ درصد مهار می‌کند و احتمال بروز خطای ۵۰۲ را به صفر می‌رساند.
در ارزیابی سامانه‌ها، تناسب ابعاد جمعیتی با نوع استقرار حیاتی است:
زیر ۱,۰۰۰ کاربر (کمتر از ۱۰۰ کاربر همزمان): سیستم‌های ابری اشتراکی (SaaS) مقرون‌به‌صرفه‌ترین گزینه هستند و نیازی به زیرساخت اختصاصی ندارند.
۱,۰۰۰ تا ۵,۰۰۰ کاربر (تا ۱,۰۰۰ همزمان): سرورهای مجازی اختصاصی همراه با لایه کشینگ وب‌سرور می‌توانند پاسخگو باشند.
بالای ۵,۰۰۰ کاربر دانشگاهی و سازمانی (بیش از ۲,۰۰۰ همزمان در آزمون): سیستم‌های اشتراکی در این مقیاس قطعاً دچار اختلال می‌شوند. در این لایه، معماری مبتنی بر صف، استقرار ایزوله در شبکه اختصاصی (On-Premise) و وب‌سرویس مستقیمِ تبادل داده (حذف ورود دستی فایل اکسل) الزامات غیرقابل مذاکره هستند.
خلاصه کلام:
اگر به عنوان مدیر آموزشی، مشاور یا متخصص فاوا به دنبال ارزیابی سامانه هستید، در بروشورها دنبال تعداد کاربر ثبت‌نامی نگردید. سوال کلیدی این است: «سیستم شما در ثانیه پیک آزمون با ۳ هزار درخواست نوشتنِ همزمان، از چه مکانیزم صف‌بندی استفاده می‌کند؟»
