كيفية تقليل تكاليف الاستضافة لتطبيقك

لتقليل تكاليف الاستضافة، اعرف ما الذي يعمل فعلًا ولماذا، ثم دع كل شيء ينام عندما لا يستخدمه أحد. في المنصات التي تنخفض إلى الصفر، يكلّف التطبيق الخامل وقاعدة البيانات النائمة القليل جدًا؛ لذا تأتي أكبر الوفورات غالبًا من إزالة ما يُبقيهما مستيقظَين، وهو غالبًا شيفرة تتحقق من قاعدة البيانات كل بضع ثوانٍ، ثم من تقليص النطاق الترددي وحذف التطبيقات التي لا يستخدمها أحد.

معظم التطبيقات الصغيرة لا تعاني مشكلة في حركة المرور، بل مشكلة «شيء يعمل دائمًا». يوضح هذا الدليل كيف تجده وتصلحه، مع أوامر يمكنك إعطاؤها لمنشئ تطبيقات بالذكاء الاصطناعي.

ما الذي تدفع ثمنه فعلًا

تأتي فواتير الاستضافة للتطبيقات الصغيرة من عدد محدود من البنود. ومعرفة أيها كبير تخبرك أين تنظر.

كثير من المنصات الحديثة، ومنها Mythex، تنخفض إلى الصفر: عندما لا يستخدم أحد التطبيق يتوقف الخادم ولا يكلّف شيئًا على الحوسبة، ثم يستيقظ عند الزيارة التالية. وهذا يغيّر السؤال من «كم حجم خادمي؟» إلى «لماذا خادمي مستيقظ؟»

الخطوة 1: انظر إلى مكان ذهاب المال

قبل تغيير أي شيء، افتح صفحة الاستخدام لدى منصتك واعثر على:

• أي مشروع يكلّف أكثر. غالبًا تطبيق واحد يشكّل معظم الفاتورة.
• أي فئة — الحوسبة أو قاعدة البيانات أو النطاق الترددي أو التخزين.
• متى يُنفق. خط مستوٍ طوال الليل، حين لا يوجد مستخدمون لديك، هو الدليل على أن شيئًا ما يُبقي التطبيق مستيقظًا.

في Mythex، تعرض تفاصيل الاستخدام آخر 30 يومًا مقسّمة إلى Build (وكيل الذكاء الاصطناعي) وRun (الاستضافة والنطاق الترددي وقاعدة البيانات وتخزين الملفات)، مع تفصيل حسب المشروع.

الخطوة 2: دع التطبيقات وقواعد البيانات الخاملة تنام

هذه هي الرافعة الحقيقية لمعظم التطبيقات الصغيرة. قاعدة البيانات التي تنام عند الخمول وتستيقظ عند الطلب التالي تكلّف شبه لا شيء خلال الساعات الهادئة. أما قاعدة البيانات التي يُستعلم منها كل بضع ثوانٍ فلا تخمل أبدًا، فتدفع ثمنها طوال اليوم.

تشرح حدود الاستضافة في Mythex كيف يعمل ذلك للتطبيقات المنشورة: التطبيق النائم لا ينفق شيئًا على الحوسبة، وقاعدة البيانات تبدأ بأصغر حجم لها وتكبر أثناء النشاط، وتنام بعد 5 دقائق خمول، وتُحتسب بحجمها مضروبًا في المدة التي كانت فيها مستيقظة. لذلك يُحتسب التطبيق الذي يستعلم من قاعدة بياناته ولو مرة كل بضع دقائق، ليلًا ونهارًا، كما لو كان مشغولًا باستمرار؛ بينما التطبيق نفسه دون أي نشاط خلفي خفيّ يكلّف القليل جدًا.

من الأشياء الشائعة التي تُبقي التطبيق مستيقظًا:

• الاستطلاع (Polling). صفحة تسأل الخادم «هل من جديد؟» كل 2–5 ثوانٍ. اترك تبويب واحدًا مفتوحًا على حاسوب واحد، ولن تنام قاعدة البيانات أبدًا.
• لوحات معلومات تتحدث تلقائيًا تعيد تحميل البيانات بمؤقت، حتى عندما لا ينظر إليها أحد.
• مراقبات التوفر (Uptime monitors) التي ترسل طلبًا للتطبيق كل دقيقة.
• حلقات خلفية في شيفرة الخادم — مثل setInterval ينظف البيانات أو يزامنها إلى الأبد.
• طلبات «إبقاء الحياة» مجدولة أضافها أحدهم لتجنب الزيارة الأولى البطيئة — وهي تعمل بمنع النوم، وهذا بالضبط ما يكلّف المال.

اطلب من الذكاء الاصطناعي أن يجدها:

ابحث في الشيفرة عن أي شيء يعمل وفق مؤقت أو يستعلم من قاعدة البيانات بشكل متكرر: الاستطلاع، و setInterval، والتحديث التلقائي، والحلقات الخلفية. اذكر كل واحد، وكم مرة يعمل، وهل يعمل عندما لا تكون الصفحة مفتوحة لدى أحد. لا تغيّر شيئًا بعد.

ثم أصلحها واحدًا تلو الآخر:

لوحة المعلومات تستطلع /api/orders كل 3 ثوانٍ. غيّرها لتتحدث فقط عندما تكون علامة تبويب المتصفح ظاهرة، وكل 60 ثانية بدلًا من 3. وأضف زر تحديث يدوي.

إذا كان تطبيقك يحتاج فعلًا إلى تحديثات مباشرة (دردشة، أو نتائج مباشرة)، فاسأل هل يمكن أن يدفع التحديثات فقط عندما يتغير شيء، بدلًا من السؤال باستمرار. وبالنسبة لكثير من التطبيقات، يكفي أن «يتحدث عند عودة المستخدم إلى التبويب».

الخطوة 3: اضبط حجم الخادم على احتياجه

الأجهزة الأكبر تكلّف أكثر في الساعة. كثير من التطبيقات المبنية بالذكاء الاصطناعي تبدأ بحجم افتراضي يكفيها، والمشكلات تأتي عندما يُطلب «مزيد من القوة» لإصلاح بطء كان في الحقيقة استعلامًا بطيئًا.

• احتفظ بأصغر حجم يخدم حركة المرور دون أخطاء.
• إذا رأيت تعطلات بسبب الذاكرة، فاسأل أولًا الذكاء الاصطناعي هل يحمّل التطبيق كثيرًا في الذاكرة (جدولًا كاملًا بدلًا من صفحة واحدة من النتائج).
• أضف أجهزة فقط عندما تكون لديك حركة مرور مقاسة تحتاج إليها.

في Mythex يُختار حجم الجهاز عند النشر بحسب احتياجات التطبيق، ولا تبدأ الأجهزة الإضافية إلا عند كثافة حركة المرور، وتعود إلى النوم عندما تنخفض. التكلفة تتبع الحجم، فاطلب في المحادثة حجمًا أصغر إذا رأيت أن الحجم الحالي أكبر من اللازم.

الخطوة 4: قلّل النطاق الترددي

النطاق الترددي هو ما يحمّله الزوار. والصور غالبًا أكبر جزء منه.

• اضغط الصور وقدّمها بصيغ حديثة مثل WebP أو AVIF.
• غيّر حجم الصور إلى الحجم الذي تُعرض به. صورة بعرض 4000 بكسل تُعرض كصورة مصغّرة بعرض 400 بكسل تُهدر معظم ما يُحمَّل.
• أجّل تحميل الصور التي تقع تحت الجزء الظاهر من الشاشة (lazy loading).
• خزّن الملفات الثابتة مؤقتًا (السكربتات والتنسيقات والصور) حتى لا يعيد الزوار العائدون تحميلها. راجع ما هو التخزين المؤقت.
• لا تسمح للتطبيق بتقديم ملفات كبيرة مع كل عرض صفحة.

افحص كل صورة في التطبيق. غيّر حجمها إلى أكبر حجم تُعرض به، وحوّلها إلى WebP، وأجّل تحميل أي شيء تحت الشاشة الأولى. أخبرني الحجم الإجمالي قبل التعديل وبعده.

عادةً تترافق الصفحات الأسرع مع نطاق ترددي أقل — راجع كيفية جعل موقعك أسرع.

الخطوة 5: نظّف ما لا يستخدمه أحد

• ألغِ نشر التطبيقات القديمة — نشرات الاختبار، والتجارب المنتهية، وموقع الحدث الذي انتهى العام الماضي.
• احذف الرفعات والسجلات والتصديرات القديمة التي لا تحتاجها.
• احذف روابط المعاينة المشتركة التي لم تعد تستخدمها. في Mythex، فتح رابط معاينة يوقظ المشروع ويُحتسب من رصيدك، فالرابط المنسي الذي يواصل أحدهم فتحه ما زال يكلّف.
• أزل الخدمات غير المستخدمة — خادم API أو عامل خلفي لم يعد التطبيق يستدعيه.

الخطوة 6: فكّر في موقع ثابت

إذا كان موقعك بلا تسجيل دخول، وبلا بيانات محفوظة للمستخدمين، وبلا منطق خادم — كموقع تسويقي أو معرض أعمال أو قائمة طعام — فيمكن أن يكون موقعًا ثابتًا: ملفات بسيطة تُقدَّم من شبكة CDN. لا يوجد خادم أو قاعدة بيانات يجب أن يبقيا يعملان. وفي Mythex، لا تستهلك المواقع الثابتة رصيدًا وهي قائمة.

هذا الموقع بلا تسجيل دخول ولا بيانات محفوظة. هل يمكن إعادة بنائه كموقع ثابت بلا خادم؟ ماذا سنخسر؟

الخطوة 7: راقب استدعاءات واجهات البرمجة المدفوعة

بالنسبة للتطبيقات التي تستدعي نماذج الذكاء الاصطناعي أو الخرائط أو الرسائل النصية، قد تتجاوز فواتير الأطراف الثالثة فاتورة الاستضافة بكثير.

• اشترط تسجيل الدخول لأي شيء يكلّف مالًا عند كل استدعاء.
• ضع حدًا لكل مستخدم (راجع ما هو تحديد المعدل).
• خزّن الإجابات التي لا تتغير مؤقتًا، مثل تحويل العنوان نفسه إلى إحداثيات.
• ضع حدودًا للإنفاق أو تنبيهات لدى كل مزوّد.

أخطاء شائعة

• التخمين بدلًا من القياس. راجع تفصيل الاستخدام أولًا؛ فالجزء المكلف غالبًا ليس ما كنت تتوقعه.
• شراء خادم أكبر لإصلاح البطء. غياب فهرس في قاعدة البيانات أو تحميل بيانات كثيرة هو السبب الحقيقي غالبًا.
• الاستطلاع لكل شيء. كل مؤقت يعمل كل بضع ثوانٍ هو سبب يجعل قاعدة البيانات مستيقظة.
• إرسال طلبات لإبقاء التطبيق «دافئًا». هذا يلغي الوفر الذي يمنحك إياه التوسع إلى الصفر. تقبّل تأخيرًا قصيرًا عند الزيارة الأولى، أو ادفع مقابل التشغيل الدائم عن قصد.
• نسيان النشرات القديمة. التطبيقات غير المستخدمة التي تحتوي على قواعد بيانات ومهام خلفية تتراكم بصمت.
• صور غير مضغوطة. غالبًا أكبر تكلفة للنطاق الترددي في المواقع الصغيرة.

قائمة المراجعة

• أعرف أي مشروع وأي فئة (الحوسبة، قاعدة البيانات، النطاق الترددي، التخزين) تكلّف أكثر.
• لا شيء يستطلع قاعدة البيانات كل بضع ثوانٍ عندما لا ينظر إليه أحد.
• لوحات المعلومات تتحدث وفق فترة معقولة، أو فقط عندما يكون التبويب ظاهرًا.
• لا توجد مراقبة للتوفر ولا حلقة خلفية تُبقي التطبيق مستيقظًا دون سبب.
• الخادم هو أصغر حجم يعمل.
• الصور مُعدّلة الحجم ومضغوطة ومؤجَّلة التحميل؛ والملفات الثابتة مخزّنة مؤقتًا.
• التطبيقات القديمة ألغي نشرها، والملفات القديمة حُذفت، وروابط المعاينة غير المستخدمة أُزيلت.
• المواقع التي بلا بيانات أو تسجيل دخول هي مواقع ثابتة.
• واجهات الطرف الثالث المدفوعة لها تسجيل دخول وحدود لكل مستخدم وتنبيهات إنفاق لدى المزوّد.

تقليل التكاليف في Mythex

تستخدم Mythex رصيدًا واحدًا من الاعتمادات للبناء وللاستضافة، لذا فإن وفورات الاستضافة تترك مزيدًا من الاعتمادات للبناء. وبعض النقاط الخاصة بـ Mythex:

• تنام التطبيقات المنشورة وقواعد بياناتها عند الخمول، وتستيقظ عند الزيارة التالية. تنام قاعدة البيانات بعد 5 دقائق خمول، لذلك فإن إزالة الاستطلاع المستمر هي غالبًا أكبر مكسب.
• تدفع خطة Pro نصف سعر الخطة المجانية مقابل الاستضافة وقواعد البيانات والنطاق الترددي وتخزين الملفات وبيئة المعاينة؛ أما الذكاء الاصطناعي فتكلفته واحدة في الخطتين. راجع الاعتمادات.
• تصلك رسالة بريد قبل أن يؤدي رصيد منخفض إلى إيقاف تطبيق منشور، والتطبيقات المتوقفة تحتفظ بقواعد بياناتها وملفاتها.

للصورة الأوسع حول تكاليف التشغيل، راجع كم تكلّف عملية بناء تطبيق وما هي استضافة الويب.

الأسئلة