مهدی مولویاین راهنماها از کار روزمرهٔ من با سیستم‌های پرترافیک دات‌نت آمده‌اند: جایی که API باید در اوج آزمون سرپا بماند، پایگاه‌داده زیر بار کند نشود و پیام‌ها نه گم شوند و نه اثرشان دو بار اعمال شود. هر راهنما یک مسئلهٔ مشخص را از تشخیص تا راه‌حل دنبال می‌کند و نمونه‌کدهایش با نسخه‌های فعلی ابزارها نوشته شده‌اند.
راهنماها
- بهینه‌سازی SQL Server برای APIهای پرترافیک پیدا کردن کوئری‌های گران با Query Store، خواندن پلن اجرایی، ایندکس پوشاننده، parameter sniffing، قفل‌ها و RCSI، دام‌های EF Core و نوشتن دسته‌ای با SqlBulkCopy.
- تست بار API با Locust نوشتن سناریوی واقعی، اجرای headless و توزیع‌شده، خواندن RPS و صدک‌ها، و پیدا کردن گلوگاه در سمت سرور.
- کش در ASP.NET Core IMemoryCache، Redis، HybridCache دولایه و Output Caching؛ این‌که هرکدام برای چه کاری است، کلید و TTL را چطور انتخاب کنیم و چه چیزی را نباید کش کرد.
- RabbitMQ در دات‌نت تأیید ناشر، ack دستی و prefetch، مصرف‌کنندهٔ idempotent، retry با تأخیر، صف پارکینگ و الگوی Outbox.
این راهنماها از کجا آمده‌اند
در «گزینه دو» روی سیستمی کار می‌کردم که در اوج آزمون‌ها ۴۵ تا ۷۰ هزار کاربر هم‌زمان داشت. پیش از اوج‌ها، APIهای پرتکرار را با Locust زیر بار می‌بردیم تا گلوگاه‌ها پیدا شوند، کوئری‌های SQL Server و مسیرهای کش را بهینه می‌کردیم و Redis را با Sentinel در حالت دسترس‌پذیری بالا نگه می‌داشتیم. شرح کامل آن پروژه در مطالعهٔ موردی سیستم آزمون در اوج ترافیک آمده است.
روایت‌های مفصل‌تر، با زمینهٔ هر پروژه، در مجموعهٔ «یادداشت‌های بک‌اند» است. از قسمت اول، دربارهٔ Redis Sentinel در اوج آزمون شروع کنید؛ بقیهٔ قسمت‌ها در بخش یادداشت‌ها فهرست شده‌اند.
از کجا شروع کنیم؟
اگر سیستم شما در اوج کند می‌شود و نمی‌دانید چرا، از تست بار شروع کنید: بدون اندازه‌گیری، هر بهینه‌سازی حدس است. اگر اندازه‌گیری نشان داد زمان پاسخ در پایگاه‌داده صرف می‌شود، سراغ راهنمای SQL Server بروید. کش و صف پیام را وقتی اضافه کنید که بدانید چه مسئله‌ای را حل می‌کنند.
اگر برای یک سیستم مشخص به کمک نیاز دارید، در صفحهٔ همکاری توضیح داده‌ام چه کمکی از من برمی‌آید.