Како да ги намалите трошоците за хостинг на вашата апликација

За да ги намалите трошоците за хостинг, најдете што навистина работи и зошто, па оставете сè да спие кога никој не го користи. Кај хостовите што скалираат до нула, неактивната апликација и спиечката база чинат многу малку, па најголемите заштеди обично доаѓаат од отстранување на она што ги држи будни — најчесто код што ја проверува базата на секои неколку секунди — а потоа од намалување на преносот и бришење на апликации што никој не ги користи.

Веќето мали апликации немаат проблем со сообраќај. Имаат проблем „нешто секогаш е вклучено“. Овој водич покажува како да го најдете и поправите, со упатства што можете да им ги дадете на AI градител на апликации.

За што всушност плаќате

Сметките за хостинг на мали апликации доаѓаат од неколку работи. Ако знаете која е голема, знаете каде да гледате.

Многу современи хостови, вклучително и Mythex, скалираат до нула: кога никој не ја користи апликацијата, серверот запира и не чини ништо за компјутерот, па се буди при следната посета. Тоа го менува прашањето од „колку е голем мојот сервер?“ во „зошто мојот сервер е буден?“.

Чекор 1: Погледнете каде одат парите

Пред да менувате нешто, отворете ја страницата за користење на вашиот хостинг и најдете:

• Кој проект чини најмногу. Често една апликација е најголемиот дел од сметката.
• Која категорија — компјутер, база, пренос или складирање.
• Кога троши. Рамна линија преку ноќта, кога немате корисници, е траг дека нешто ја држи апликацијата будна.

Кај Mythex, деталите за користење ги прикажуваат последните 30 дена поделени на Build (AI агентот) и Run (хостинг, пренос, база и складирање датотеки), со преглед по проект.

Чекор 2: Оставете неактивните апликации и бази да спијат

Ова е вистинската полуга за повеќето мали апликации. База што спие кога е неактивна и се буди при следното барање чини скоро ништо во тивките часови. База што се прашува на секои неколку секунди никогаш не е неактивна, па плаќате за неа цел ден.

Во ограничувањата за хостинг на Mythex е објаснето како функционира тоа за објавените апликации: спиечката апликација не троши ништо за компјутерот, а базата почнува во најмала големина, расте додека е зафатена, спие по 5 минути неактивност и се наплаќа според својата големина помножена со времето кога била будна. Значи, апликација што ја прашува својата база дури и еднаш на неколку минути, дење и ноќе, се наплаќа како да е секогаш зафатена — додека истата апликација без позадинска комуникација чини многу малку.

Вообичаени работи што држат апликација будна:

• Прашување (polling). Страница што го прашува серверот „има ли нешто ново?“ на секои 2–5 секунди. Ако таб со тоа остане отворен на еден лаптоп, базата никогаш не спие.
• Автоматски освежувачки табла што ги вчитуваат податоците на тајмер, дури и кога никој не гледа.
• Мониторинг за работно време што ја пингува апликацијата на секоја минута.
• Позадински јамки во серверскиот код — setInterval што засекогаш чисти или синхронизира податоци.
• Закажани барања „keep-alive“ што некој ги додал за да се избегне бавна прва посета — тие функционираат така што го спречуваат спиењето, а токму тоа чини пари.

Прашајте го AI да ги најде:

Прегледајте го кодот и најдете сè што работи на тајмер или постојано ја пребарува базата на податоци: прашување, setInterval, автоматско освежување, позадински јамки. Наведете секоја, колку често работи и дали работи кога никој нема отворено страница. Засега не менувајте ништо.

Потоа поправете ги една по една:

Таблата ги прашува /api/orders на секои 3 секунди. Променете ја така да се освежува само додека табот во прелистувачот е видлив, и на секои 60 секунди наместо на 3. Додајте копче за рачно Освежи.

Ако вашата апликација навистина има потреба од ажурирања во живо (разговор, жива табла со резултати), прашајте дали може да испраќа ажурирања само кога нешто ќе се промени, наместо постојано да прашува. Кај многу апликации, „освежи кога корисникот ќе се врати на табот“ е доволно.

Чекор 3: Прилагодете ја големината на серверот

Поголемите машини чинат повеќе по час. Многу апликации направени со AI почнуваат со стандардна големина што е соодветна; проблемите доаѓаат кога се бара „повеќе моќ“ за да се поправи бавност што всушност е бавен упит.

• Задржете ја најмалата големина што ги опслужува вашите посетители без грешки.
• Ако видите паѓања поради меморија, прво прашајте го AI дали апликацијата вчитува премногу во меморијата (цела табела наместо една страница резултати).
• Додавајте машини само ако имате измерен сообраќај што ги бара.

Кај Mythex, големината на машината се избира при објавувањето според потребите на апликацијата, а дополнителни машини се стартуваат само кога сообраќајот е голем и повторно заспиваат кога ќе опадне. Трошокот следи големина, па побарајте во чатот помала големина ако мислите дека е преголема.

Чекор 4: Намалете го преносот

Преносот е она што го преземаат посетителите. Сликите обично се најголемиот дел.

• Компресирајте слики и служете современи формати како WebP или AVIF.
• Променете ја големината на сликите на онаа при која се прикажуваат. Фотографија од 4.000 пиксели прикажана како минијатура од 400 пиксели троши најголем дел од преземеното.
• Лениво вчитувајте слики под првиот екран.
• Кеширајте статични датотеки (скрипти, стилови, слики) за враќачките посетители да не ги преземаат повторно. Видете што е кеширање.
• Не дозволувајте апликацијата да испраќа големи датотеки при секое прегледување на страница.

Проверете ја секоја слика во апликацијата. Променете ја големината на најголемата при која се прикажува, конвертирајте ја во WebP и лениво вчитувајте сè под првиот екран. Кажете ми вкупната големина пред и по.

Побрзите страници и помалиот пренос обично одат заедно — видете како да ја направите вашата веб-страница побрза.

Чекор 5: Расчистете што никој не го користи

• Отпубликувајте стари апликации — тест-распоредувања, завршени експерименти, страница за минатогодишен настан.
• Избришете стари прикачувања, логови и извози што не ви требаат.
• Избришете споделени линкови за преглед што повеќе не ги користите. Кај Mythex, отворањето линк за преглед ја буди единицата и се наплаќа од вашите кредити, па заборавен линк што некој постојано го отвора сè уште чини.
• Отстранете неискористени услуги — API сервер или worker што апликацијата веќе не го повикува.

Чекор 6: Размислете за статичка страница

Ако вашата страница нема најави, нема зачувани податоци на корисници и нема серверска логика — маркетиншка страница, портфолио, мени — може да биде статичка страница: обични датотеки што се служат од CDN. Нема сервер или база што треба да работи. Кај Mythex, статичките страници не трошат кредити додека стојат.

Оваа страница нема најави или зачувани податоци. Дали може да се изгради повторно како статичка страница без сервер? Што би изгубиле?

Чекор 7: Пазете на платените API повици

За апликации што повикуваат AI модели, мапи или SMS, сметките на трети страни можат да ја надминат сметката за хостинг.

• Барајте најава за сè што чини пари по повик.
• Додајте лимит по корисник (видете што е ограничување на барања).
• Кеширајте одговори што не се менуваат, како геокодирање на истата адреса.
• Поставете ограничувања на потрошувачката или известувања кај секој провајдер.

Чести грешки

• Погодување наместо мерење. Прво проверете го прегледот на користење; скапиот дел често не е она што го очекувате.
• Купување поголем сервер за да се поправи бавноста. Недостасувачки индекс во базата или вчитување на премногу податоци обично е вистинската причина.
• Прашување за сè. Секој тајмер на неколку секунди е причина базата да остане будна.
• Пингување на апликацијата за да остане „топла“. Тоа го прекинува заштедата што ја дава скалирањето до нула. Прифатете кратко будење при првата посета или платете за постојана работа намерно.
• Заборавање стари распоредувања. Неискористените апликации со бази и позадински задачи тивко се собираат.
• Некомпресирани слики. Често е најголемиот единечен трошок за пренос кај мали страници.

Листа за проверка

• Знам кој проект и која категорија (компјутер, база, пренос, складирање) чини најмногу.
• Ништо не ја прашува базата на секои неколку секунди кога никој не гледа.
• Таблите се освежуваат на разумен интервал или само додека табот е видлив.
• Ниту еден мониторинг за работно време или позадинска јамка не ја држи апликацијата будна без причина.
• Серверот е најмалата големина што функционира.
• Сликите се променети по големина, компресирани и лениво вчитувани; статичките датотеки се кеширани.
• Стари апликации се отпубликувани, стари датотеки избришани, неискористени линкови за преглед отстранети.
• Страниците без податоци или најави се статички.
• Платените API имаат најава, лимити по корисник и известувања за потрошувачката кај провајдерот.

Намалување на трошоците на Mythex

Mythex користи еден баланс на кредити и за градење и за хостинг, па заштедите на хостингот оставаат повеќе кредити за градење. Неколку точки специфични за Mythex:

• Објавените апликации и нивните бази спијат кога се неактивни и се будат при следната посета. Базата спие по 5 минути неактивност, па отстранувањето на постојаното прашување обично е најголемата добивка.
• Pro плаќа половина од Free цената за хостинг, бази, пренос, складирање датотеки и sandbox за преглед; AI чини исто на двата плана. Видете Credits.
• Добивате е-пошта пред баланс толку низок да ја паузира објавената апликација, а паузираните апликации ги задржуваат своите бази и датотеки.

За поширока слика за трошоците на работење, видете колку чини изградба на апликација и што е веб-хостинг.

Прашања