چطور هزینه میزبانی اپلیکیشن را کم کنیم

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

بیشتر اپ‌های کوچک مشکل ترافیک ندارند. مشکل آن‌ها «همیشه چیزی روشن است» است. این راهنما نشان می‌دهد چطور آن را پیدا و رفع کنید، با دستوراتی که می‌توانید به یک ساز اپلیکیشن با هوش مصنوعی بدهید.

در واقع برای چه چیزی پول می‌دهید

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

بسیاری از میزبان‌های مدرن، از جمله Mythex، تا صفر مقیاس می‌شوند: وقتی کسی اپ را استفاده نمی‌کند، سرور متوقف می‌شود و برای پردازش هزینه‌ای ندارد، و با بازدید بعدی بیدار می‌شود. این سؤال را از «سرورم چقدر بزرگ است؟» به «چرا سرورم بیدار است؟» تغییر می‌دهد.

گام ۱: ببینید پول کجا می‌رود

قبل از تغییر هر چیزی، صفحه مصرف میزبانتان را باز کنید و پیدا کنید:

• کدام پروژه بیشترین هزینه را دارد. اغلب یک اپ بخش بزرگی از صورتحساب است.
• کدام دسته — پردازش، پایگاه داده، پهنای باند یا فضای ذخیره‌سازی.
• چه زمانی خرج می‌کند. یک خط صاف در شب، وقتی کاربری ندارید، نشانه این است که چیزی اپ را بیدار نگه می‌دارد.

در Mythex، جزئیات مصرف مصرف ۳۰ روز گذشته را به دو بخش Build (عامل هوش مصنوعی) و Run (میزبانی، پهنای باند، پایگاه داده و ذخیره‌سازی فایل) تقسیم و بر اساس پروژه نشان می‌دهد.

گام ۲: بگذارید اپ‌ها و پایگاه‌های داده بیکار بخوابند

برای بیشتر اپ‌های کوچک، این اهرم واقعی است. پایگاه داده‌ای که وقت بیکاری می‌خوابد و با درخواست بعدی بیدار می‌شود، در ساعات آرام تقریباً هزینه‌ای ندارد. پایگاه داده‌ای که هر چند ثانیه کوئری می‌شود هرگز بیکار نمی‌شود، پس تمام روز هزینه‌اش را می‌دهید.

محدودیت‌های میزبانی Mythex توضیح می‌دهد این برای اپ‌های منتشرشده چطور کار می‌کند: اپ خوابیده هزینه پردازشی ندارد، پایگاه داده با کوچک‌ترین اندازه شروع می‌شود، هنگام شلوغی بزرگ می‌شود، بعد از ۵ دقیقه بیکاری می‌خوابد، و هزینه‌اش برابر است با اندازه‌اش ضرب در مدت زمانی که بیدار بوده. بنابراین اپی که حتی هر چند دقیقه یک بار پایگاه داده‌اش را کوئری می‌کند، شبانه‌روز مانند اپی که همیشه مشغول است صورتحساب می‌شود، در حالی که همان اپ بدون این ارتباط پس‌زمینه هزینه بسیار کمی دارد.

چیزهای رایجی که اپ را بیدار نگه می‌دارند:

• پولینگ. صفحه‌ای که هر ۲ تا ۵ ثانیه از سرور می‌پرسد «چیز جدیدی هست؟». اگر آن تب روی یک لپ‌تاپ باز بماند، پایگاه داده هرگز نمی‌خوابد.
• داشبوردهای با تازه‌سازی خودکار که داده‌ها را با تایمر دوباره بارگذاری می‌کنند، حتی وقتی کسی نگاه نمی‌کند.
• مانیتورهای آپتایم که هر دقیقه اپ را پینگ می‌زنند.
• حلقه‌های پس‌زمینه در کد سرور — یک setInterval که برای همیشه داده‌ها را پاک‌سازی یا همگام‌سازی می‌کند.
• درخواست‌های زمان‌بندی‌شده «زنده نگه داشتن» که کسی برای جلوگیری از بازدید کند اول اضافه کرده — آن‌ها با جلوگیری از خوابیدن کار می‌کنند، و دقیقاً همین است که هزینه دارد.

از هوش مصنوعی بخواهید آن‌ها را پیدا کند:

در کد دنبال هر چیزی بگرد که با تایمر اجرا می‌شود یا مکرراً پایگاه داده را کوئری می‌کند: پولینگ، setInterval، تازه‌سازی خودکار، حلقه‌های پس‌زمینه. هر کدام را فهرست کن، بگو هر چند وقت اجرا می‌شود و آیا وقتی کسی صفحه را باز ندارد هم اجرا می‌شود. هنوز چیزی را تغییر نده.

سپس آن‌ها را یکی‌یکی رفع کنید:

داشبورد هر ۳ ثانیه از /api/orders پولینگ می‌کند. آن را طوری تغییر بده که فقط وقتی تب مرورگر قابل‌مشاهده است تازه‌سازی شود و به جای ۳ ثانیه، هر ۶۰ ثانیه. یک دکمه دستی Refresh هم اضافه کن.

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

گام ۳: اندازه سرور را درست تنظیم کنید

دستگاه‌های بزرگ‌تر در هر ساعت هزینه بیشتری دارند. بسیاری از اپ‌هایی که با هوش مصنوعی ساخته شده‌اند با اندازه پیش‌فرضی شروع می‌شوند که کافی است؛ مشکل وقتی پیش می‌آید که برای رفع کندی‌ای که در واقع از یک کوئری کند بوده، «قدرت بیشتر» بخواهید.

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

در Mythex، اندازه دستگاه هنگام انتشار بر اساس نیاز اپ انتخاب می‌شود و ماشین‌های اضافی فقط وقتی ترافیک زیاد است شروع می‌شوند و وقتی ترافیک کم می‌شود دوباره می‌خوابند. هزینه تابع اندازه است، پس اگر فکر می‌کنید بیش از حد بزرگ است، در گفتگو کوچک‌تر شدنش را بخواهید.

گام ۴: پهنای باند را کم کنید

پهنای باند همان حجمی است که بازدیدکننده‌ها دانلود می‌کنند. تصاویر معمولاً بزرگ‌ترین بخش آن‌اند.

• تصاویر را فشرده کنید و فرمت‌های جدید مثل WebP یا AVIF را سرو کنید.
• تصاویر را به اندازه‌ای که نمایش داده می‌شوند تغییر اندازه دهید. عکسی ۴٬۰۰۰ پیکسلی که به صورت تصویر کوچک ۴۰۰ پیکسلی نشان داده می‌شود، بیشتر چیزی را که دانلود شده هدر می‌دهد.
• تصاویر پایین صفحه اول را تنبل‌بارگذاری (lazy-load) کنید.
• فایل‌های استاتیک (اسکریپت‌ها، استایل‌ها، تصاویر) را کش کنید تا بازدیدکنندگان تکراری دوباره دانلودشان نکنند. کش چیست را ببینید.
• اجازه ندهید اپ با هر بازدید از صفحه فایل‌های بزرگ بدهد.

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

سرعت بیشتر صفحه و پهنای باند کمتر معمولاً با هم می‌آیند — چطور وب‌سایتمان را سریع‌تر کنیم را ببینید.

گام ۵: هر چیزی را که کسی استفاده نمی‌کند پاک کنید

• اپ‌های قدیمی را منتشر نکنید — دیپلوی‌های آزمایشی، آزمایش‌های تمام‌شده، سایت رویداد سال گذشته.
• آپلودهای قدیمی، لاگ‌ها و خروجی‌هایی را که لازم ندارید پاک کنید.
• لینک‌های پیش‌نمایش مشترک را که دیگر استفاده نمی‌کنید حذف کنید. در Mythex، باز کردن لینک پیش‌نمایش پروژه را بیدار می‌کند و با اعتبار شما اجرا می‌شود، پس لینکی که فراموش شده و کسی مدام بازش می‌کند، همچنان هزینه دارد.
• سرویس‌های استفاده‌نشده را حذف کنید — یک سرور API یا worker که اپ دیگر صدایش نمی‌زند.

گام ۶: یک سایت استاتیک را در نظر بگیرید

اگر سایتتان ورود کاربر، داده ذخیره‌شده کاربر یا منطق سرور ندارد — یک سایت بازاریابی، نمونه‌کارهای شخصی، یک منو — می‌تواند یک سایت استاتیک باشد: فایل‌های ساده‌ای که از CDN سرو می‌شوند. سرور یا پایگاه داده‌ای نیست که در حال اجرا بماند. در Mythex، سایت‌های استاتیک وقتی فقط نشسته‌اند اعتبار مصرف نمی‌کنند.

این سایت ورود کاربر یا داده ذخیره‌شده ندارد. آیا می‌شود آن را بدون سرور به صورت سایت استاتیک بازسازی کرد؟ چه چیزی را از دست می‌دهیم؟

گام ۷: هزینه APIهای پولی را زیر نظر بگیرید

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

• برای هر چیزی که برای هر تماس هزینه دارد، ورود را الزامی کنید.
• یک محدودیت برای هر کاربر اضافه کنید (ببینید محدودسازی نرخ چیست).
• پاسخ‌هایی را که تغییر نمی‌کنند کش کنید، مانند تبدیل همان آدرس به مختصات جغرافیایی.
• در هر ارائه‌دهنده سقف هزینه یا هشدار تنظیم کنید.

اشتباه‌های رایج

• حدس زدن به جای اندازه‌گیری. اول تفکیک مصرف را بررسی کنید؛ بخش گران اغلب چیزی نیست که انتظارش را دارید.
• خریدن سرور بزرگ‌تر برای رفع کندی. نبودن یک ایندکس پایگاه داده یا بارگذاری داده‌ی زیاد معمولاً علت واقعی است.
• پولینگ همه‌چیز. هر تایمر چند ثانیه‌ای دلیلی است که پایگاه داده بیدار بماند.
• پینگ زدن اپ برای «گرم نگه داشتن». این همان صرفه‌جویی‌ای را که تا صفر مقیاس شدن می‌دهد از بین می‌برد. یک تأخیر کوتاه در اولین بازدید را بپذیرید، یا عمداً برای روشن بودن دائمی پول بدهید.
• فراموش کردن دیپلوی‌های قدیمی. اپ‌های استفاده‌نشده با پایگاه داده و کارهای پس‌زمینه بی‌سروصدا جمع می‌شوند.
• تصاویر فشرده‌نشده. اغلب تنها بزرگ‌ترین هزینه پهنای باند در سایت‌های کوچک است.

چک‌لیست

• می‌دانم کدام پروژه و کدام دسته (پردازش، پایگاه داده، پهنای باند، فضای ذخیره‌سازی) بیشترین هزینه را دارد.
• هیچ چیزی وقتی کسی نگاه نمی‌کند هر چند ثانیه پایگاه داده را پولینگ نمی‌کند.
• داشبوردها در یک بازه معقول یا فقط وقتی تب قابل‌مشاهده است تازه می‌شوند.
• هیچ مانیتور آپتایم یا حلقه پس‌زمینه‌ای بدون دلیل اپ را بیدار نگه نمی‌دارد.
• سرور کوچک‌ترین اندازه‌ای است که کار می‌کند.
• تصاویر تغییر اندازه، فشرده و تنبل‌بارگذاری شده‌اند؛ فایل‌های استاتیک کش شده‌اند.
• اپ‌های قدیمی منتشرنشده‌اند، فایل‌های قدیمی حذف شده‌اند و لینک‌های پیش‌نمایش استفاده‌نشده برداشته شده‌اند.
• سایت‌هایی که داده یا ورود ندارند، استاتیک هستند.
• APIهای پولی ورود، محدودیت برای هر کاربر و هشدار هزینه در ارائه‌دهنده دارند.

کم کردن هزینه در Mythex

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

• اپ‌های منتشرشده و پایگاه داده‌هایشان وقتی بیکارند می‌خوابند و با بازدید بعدی بیدار می‌شوند. پایگاه داده بعد از ۵ دقیقه بیکاری می‌خوابد، پس حذف پولینگ مداوم معمولاً بزرگ‌ترین برد است.
• پلن Pro برای میزبانی، پایگاه داده‌ها، پهنای باند، ذخیره‌سازی فایل و محیط پیش‌نمایش نصف نرخ پلن Free را می‌پردازد؛ هزینه‌های هوش مصنوعی در هر دو پلن یکسان است. اعتبار را ببینید.
• قبل از اینکه موجودی کم باعث توقف یک اپ منتشرشده شود، ایمیل دریافت می‌کنید، و اپ‌های متوقف‌شده پایگاه داده و فایل‌هایشان را نگه می‌دارند.

برای تصویر کلی‌تر درباره هزینه‌های اجرا، چقدر هزینه دارد یک اپ بسازیم و وب‌هاستینگ چیست را ببینید.

پرسش‌ها