Tafuta ombi ghali kabla ya kubadilisha hifadhidata
Anzia na kitendo cha mtumiaji: kufungua daraja la kategoria, kutafuta makala, kuongeza kwenye kisha (cart), au kuwasilisha oda. Rekodi njia yake, idadi ya maswali (queries), muda kwenye hifadhidata, mistari iliyorejeshwa, na muda wa ombi. Ukurasa polepole unaweza pia kusubiri kwa msimbo wa programu au tegemezi nyingine, kwa hivyo usitatue tatizo kwa muda wa kupakia ukurasa peke yake.
Mpango wa swali (query plan) ni njia ya hifadhidata kupitia jedwali, viindexi, joini, aina za upangaji (sorts), na aggregates. Katika PostgreSQL, EXPLAIN inaonyesha njia hiyo. EXPLAIN ANALYZE inafanya taarifa na kuripoti mistari na nyakati halisi, hivyo tumia swali salama linalowakilisha. Tofauti kubwa kati ya makadirio na halisi ya mistari ni sababu ya kuchunguza takwimu au masharti, sio ombi la kiotomatiki la kiindexi.
Unganisha swali kinachoaminika na njia na matokeo, ili ripoti ya dashibodi isitoruke juu ya ukamilifu wa malipo (checkout) polepole.
Rekodi nyakati kabla ya mabadiliko na trafiki inayofanana bila kuandika vitambulisho vya wateja, token, au thamani zinazohusiana na kadi.
Buni viindexi kwa njia ya upatikanaji unayotumia kwa kweli
Kiindexi ni muundo unaoudhireshwa unaoweza kusaidia kupata mistari au kuirejesha kwa mpangilio; si swichi ya kasi ya ulimwengu wote. Anza na vichujio (filters), funguo za joini, na mpangilio (sort order) wa swali muhimu, kisha thibitisha kiindexi kilichopendekezwa kwenye mpango. PostgreSQL inaandika kwamba kiindexi kinacholingana cha B-tree kinaweza kutosheleza ORDER BY bila sort tofauti, hasa na LIMIT ndogo.
Viindexi huongeza kuhifadhi na kazi za kuandika kwa sababu inserts, updates, na deletes vinavitunza. Kwa swali linalohitaji sehemu kubwa ya jedwali, scani ya mfululizo (sequential scan) na sort ya wazi inaweza kuwa ya haraka zaidi. Jaribu kwenye data inayofanana na uzalishaji na wacha kiindexi ikiwa faida inafaa kwa gharama yake.
Tumia vichujio vya swali vinavyotumika kwa kweli na ORDER BY, ikijumuisha tie-breaker wa kuamuliwa pale kiolesura kinapohitaji mpangilio thabiti.
Kagua kama kiindexi kinatumika na gharama yake wakati wa uandishi; angalia tena kadri data na trafiki zinavyobadilika.
Fanya upangaji ukurasa (pagination) uwe thabiti na wa gharama nafuu
Upangaji kwa nambari ya ukurasa kawaida hutumia LIMIT pamoja na OFFSET. Daima weka mpangilio unaotabirika. PostgreSQL inatambia kwamba bila ORDER BY, LIMIT inaweza kurudisha sehemu isiyotabirika; LIMIT tofauti au OFFSET inaweza kutoa seti zisizolingana kwa sababu optimizer unaweza kuchagua mipango tofauti.
Offsets kubwa zinastahili uchunguzi kwa sababu mistari inayopitishwa bado inabidi ihesabiwe. Kwa katalogi ya kina, historia ya oda, au kuvinjari maktaba, fikiria cursor au pagination ya keyset: omba mistari baada ya thamani ya mpangilio thabiti iliyojulikana na tie-breaker ya kipekee. Tafsiri jinsi rekodi mpya au zilizofutwa zinaonekana kabla ya kubadilisha kiolesura.
Rudisha ukurasa mdogo zaidi unaofaa badala ya matokeo yasiyo na kikomo.
Amua kama kiolesura kweli kinahitaji jumla kamili kwa kila ombi.
Tumia cache kwa kazi za kusoma bila kutoa jibu lisilo sahihi
Cache inarudisha matokeo ya awali badala ya kuitengeneza tena kutoka hifadhidata. Anza katika tabaka la HTTP kwa kurasa za umma, zinazorudiwa, na mali zilizo na toleo, kwa sababu hit ya cache inaweza kuepuka kazi za programu na hifadhidata. web.dev inapendekeza caching ya muda mrefu kwa URL zilizo na toleo; kubadilisha URL ni njia ya vitendo ya kufuta (invalidation).
Sera ya cache ni uamuzi wa usahihi. Cache iliyoshirikiwa inaweza kutumia jibu moja kwa watumiaji wengi, hivyo usishirikishe pato linalohusiana na akaunti, kisha, bei, au uthibitisho wa ruhusa isipokuwa limetengenezwa na kupimwa kwa upana huo. Cache-Control private inakataza matumizi kwa browser pekee, wakati no-store inaagiza caches zisizorekodi kabisa.
Tofautisha pato la katalogi ya umma au makala kutoka kwa yale yanayohusiana na vikao, eneo, na usalama wa ruhusa.
Fafanua nani anaweza kuona thamani iliyochelewa, kwa muda gani, na njia ya kufuta au kuthibitisha tena.
Linda uwezo wa muunganisho badala ya tu kuinua kikomo
Muunganisho ni kikao cha mteja kilicho hai na hifadhidata. Wafanyakazi (workers), kazi za cron, mapitio (previews), au marudio yanaweza kuchukua mashimo hata wakati maswali binafsi yanaonekana kukubalika. max_connections ya PostgreSQL inadhibiti muunganisho sambamba, imewekwa wakati wa kuanzisha server, na thamani kubwa inateua rasilimali zaidi ikiwemo shared memory. Kuiinua bila mfano wa mzigo inaweza kusonga hitilafu mahali pengine.
Weka bajeti moja kwa wafanyakazi wa wavuti, kazi za nyuma (background jobs), usimamizi, na nakala (replicas). Tumia pooling ulio na mipaka pale inafaa, hifadhi nafasi ya kupona, na tumia timeouts ili kazi zilizokatwa zisisubiri bila kikomo. Nambari salama zinategemea engine, kumbukumbu, mchanganyiko wa maswali, na vikwazo vya mtoa huduma; thibitisha nasi msimamizi (operator).
Jumlisha michakato ya wavuti, vigezo, kazi zilizopangwa, uhamishaji wa data, na kazi za uendeshaji za utoaji.
Weka kikomo cha sambamba na tumia backoff ili hitilafu isizidishwe na mahitaji ya muunganisho.
Tazama gharama ya swali kwa muktadha na udhibiti wa faragha
Panga kazi za hifadhidata kwa ufanisi wa jumla, sio sampuli moja polepole. Swali la wastani polepole linaloitwa mara elfu linaweza kuwa muhimu zaidi kuliko ripoti adimu. pg_stat_statements ya PostgreSQL inakusanya data za kupanga na utekelezaji ikiwa ni pamoja na mapigao (calls), jumla na wastani wa muda wa utekelezaji, mistari, na shughuli za buffer. Inahitaji usanidi wa server na restart kuongeza au kuondoa; ufuatiliaji wa kupanga unaweza kuongeza overhead.
Unganisha vikundi vya maswali na njia, toleo la utolewaji, na dirisha la wakati. OpenTelemetry inashauri kukusanya maandishi ya swali kitaaluma tu baada ya kusafishwa ili nafasi (literals) zibadilishwe, na kutumia muhtasari wa low-cardinality wa swali kwa ajili ya kuunganisha. Hii husaidia wamiliki kuona mwelekeo bila kuhamisha data ya wateja au kuunda lebo kwa kila thamani.
Kagua muda, jumla ya muda, mapigao, makosa, muunganisho, na mistari; kila mojawapo inaonyesha aina tofauti ya hitilafu.
Tumia maswali yaliyopangwa (parameterized queries) na thibitisha kuwa nafasi zimeondolewa kabla ya traces au log kutoka kwenye programu.
Tuma mabadiliko ya hifadhidata kama kazi za uaminifu zinazoweza kurudiwa
Chukulia kiindexi, uandishi upya, sera ya cache, usanidi wa pool, au mabadiliko ya skima kama mabadiliko ya uzalishaji yenye mwenyewe, kipimo cha mafanikio, na uamuzi wa kurudi nyuma. Thibitisha katika mazingira yanayowakilisha, toa kwa sehemu ndogo, na angalia safari iliyoshughulikiwa. Haraka sio mafanikio ikiwa mabadiliko yanarudisha data isiyo sahihi, iliyokosekana, rudufu, au yenye kuchelewa.
Mabadiliko ya skima yanahitaji uangalizi kwa sababu matoleo ya programu yanaweza kushindwa. Mwongozo wa Google Cloud unaelezea mfululizo unaokubaliana: toa toleo la programu linaloshughulikia skima ya zamani na mpya, badilisha skima, kisha toa kipengele kinachokiitumia. Hii huhifadhi njia ya kurudi kwa rollback ya programu. Kufunga na tabia ya mabadiliko ya mtandaoni hutofautiana kwa engine na huduma iliyosimamiwa; pata ukaguzi wenye sifa kwa mifumo yenye msongamano mkubwa au inayohusiana na malipo.
Taja njia, ishara za utendaji na usahihi, na kizuizi kinachosimamisha utolewaji.
Thibitisha utendaji na usahihi katika sehemu iliyodhibitiwa kabla ya kupanua; ada mazoezi ya njia ya kurudi nje ya tukio.