یک توسعهدهنده با افزایش فاصله زمانی درخواستهای دورهای (polling) در سمت کلاینت از ۳۰ ثانیه به ۱۵ دقیقه، هزینههای پردازشی پایگاه داده serverless شرکت Neon را کاهش داد. این وقفه طولانیتر به پایگاه داده اجازه میدهد تا به اندازه کافی در حالت بیکاری قرار بگیرد تا به وضعیت «مقیاسپذیری به صفر» (scale to zero) برسد؛ امری که باعث حذف اعتبارهای پردازشی میشود که یک درخواست ۳۰ ثانیهای مداوم مصرف میکرد.
Neon برای هر ثانیهای که موتور پردازشیاش در حال اجراست، هزینه دریافت میکند. در یک ساختار معمول serverless، هر درخواستی — هرچقدر هم کوچک — موتور را فعال نگه میدارد. داشبورد تلویزیونی نویسنده هر نیم دقیقه یکبار از پایگاه داده پرسوجو (query) میکرد، در حالی که دادههای نمایشدادهشده تنها زمانی تغییر میکردند که کاربر بهصورت دستی همگامسازی (sync) انجام دهد یا پخش جدیدی آغاز شود. این الگو مانع از رسیدن مجموعه پردازشی Neon به وضعیت صفر (zero-state) میشد (وضعیتی که صورتحساب را متوقف میکند) و باعث ایجاد جهشهای منظم در داشبورد هزینههای Vercel میشد.
چرا درخواستهای دورهای اولیه اهمیت داشتند
- داشبورد یک کامپوننت React صرفاً در سمت کلاینت بود، بنابراین هر نمونه مرورگر مستقیماً به Neon درخواست میفرستاد.
- قیمتگذاری Neon هزینه را به زمان پردازش فعال مرتبط میکند، نه تعداد درخواستها؛ بنابراین یک درخواست در هر ۳۰ ثانیه، یک هزینه پایه را تداوم میبخشید.
- مانیتورینگ Vercel نویسنده همبستگی بین ترافیک و میزان استفاده از پردازش Neon را نشان داد که تأیید میکرد همین درخواستهای دورهای باعث فعال ماندن پایگاه داده میشدند.
راهکارهای جایگزین ناموفق
استفاده از یک debounce سریع — یعنی به تأخیر انداختن درخواست پس از آخرین تعامل کاربر — کمکی نکرد، زیرا تایمر همچنان هر ۳۰ ثانیه یکبار اجرا میشد. همچنین استفاده از Vercel Edge Functions را امتحان کردم، اما این کار پیچیدگی بیش از حد ایجاد کرد.
راهکار ساده
تنها تغییر کد مورد نیاز، جایگزین کردن ثابتی (constant) بود که فاصله زمانی بازنشانی (refresh interval) را تعیین میکرد:
- از ۳۰ ثانیه ← ۵ دقیقه
- سپس ۵ دقیقه ← ۱۵ دقیقه
در فاصله ۱۵ دقیقهای، Neon زمان کافی برای تشخیص عدم فعالیت و متوقف کردن منابع پردازشی خود را دارد. داشبورد همچنان کارآمد باقی میماند: کاربران همچنان با بازنشانی دستی، آخرین دادهها را مشاهده میکنند و درخواستهای دورهای خودکارِ گاهوبیگاه نیز بدون ایجاد ترافیک مداوم، پخشهای جدید را شناسایی میکنند.
چرا درخواستهای دورهای را در سمت کلاینت نگه داریم؟
- سادگی – بدون نیاز به توابع serverless اضافی یا مراحل ساخت (build) بیشتر.
- انتظارات کاربر – داشبورد در حال حاضر مانند یک اپلیکیشن کلاینت عمل میکند؛ یک کلیک دستی همچنان باعث بهروزرسانی فوری میشود.
- همسویی با مدل هزینه – Neon بر اساس ثانیه پردازش هزینه میگیرد، نه بر اساس تعداد درخواست؛ بنابراین کاهش فرکانس درخواستها مستقیماً صورتحساب را کاهش میدهد.
درسهایی برای توسعهدهندگان serverless
- فرکانس درخواستهای دورهای را با آهنگ بهروزرسانی واقعی دادههای خود مطابقت دهید. اگر یک مجموعه داده تنها چند بار در ساعت تغییر میکند، فاصله ۱۵ دقیقهای اغلب کافی است.
- درخواستهای دورهای مکرر در محیط serverless یک عامل مخفی افزایش هزینه است؛ حتی یک درخواست اضافی در هر دقیقه میتواند مانع از کاهش مقیاس (scaling down) پایگاه داده شود.
- تغییرات کوچک در تنظیمات میتواند بدون نیاز به بازنگری در معماری، صرفهجوییهای بسیار بزرگی ایجاد کند.
خلاصه کلام: تغییر یک مقدار ثابت، پایگاه دادهای که مدام فعال بود را به یک کامپوننت واقعاً serverless تبدیل کرد و ضمن حفظ کارایی داشبورد، هزینههای پردازشی را کاهش داد. برای هر تیمی که از Neon یا سرویسهای پردازشی مشابه (با محاسبه بر اساس ثانیه) استفاده میکند، بازنگری در فواصل زمانی درخواستها یک پیروزی سریع است که ارزش تست کردن در همین امروز را دارد.