Kuidas rakendada sageli vahetuva sisu vahemäluliseks lehtmist

Kui meil on vaja kuvada palju taustal talletatud sisu, jaotame selle tükkideks ja laadime need seejärel ükshaaval korraga. See on levinud lähenemine ja selle suurepäraseks tegemiseks on mitu põhjust:

  1. See parandab kasutajakogemust. Väikese ühe lehe laadimine võtab vähem aega, nii et kasutaja saab hakata sisu kiiremini tarbima.
  2. See vähendab võrgu koormust. Üks leht on ribalaiuse osas väike ja kerge. Lisaks saame optimeerida mobiilseadmete aku ja võrgu tarbimist, kohandades ühe lehe suurust.
  3. See vähendab tagaosa koormust. Väiksemate tükkide töötlemine on kiirem kui suuremate tükkide töötlemine. Kasutajad ei vaja tavaliselt kogu sisu korraga, seega on keskmine koormus kasutaja kohta madalam.

Kõik võidavad. Enamikul juhtudel. Kuid mitte kõiki neid. Nagu geneeriliste lahenduste puhul sageli juhtub, mida domeenispetsiifilisemaks see läheb, seda parem on leitav lahendus. Selles artiklis tahan jagada huvitavat lahendust ühele sellisele juhtumile.

Ülesande määratlemine

Kujutame ette kollektsiooni, mis muutub aja jooksul sageli. Näiteks võiksime vaadata artiklite loendit, mille jaoks kasutaja keskkonnas plaksutas, või ostude rakenduse sooviloendit või teiste kasutajate üldist tegevust. Kasutajad saavad sellesse kollektsiooni lisada nii palju üksusi, kui nad soovivad.

Meie ülesanne on seda kollektsiooni mugavalt kuvada, andes samas endast parima, et vältida võrgu kuritarvitamist ning seega aku ja ribalaiuse kuritarvitamist.

Probleemid palgatsiooniga

Üks võimalus võrgukasutuse minimeerimiseks on vastuste vahemällu salvestamine. Enamik mobiili- ja veebirakendusi sõltub suuresti HTTP vahemälust. See salvestab vastused vastuse päises määratud aja jooksul. Iga kord, kui mõni rakendus esitab päringu, proovib HTTP klient vahemälust vastavat vastust saada. Ainult siis, kui see pole saadaval, helistab ta taustprogrammile.

Vahel ei toimi selline vahemälustamine pagineeritud sisu korral hästi. Kui kollektsiooni muudetakse sageli ja sisu peab olema ajakohane, pole lihtsalt mõtet vastust vahemällu salvestada. Kujutame näiteks ette järgmist stsenaariumi:

  1. Kasutaja avab artiklite loendi, mille jaoks nad plaksutasid, siin, keskmisel. Esimene leht tõmmatakse taustaprogrammist.
  2. Pärast seda otsis kasutaja midagi uut, leidis veel ühe huvitava artikli ja otsustas seda soovitada.
  3. Nüüd tahavad nad uuesti kontrollida nende soovitatud artiklite loendit.

Rakendus peab esimese lehe jaoks täitma sama päringu, kuid tulemus on erinev. Vastust ei saa vahemällu salvestada.

Kui teie domeenipõhine ülesanne võimaldab teil selle kollektsiooni üksusi ümber korraldada, on teie probleem veelgi hullem. Samal põhjusel: reageerimine muutub pidevalt.

Teine lähenemine

Vaatame lähemalt taustaprogrammist tõmmatud andmete esimest lehte. Vastus ise on üksuste loetelu kindlas järjekorras. Iga üksus tõenäoliselt ei muutu. Mis muudab elementide järjekorda ja millised üksused on selles loendis.

See tähendab, et kui saame eraldi tuua üksuse ID-de järjekorra ja üksuse üksikasjad, siis võib teine ​​kõne olla vahemällu salvestatud. Tegelikult pole isegi teise kõne vahemällu salvestamine lihtne - kuid jõuame selleni. Teeme nüüd iga üksuse jaoks eraldi taotluse:

Nagu ülaltoodud diagrammist näete, kuna üksused tõenäoliselt ei muutu, võime üksuste üksikasjade kõned vahemällu salvestada. Kahjuks korrutab selline jaotus võrgukõnede arvu suurusjärguga. Kuid selles saab midagi ära teha.

Mida me tegelikult tahame?

Kui me lihtsalt taotleme hunnikut üksust, seisame silmitsi sama probleemiga nagu üldine lehele lähenemine. HTTP vahemälu ei tööta nii, nagu me tahame, nii et kirjutagem oma, kasutades sarnast, kuid sihikindlamat loogikat.

Vahemälu ei kavatse partiisid säilitada, vaid üksikuid esemeid kindla aja jooksul. Võtame vastuse, pääseme juurde selle HTTP päistele ja hangime teavet vahemällu salvestamise aja kohta. Seejärel paneme iga üksuse eraldi vahemällu. Järgmine kord, kui peame üksusi kuvama, pääsete vahemällu salvestatud üksustele hõlpsalt juurde ja saame ülejäänud nõuda. Koodis tundub see lihtsam kui tundub:

Vaatame koodi kiiresti läbi. Meetod getOrderedItemsIds () tagastab elementide järjekorra ja on leheküljeline. Kõige olulisem osa on meetod getItemsByIds (). See on koht, kus kontrollime kõigepealt vahemälus olevaid üksusi ja taotleme seejärel ülejäänud taustaprogrammist. Pange tähele, et lihtsuse huvides on ülaltoodud kood sünkroonne ja tõenäoliselt ei kompileerita.

Pärast selle lähenemisviisi juurutamist põhjustab uue elemendi lisamine loendi päisesse uue toote üksuse ID ja detaili tellimise taotluse. Ülejäänud osa tuleb vahemälust.

Sarnane paar kõnet toimub ka igal järjestikusel lehel. Peamine idee on see, et saaksime vahemälust enamiku üksuste üksikasju. Kuid kahjuks peame taotlema iga lehe üksuste ID-de tellimist.

Tee seda paremini

Üksuse ID on tavaliselt väike objekt, näiteks stringi või universaalselt unikaalne identifikaator (UUID). Seetõttu võime saata suuremaid lehti. Tellimiskõnega tagastatavate üksuse ID-de arvu suurendamine vähendab kõnede arvu ilma võrgu ribalaiust kuritarvitamata.

Näiteks 20–40 üksuse ID taotlemise asemel võime taotleda 100–200. Hiljem saab kasutajaliidese kiht modelleerida kuvatavate üksuste üksikasjade arvu ja neid vastavalt taotleda. Siis näeb kõnede jada välja umbes selline:

  1. Taotlege esimest 100 üksuse ID-d ja hoidke neid mälus.
  2. Küsige esimese 20 üksuse üksikasju (salvestage need muidugi vahemällu) ja kuvage need kasutajale.
  3. Pärast seda, kui kasutaja on kerinud läbi esimesed 20 eset, taotlege teist partiid, milles on 20 eset.
  4. Korrake eelmist toimingut veel kolm korda ja toimige sarnaselt üksuste ID järgmisele lehele.

Uue üksuse lisamisel ülaosale on endiselt kaks taotlust (üks ID-de ja teine ​​selle uue üksuse üksikasjade saamiseks). Kuid me ei pea mõnda aega järgmist lehte taotlema, kuna need lehed on suuremad. Samuti ei pea me üksuste üksikasju nõudma, kuna need on vahemällu salvestatud!

Väike lahtiütlemine: viis, kuidas kasutajaliides üksuse üksikasjade nõudmist modereerib, võib olla huvitavam. Näiteks võib see mõne üksuse taotlused vahele jätta, kui kasutaja kerib liiga kiiresti, kuna nad pole neist huvitatud. Kuid see väärib täiesti teist artiklit.

Järeldus

Üldisi lahendusi tavaliselt konkreetseteks juhtumiteks ei optimeerita. Spetsiifika tundmine aitab meil kiiremini ja optimeeritumaid rakendusi kirjutada. Sel juhul oli oluline teadmine, et sisu muutub sageli ja et see on ID-dega esemete kogum. Vaatame üle kõik uue lähenemisega kaasnenud parandused:

  1. Üksuste tellimise eraldi taotlemine võimaldab meil vahemällu salvestada üksikasju, isegi kui pidime kirjutama muudetud HTTP vahemälu.
  2. Üksuse üksikasjade vahemällu salvestamine vähendab ribalaiuse kasutamist.
  3. Suurenenud tellimustaotluse lehtede maht vähendab kõnede arvu.

Viimane asi: optimeerimine on fantastiline ja mul oli põnev kirjutada tõhusat koodi, kuid ärge unustage seda esmalt profiilile panna. Enneaegne optimeerimine võib põhjustada probleeme ja me kõik peaksime seda vältima.

Täname, et leidsite selle artikli lugemise eest aega. Kui teile meeldib, ärge unustage klõpsata allpool asuvat .