Aplicația ta creată cu IA tocmai a fost remarcată. Va rezista valului de trafic?
Cineva ți-a distribuit aplicația și o mie de oameni au apărut deodată. Iată cum să-ți ajuți aplicația creată cu IA să reziste unui val de trafic fără să o reconstruiești noaptea dinainte să conteze.
Imaginează-ți versiunea bună a unei zile proaste. Ți-ai postat aplicația creată cu IA într-o comunitate din care faci parte, sau cineva cu mulți urmăritori a încercat-o și a distribuit-o, sau a ajuns pe prima pagină a unui forum unde nici măcar nu o trimiseseși. Dintr-odată, firicelul de vizitatori cu care erai obișnuit devine un potop. O mie de oameni, toți dând clic prin aplicație în aceeași oră.
Acesta e momentul pentru care ai construit totul. E și momentul în care multe aplicații create cu IA cedează în liniște — pagini lente, încărcări care se învârt la nesfârșit, un formular de înscriere care nu vrea să se trimită. Oamenii care în sfârșit au apărut se lovesc de un zid și pleacă, iar cei mai mulți nu se mai întorc niciodată să încerce din nou.
Vestea bună: să reziști unui val de trafic ține mai ales de o mână de decizii plictisitoare pe care le poți lua înainte să se întâmple valul. Nu trebuie să fii inginer. Trebuie să știi ce colțuri să nu tai.
Ce se strică de fapt când traficul crește brusc
Când de o sută de ori mai mulți oameni decât de obicei îți folosesc aplicația în același timp, lucrurile nu se strică la întâmplare. Se strică într-o ordine previzibilă și aproape mereu în aceleași trei locuri.
Baza de date se sufocă. De fiecare dată când cineva încarcă o pagină, aplicația ta îi pune de obicei o întrebare bazei de date: „care sunt datele acestui utilizator?”. Un singur om care întreabă nu înseamnă nimic. O mie de oameni care pun aceeași întrebare în același minut se pot îngrămădi mai repede decât poate baza de date să răspundă, iar pagina tuturor încetinește până la oprire.
Ceva din afara aplicației tale devine lent. Majoritatea aplicațiilor create cu IA se sprijină pe alte servicii — trimiterea de e-mailuri, procesarea plăților, apelarea unui model de IA. Aceste servicii limitează adesea cât de repede le poți apela. La trafic normal nu observi niciodată limita. La un val, aplicația ta o atinge și, dintr-odată, fiecare acțiune care atinge serviciul respectiv se blochează.
Aplicația face aceeași muncă costisitoare iar și iar. Dacă pagina ta principală rulează un calcul greoi de fiecare dată când cineva o vizitează — aduce o listă, o clasifică, o formatează — e în regulă pentru zece vizitatori și brutal pentru o mie. Munca a fost mereu o risipă. Traficul scăzut doar o ascundea.
Observă tiparul: niciuna dintre acestea nu e o eroare nouă. Valul nu a stricat nimic. A scos la iveală slăbiciuni care erau deja acolo, stând în liniște la trafic scăzut.
Cea mai ieftină soluție: pune în cache lucrurile care nu se schimbă
Caching-ul sună tehnic, dar ideea e simplă: dacă răspunsul la o întrebare e același pentru toată lumea și se schimbă rar, calculează-l o dată și refolosește-l, în loc să refaci munca pentru fiecare vizitator.
Pagina ta principală arată probabil identic pentru toți cei 1.000 de oameni care o accesează. Așa că de ce să ceri bazei de date să o reconstruiască de 1.000 de ori? Construiește-o o dată, salvează rezultatul câteva minute și servește copia salvată tuturor. Tocmai ai transformat o mie de drumuri costisitoare la baza de date într-unul singur.
Spune-i creatorului tău cu IA exact asta: „Pune în cache pagina principală și lista publică de produse timp de cinci minute, ca să nu accesăm baza de date la fiecare vizită”. Orice e la fel pentru toată lumea și nu trebuie să fie actualizat la secundă — o pagină de prețuri, o listă publică, un index de blog — e un candidat pentru cache. Lucrurile personalizate (panoul propriu al cuiva, setările contului său) nu pot fi puse în cache la fel, dar de obicei reprezintă o felie mică din trafic în timpul unui val. Cei mai mulți oameni se uită la aceleași câteva pagini publice.
Nu pune oamenii să aștepte după lucruri care se pot întâmpla mai târziu
Iată o greșeală ușor de făcut și ușor de reparat. Să zicem că cineva se înscrie, iar aplicația ta îi trimite un e-mail de bun venit. Dacă aplicația îl pune să aștepte pe pagina de înscriere până când e trimis complet e-mailul, atunci un serviciu de e-mail lent îți face înscrierea lentă — exact în momentul în care se înscriu cei mai mulți oameni.
Soluția e să lași lucrurile lente să se întâmple în fundal. Persoana vede instantaneu „Ai intrat!”, iar e-mailul pleacă câteva secunde mai târziu, fără ca nimeni să-l aștepte. Același rezultat, dar vizitatorul nu se holbează la o rotiță în timp ce un server de e-mail aflat la trei companii distanță își ia tihna.
Cere-i creatorului tău: „Trimite e-mailul de bun venit în fundal, ca înscrierea să nu-l aștepte”. Aceeași logică se aplică oricărui lucru care nu trebuie terminat înainte ca persoana să poată merge mai departe — generarea unui raport, sincronizarea cu un alt instrument, trimiterea unei notificări. Dacă utilizatorul nu are nevoie de rezultat chiar acum, nu-l pune să-l aștepte.
Ai un plan pentru „prea mulți oameni”
Uneori valul e mai mare decât orice ai pregătit, iar mișcarea sinceră e să te degradezi elegant în loc să te prăbușești. O aplicație lentă care tot funcționează e mai bună decât una stricată.
Câteva versiuni simple ale acestei idei:
- Un mesaj prietenos de așteptare. Dacă ceva e cu adevărat supraîncărcat, să afișezi „Avem foarte mulți vizitatori chiar acum — mai dă-i o clipă” e mult mai bine decât un ecran gol sau o eroare brută. Oamenii iartă o aplicație ocupată. Nu iartă una stricată.
- Oprește temporar cea mai grea funcție. Dacă o anumită funcție e cea costisitoare — să zicem, o generare cu IA care costă bani și timp reali la fiecare clic — o poți ascunde în timpul unui vârf și păstra restul aplicației rapid. Oricum, cei mai mulți vizitatori în timpul unui val răsfoiesc, nu folosesc cea mai pretențioasă funcție.
- Știi de unde vine factura ta. Dacă aplicația ta apelează un model de IA cu plată la fiecare vizită, o mie de vizitatori pot însemna o factură-surpriză, nu doar o pagină lentă. Dacă știi ce acțiuni costă bani, poți decide din timp ce să plafonezi.
O repetiție generală de treizeci de minute
Nu ai nevoie de instrumente sofisticate ca să-ți găsești punctele slabe. Ai nevoie de câțiva prieteni și de o jumătate de oră.
Roagă cinci sau șase oameni să-ți deschidă aplicația în același moment și să dea clic intens prin ea câteva minute — să se înscrie, să folosească funcția principală, să încarce paginile aglomerate. E grosolan, dar scoate la suprafață lucrurile evidente rapid. Dacă aplicația deja se simte greoaie cu șase oameni care o bombardează, o mie o vor face una cu pământul. Dacă rămâne sprintenă, ai trecut măcar ștacheta minimă.
Cât timp dau ei clic, urmărește ce pagină se simte cea mai lentă. Acea pagină lentă e exact locul unde un val real de trafic va lovi cel mai tare și e primul lucru pe care merită să-l pui în cache sau să-l simplifici. Nu încerci să simulezi o mie de utilizatori. Încerci să găsești singura pagină care deja se chinuie la șase.
Scopul real
Nu poți face aplicația infinit de rezistentă și nici nu e nevoie. Scopul nu e să gestionezi impecabil zece mii de oameni la primul tău moment viral. E să nu te faci de râs în fața celor câteva sute care în sfârșit au apărut — să te asiguri că oamenii pe care ai muncit atât de mult să-i atragi primesc o aplicație care funcționează, nu o roată care se învârte.
Pune în cache paginile care nu se schimbă. Mută lucrurile lente în fundal. Ai un plan pentru „prea mulți oameni”. Fă o repetiție generală cu cinci prieteni înainte să ai nevoie de ea. Nimic din toate astea nu cere să scrii cod tu însuți — doar să știi ce să-i ceri creatorului tău cu IA.
Apoi, când îți vine momentul, poți să te bucuri de el în loc să-l depanezi frenetic. Așa că iată întrebarea cu care merită să stai în această săptămână: dacă o mie de oameni ar apărea mâine, ce pagină ar ceda prima — și știi deja care e?