Prečo vaša AI-postavená appka spadne so 100 reálnych používateľov

Vaša AI-postavená aplikácia funguje perfektne. Testovali ste ju. Kamaráti ju testovali. Desať beta používateľov ju testovalo. Všetko je v poriadku.

Potom spustíte na Product Hunt. Sto používateľov príde naraz. Aplikácia sa spomalí na minimum, začne hádzať 500 chyby a potom kompletne spadne. Reštartujete server, vráti sa na 20 minút, potom spadne znova.

Toto nie je hypotetické. Toto je najčastejší spôsob zlyhania AI-generovaných aplikácií. A príčina je vždy rovnaká: kód bol písaný pre demo škálovanie, nie pre produkčné škálovanie.

Tu je päť výkonnostných zabijakov, ktoré sa skrývajú takmer v každej vibe-coded aplikácii.

1. N+1 dotazy požierajú vašu databázu

Toto je absolútne najčastejší výkonnostný problém v AI-generovanom kóde. A zároveň najnebezpečnejší, pretože pri malom počte používateľov je neviditeľný.

Tu je čo sa deje: máte stránku, ktorá zobrazuje zoznam 20 položiek. Každá položka má priradeného používateľa. AI-generovaný kód načíta zoznam jedným dotazom, potom načíta každého používateľa separátnym dotazom. To je 21 databázových dotazov na jedno načítanie stránky.

Pri 10 položkách si to nevšimnete. Pri 100 položkách a 50 súčasných používateľoch je to 5 000 databázových dotazov súčasne. Váš connection pool sa vyčerpá, dotazy sa zaradia do fronty, časy odpovede vyletia a aplikácia sa zloží.

Riešenie: Eager loading. Jeden dotaz na položky, jeden dotaz na všetkých súvisiacich používateľov. Dva dotazy namiesto 101. Každý ORM toto podporuje — Prisma používa include, SQLAlchemy joinedload, Eloquent with. AI sa s tým jednoducho neobťažuje.

// Zle: N+1 (čo generuje AI)
const posts = await db.post.findMany()
for (const post of posts) {
  post.author = await db.user.findUnique({ where: { id: post.authorId } })
}

// Dobre: Eager loading (čo potrebuje produkcia)
const posts = await db.post.findMany({
  include: { author: true }
})

2. Nulové cachovanie, všade

AI-generované aplikácie zaobchádzajú s každým requestom, akoby bol prvý. Žiadne cachovacie hlavičky. Žiadna Redis vrstva. Žiadne CDN. Žiadna memoizácia. Každé načítanie stránky udriem do databázy, prepočíta všetko a servíruje čerstvé dáta, aj keď sa nič nezmenilo.

Pre landing page, ktorá sa aktualizuje raz za týždeň, vaša databáza obsluhuje identické dotazy tisíckrát denne. Pre API, ktoré vracia používateľské nastavenia, bijete do databázy pri každom jednom requeste, keď sa dáta menia raz za mesiac.

Riešenie je viacúrovňové:

• HTTP cachovacie hlavičky — povedzte prehliadačom a CDN aby cachovali statický a polostatický obsah
• Cachovanie na úrovni aplikácie — Redis alebo in-memory cache pre často pristupované dáta
• CDN pre statické assety — obrázky, CSS a JS by nikdy nemali trafiť váš origin server po prvom requeste
• Cachovanie výsledkov dotazov — cachujte drahé databázové dotazy na rozumný TTL

Nemusíte cachovať všetko. Začnite s endpointmi, ktoré sú najvyužívanejšie, a dotazmi, ktoré sú najpomalšie.

3. Žiadny connection pooling

Zakaždým, keď vaša aplikácia potrebuje komunikovať s databázou, otvorí nové spojenie. Vytvorenie spojenia trvá 20-50ms. Pre stránku s 5 databázovými volaniami je to 100-250ms čistej réžie pred akoukoľvek skutočnou prácou.

Ale skutočný problém sú limity. Väčšina managed databáz obmedzuje spojenia na 20-100. Bez poolingu môže 50 súčasných používateľov okamžite vyčerpať váš limit spojení. Nové requesty zlyhajú. Aplikácia spadne.

AI nástroje nekonfigurujú connection pooling, pretože nemyslia na súčasných používateľov. Testujú s jedným používateľom, ktorý robí jeden request naraz.

Riešenie: Nakonfigurujte connection pool. Väčšina ORM to podporuje natívne. Pre serverless prostredia použite externý pooler ako PgBouncer alebo Prisma Accelerate. Nastavte veľkosť poolu tak, aby zodpovedala limitu spojení vašej databázy mínus nejaká rezerva.

4. Synchrónne všetko

AI-generovaný kód robí všetko inline, v request cykle. Poslať uvítací email? Urobiť to pred odpoveďou používateľovi. Vygenerovať PDF report? Nech používateľ čaká. Spracovať webhook? Blokovať kým to nie je hotové.

Výsledok: časy odozvy 3-10 sekúnd pre operácie, ktoré by mali vrátiť odpoveď za 200ms. Používatelia vidia spinnery. Timeouty sa hromadia. Fronta requestov sa upchá. Serveru dôjde pamäť, pretože drží otvorené desiatky dlho bežiacich requestov súčasne.

Riešenie: Presuňte pomalé operácie do background jobov.

• Posielanie emailov — zaraďte do fronty, okamžite odpovedzte
• Spracovanie súborov — prijmite upload, spracujte asynchrónne, notifikujte keď je hotové
• Spracovanie webhookov — potvrďte príjem (200 OK), spracujte na pozadí
• Generovanie reportov — spustite job, nechajte používateľa pollovať alebo pošlite notifikáciu

Nástroje ako BullMQ (Node.js), Celery (Python) alebo dokonca jednoduchá fronta jobov založená na databáze toto vyriešia. Používateľ dostane rýchlu odpoveď, práca prebieha na pozadí, všetci sú spokojní.

5. Žiadne error boundaries ani graceful degradation

Keď sa jedna vec pokazí v AI-postavenej aplikácii, pokazí sa všetko. Neúspešné API volanie zničí celú stránku. Pomalý servis tretej strany spomalí celú vašu aplikáciu. Výpadok databázy zničí funkcie, ktoré databázu ani nepotrebujú.

Neexistuje žiadny circuit breaker pattern. Žiadny timeout na externé API volania. Žiadne náhradné UI pre zlyhané komponenty. Žiadna retry logika s exponenciálnym backoffom. Aplikácia je krehká, pretože bola postavená s predpokladom, že všetko vždy funguje.

Riešenie:

• Error boundaries v Reacte — zachyťte chyby komponentov bez pádu celej stránky
• Timeouty na všetky externé volania — nikdy nečakajte nekonečne na API tretej strany
• Circuit breakery — ak servis zlyháva, prestaňte ho volať na chvíľu namiesto toho, aby ste ho bombardovali
• Graceful degradation — ak je odporúčací engine mimo prevádzky, ukážte predvolený obsah namiesto prázdnej stránky
• Retry s backoffom — prechodné zlyhania by sa mali automaticky opakovať, nie okamžite spadnúť

Skutočný problém

Žiadny z týchto problémov nie je viditeľný počas vývoja. Objavia sa len pod záťažou, s reálnymi používateľmi, v najhorší možný čas — zvyčajne počas vášho launchu.

AI nástroje optimalizujú na to, aby niečo fungovalo. Produkčné inžinierstvo optimalizuje na to, aby to fungovalo pod stresom. To sú fundamentálne odlišné disciplíny a žiadne množstvo promptovania neprinúti AI nástroj rozmýšľať nad connection poolingom alebo cache invalidáciou.

Čo s tým

Máte tri možnosti:

1. Čakať až to spadne a opravovať reaktívne. Najlacnejšie na začiatku, najdrahšie na stratených používateľoch a reputácii.
2. Záťažovo testovať pred spustením. Použite nástroje ako k6 alebo Artillery na simuláciu 100+ súčasných používateľov a pozrite sa, čo sa pokazí. Opravte najhoršie problémy.
3. Nechať si spraviť audit produkčnej pripravenosti. Nechajte niekoho, kto to už robil, prezrieť váš kód a infraštruktúru.

My odporúčame možnosť 3, samozrejme. Ale aj možnosť 2 je lepšia než možnosť 1.

Objednajte si bezplatný Quick Audit — identifikujeme výkonnostné úzke hrdlá vo vašej AI-postavenej aplikácii skôr, než to urobia vaši používatelia. Pozrite si aj náš MVP do produkcie checklist pre kompletný obraz toho, čo produkčná pripravenosť znamená.