Ano ang Caching? Gabay sa Simpleng Ingles para sa App Builders

Ang caching ay pag-iimbak ng handang kopya ng isang bagay na mabagal o mahal kunin, para masagot nang mabilis ang susunod na request mula sa kopyang iyon. Tinatawag na cache ang naka-save na kopya. Nagca-cache ang browser mo ng mga larawan para mas mabilis mag-load ang isang site sa pangalawang bisita mo; nagca-cache naman ang server ng resulta ng mabagal na database query para hindi ito patakbuhin para sa bawat bisita.

Pinapabilis at pinapamura ng caching ang pagpapatakbo ng mga app. Ang pangunahing kapalit nito ay maaaring maging luma ang kopya.

Bakit mahalaga ang caching kapag gumagawa ka gamit ang AI

Makakasalubong mo ang caching sa mga app na gawa ng AI sa tatlong paraan:

• “Na-update ko na ang app pero lumang bersyon pa rin ang nakikita ko.” Ito ang pinakakaraniwang sitwasyon sa caching, at kadalasang hindi nakakapinsala. Ipinapakita lang ng browser o CDN ang naka-save na kopya.
• Bilis. Kung mabagal ang isang pahina dahil inuulit nito ang parehong kalkulasyon para sa bawat bisita, ang pag-cache ng resulta ay maaaring magpaparamdam dito na agad-agad.
• Gastos. Maraming AI builder at host ang naniningil para sa compute, oras ng database at panlabas na API calls. Kung libu-libong bisita ang nagti-trigger ng parehong mahal na request, hinahayaan ka ng caching na magbayad nang isang beses lang.

Kapag alam mo ang batayan, mahihiling mo ang caching kung saan ito makakatulong, at makikilala mo ito kapag ito ang dahilan ng kakaibang itsura ng isang bagay.

Isang halimbawang pang-araw-araw

Isipin ang kusina ng isang abalang café.

Kada umaga, puwedeng i-brew ng barista ang bawat kape mula sa sariwang giniling na beans kapag may nag-order. Mabagal iyon. Kaya naghahanda sila ng isang tabong filter coffee sa hot plate. Karamihan ng customer ay makakakuha ng kape sa loob ng ilang segundo. Iyon ang cache hit. Kapag naubos ang tabo, may magti-timpla ng bago. Iyon ang cache miss.

Pero nagiging lipas ang kape kapag matagal nang nakatayo, kaya may patakaran ang café: itapon ang anumang tabong mahigit 30 minuto na. Iyon ang expiry time ng cache. Walang magtatagal ng iisang tabo buong araw, at hindi rin pre-brew ang custom na order ng may gatas na oat at tatlong asukal. May mga bagay na hindi dapat i-cache talaga.

Saan nakatira ang mga cache

Maaaring dumaan ang isang page load sa ilang cache, mula sa pinakamalapit sa user hanggang sa pinakamalayo:

Ang CDN (content delivery network) ay sa esensya isang pandaigdigang network ng caches para sa mga file ng site mo.

Paano nagpapasya ang cache kung ano ang itatago

Kailangang sagutin ng bawat cache ang parehong mga tanong:

• Ano ang puwedeng i-cache? Pampubliko at shared na data (larawan ng produkto, blog post): oo. Pribadong data (pahina ng account ng user, mga mensahe niya): hindi kailanman sa shared cache.
• Gaano katagal? Ito ang TTL (time to live). Puwedeng i-cache ng isang taon ang logo; 30 segundo lang ang stock level.
• Paano ito ina-update? Alinman sa mag-e-expire ang kopya at kukunin ulit, o sinasadyang tatanggalin ng app ang kopya kapag nagbago ang data. Tinatawag itong invalidation.

Para sa mga website, sinasabi ng server sa browser at CDN kung paano i-cache ang bawat file gamit ang Cache-Control header. Halimbawa, ang Cache-Control: max-age=3600 ay nangangahulugang “puwede mong gamitin muli ang kopyang ito sa loob ng isang oras.”

Ang mga modernong build tool ang humahawak sa pinakamahirap na bahagi para sa static files gamit ang cache busting: sa bawat pagbabago ng file, binibigyan ito ng bagong pangalan na may fingerprint, gaya ng app.3f9a2c.js. Puwedeng i-cache nang matagal ng browser ang lumang pangalan, dahil magkaiba lang ang pangalan ng bagong bersyon.

Isang halimbawang gawa: katalogo ng produkto

May maliit kang online shop. Ipinapakita ng home page ang 50 produkto na may presyo at stock mula sa database, kasama ang listahan ng “trending” na nangangailangan ng mabagal na kalkulasyon sa lahat ng order.

1. Mga larawan at scripts ay naka-cache ng browser at CDN nang matagal. Binibigyan ng bagong pangalan ng bawat build ang mga nagbagong file, kaya lumalabas pa rin ang mga update.
2. Ang listahan ng trending ay kinakalkula kada 10 minuto at naka-store sa application cache. Bawat bisita sa loob ng 10 minutong iyon ay agad na nakakakuha ng naka-save na resulta.
3. Mga presyo ay naka-cache nang maikling panahon, at nililinis ang cache tuwing ie-edit mo ang isang produkto, para hindi makakita ng lumang presyo ang customer nang matagal.
4. Stock sa checkout ay hindi kailanman naka-cache. Kapag pinindot ng isang tao ang “Buy,” tinitingnan ng app ang totoong database, kaya hindi ito makakapagbenta ng item na kaka-ubos lang.
5. Ang cart at account pages ay hindi kailanman itinatago sa shared caches, dahil personal ang mga ito.

Resulta: mabilis ang home page, mas kaunti ang trabaho ng database, at walang stale na bagay na mahalaga para sa pera o privacy.

Mahahalagang termino

Mga karaniwang maling akala

• “Laging maganda ang caching.” Ang pag-cache ng maling bagay ay nagdudulot ng totoong bug: lumang presyo, hindi lumalabas na bagong post, o, ang pinakamasama, pribadong pahina ng isang user na ipinapakita sa iba. Mag-cache nang sinasadya.
• “Kapag lumang bersyon ang nakikita ko, nabigo ang update ko.” Kadalasan, hindi. Subukan muna ang hard refresh (Ctrl+Shift+R, o Cmd+Shift+R sa Mac) o private window bago ipagpalagay na may sira.
• “Inaayos ng caching ang mabagal na app.” Tinatakpan lang nito ang bagal para sa paulit-ulit na request. Mabagal pa rin ang unang request, at kung ang tunay na problema ay kulang na database index, ayusin din iyon.
• “Dapat i-cache ang lahat hangga’t maaari.” Angkop ang mahabang cache time sa mga file na binibigyan ng bagong pangalan kapag nagbago. Para sa HTML pages at data, mas ligtas ang mas maiikling panahon.
• “Kapag nilinis ko ang cache ko, maaayos na para sa lahat.” Sarili mo lang na browser ang nalilinis. Mayroon pa ring sariling kopya ang mga bisita at CDN caches.

Ano ang itatanong sa AI builder mo

• “Aling bahagi ng app na ito ang mabagal, at alin ang puwedeng i-cache nang ligtas?”
• “I-cache ang [trending list / API result] nang [N] minuto, at burahin ito kapag nagbago ang pinagbabatayang data.”
• “Siguraduhing walang pahinang may personal o account data ang puwedeng i-cache ng CDN o shared cache.”
• “Magtakda ng mahabang cache time para sa fingerprinted static files at maikli para sa HTML.”
• “I-cache ang sagot mula sa [panlabas na API] para hindi ito tawagin sa bawat pag-load ng pahina, at sabihin mo kung gaano kaluma maaaring maging data.”
• “Nakikita ko ang lumang bersyon pagkatapos mag-publish. Cache ba ito ng browser ko, o may hindi pa na-deploy?”

Caching sa Mythex

Pagkatapos mag-publish ng update sa app ng Mythex, nabanggit sa docs na maaaring mahuli nang kaunti ang CDN caches, at ang hard refresh sa public URL ay nagpapakita ng bagong bersyon. Tingnan ang How to publish. Nirerekomenda rin ng pahinang Hosting limits ang pag-cache ng static assets, dahil binabayaran mula sa credit balance mo ang hosting, oras ng database at bandwidth. Ang lampas doon, gaya ng pag-cache ng query results o API responses, ay hinihiling mong isama ng agent sa app mo.

Kaugnay na babasahin: ano ang CDN, paano gawing mas mabilis ang website mo at ano ang rate limiting.

Mga tanong