در این مقاله
اگر هزینه اجرای Next.js را فقط با قیمت پردازش برنامه حساب کرده‌اید، تغییر Data Cache به Runtime Cache در Vercel را هم بررسی کنید. اطلاعیه ۳۰ اکتبر ۲۰۲۶ از تغییر محل کش و نحوه محاسبه مصرف پس از مهاجرت خبر می‌دهد. این تغییر به معنی گران‌شدن قطعی همه پروژه‌ها یا ضرورت خروج فوری نیست؛ ابتدا باید بدانید چه عملیاتی انجام می‌دهید، چه واحدی صورتحساب می‌شود و کدام مسیرها واقعاً از کش سود می‌برند.
این راهنما برای تیمی است که فروشگاه، داشبورد یا API ساخته و حالا بین ادامه استفاده از Vercel و ارزیابی یک میزبان دیگر تصمیم می‌گیرد. محور مقایسه، بار کاری یکسان است. در پایان باید بتوانید هزینه را از گزارش مصرف بخوانید، عامل افزایش آن را پیدا کنید و برای ارزیابی هاست Next.js پاستا یک آزمایش منصفانه طراحی کنید.
دقیقاً چه خبری اعلام شده است؟
در اعلام رسمی انتقال Data Cache، Vercel می‌گوید کش fetch و unstable_cache در مسیر مهاجرت به Runtime Cache منتقل می‌شود. زمانبندی تیم تازه، تیم موجود و فعالسازی زودهنگام یکسان نیست. برای تیمهای موجود Hobby، تاریخ اعلام‌شده ۲۹ نوامبر است؛ درباره پلن‌های دیگر باید اطلاع‌رسانی همان حساب را ملاک قرار داد. وضعیت واقعی حساب از عنوان خبر مهم‌تر است.
تاریخ بررسی این مقاله ۳۱ اکتبر ۲۰۲۶ است. نرخ و سهمیه، حقیقت دائمی نیستند و ممکن است با منطقه یا پلن تفاوت داشته باشند. اعداد را از صفحه رسمی قیمت و گزارش حساب وارد محاسبه کنید. نمونه‌های محاسباتی این راهنما فرضی‌اند و فاکتور یک مشتری یا تضمین قیمت آینده نیستند. همچنین قیمت خدمات یک شرکت را به قیمت پاستا تعمیم نمی‌دهیم.
درخواست صفحه، خواندن کش و واحد صورتحساب را جدا کنید
یک بازدید صفحه ممکن است چند عملیات خواندن کش ایجاد کند؛ ممکن است پاسخ از CDN برسد و به آن مسیر نرسد. اندازه داده، رفتار فریمورک و نوع عملیات هم می‌توانند در واحد مصرف اثر بگذارند. بنابراین شمارنده درخواست HTTP را مستقیم در نرخ read unit ضرب نکنید. واحد گزارش‌شده باید همان واحدی باشد که جدول صورتحساب تعریف میکند.
سه منبع را کنار هم قرار دهید: درخواست‌های ورودی، عملیات کش و تماس با منبع داده. اگر بازدید ثابت مانده اما نوشتن کش بالا رفته، احتمالاً مسئله فقط رشد مخاطب نیست. شاید کلیدها تنوع غیرضروری دارند، زمان انقضا بسیار کوتاه است یا هر انتشار داده یکسان را دوباره می‌سازد. این تشخیص قبل از انتخاب میزبان بعدی لازم است؛ مهاجرت بدون شناخت، همان الگو را به جای دیگری منتقل میکند.
اول گزارش مصرف قابل مقایسه بسازید
یک بازه با طول مشخص انتخاب کنید و زمان انتشار، کمپین تبلیغاتی و تغییر کد را روی آن علامت بزنید. مصرف روز تعطیل را با روز پرفروش بدون توضیح مقایسه نکنید. میزان Hit، Miss، خطا، حجم داده و عملیات نوشتن را برای مسیرهای مهم ثبت کنید. اگر گزارش بعضی فیلدها در پلن شما وجود ندارد، آن محدودیت را بنویسید و از ساختن عدد تخمینی دقیق‌نما پرهیز کنید.
اطلاعات شخصی را وارد کلید یا گزارش عمومی نکنید. نام مسیر و دسته عملیات معمولاً برای تشخیص کافی است؛ متن کامل درخواست کاربر و توکن احراز هویت لازم نیست. پیش از آزمایش، از تیم محصول بپرسید کدام داده می‌تواند قدیمی باشد. صفحه فهرست عمومی کالا با موجودی هنگام پرداخت و صفحه حساب کاربری قرارداد تازگی یکسانی ندارد.
هزینه را با ورودی‌های روشن محاسبه کنید
فرمول پایه، مجموع هزینه واحدهای خواندن و نوشتن پس از اعمال قواعد پلن است. اعتبار ماهانه، سهمیه، منطقه و دیگر هزینه‌ها باید جدا بررسی شوند. نمونه زیر عمداً ساده است: فقط تعداد واحد قابل پرداخت را می‌گیرد و قیمت فرضی هر یک میلیون واحد را از ورودی می‌خواند. این تابع موتور صورتحساب Vercel یا پاستا نیست و اعتبار پلن را خودکار محاسبه نمیکند.
export function estimateCacheUnits(reads, writes, readUsd, writeUsd) {
const values = [reads, writes, readUsd, writeUsd];
if (!values.every(v => Number.isFinite(v) && v >= 0)) {
throw new Error("invalid non-negative input");
}
if (!Number.isSafeInteger(reads) || !Number.isSafeInteger(writes)) {
throw new Error("unit counts must be safe integers");
}
const total = reads / 1_000_000 * readUsd
+ writes / 1_000_000 * writeUsd;
if (!Number.isFinite(total)) throw new Error("overflow");
return total;
}برای مثال آموزشی، یک میلیون واحد خواندن با نرخ فرضی دو دلار و نیم‌میلیون واحد نوشتن با نرخ فرضی چهار دلار، چهار دلار می‌شود. این نرخ‌ها نقل قیمت سرویس نیستند. با صفر واحد باید صفر بگیرید و ورودی منفی یا نامعتبر باید رد شود. تبدیل دلار به تومان هم به نرخ و زمان تسویه وابسته است؛ آن را به‌عنوان ستون جدا با تاریخ مشخص نگه دارید.
نظرات کاربران (۰)
هنوز نظری ثبت نشده است. اولین نفر باشید.