Էջերի քեշ Odoo-ի համար. խանութ և բլոգ RAM-ից կամ ֆայլից – արագ այցելուների, որոնողական համակարգերի և արհեստական բանականության համար

2026 թ. նոյեմբերի 10  |  Սեփական մշակում  |  Odoo, արագագործություն և որոնողական համակարգեր

Odoo կայքը յուրաքանչյուր դիմումի ժամանակ յուրաքանչյուր էջ նորից ձևավորում է՝ տվյալների բազայի հարցումներ, ձևանմուշներ, թարգմանություններ, գներ։ Մեկ այցելուի համար դա աննկատ է։ Սակայն երբ որոնողական համակարգերը և արհեստական բանականության ինդեքսավորիչները բազմաթիվ լեզուներով հարյուրավոր կամ հազարավոր էջեր են պահանջում, դա վերածվում է մշտական ծանրաբեռնվածության, և իրական հաճախորդներն էլ սպասում են։ Դրա համար մենք մշակեցինք Odoo 19-ի website_page_cache մոդուլը և GitHub-ում հրապարակեցինք որպես բաց կոդով (LGPL-3) ծրագիր։ Անանուն կերպով պահանջված խանութի և բլոգի էջերը գրեթե ստատիկ կերպով տրվում են քեշից՝ կա՛մ ֆայլերից, կա՛մ օպերատիվ հիշողությունից (RAM), և ցանկացած փոփոխություն՝ նաև թարգմանության փոփոխությունը, ավտոմատ կերպով հեռացնում է տուժած էջերը քեշից։

Կարևոր է բոլոր նրանց համար, ովքեր ուզում են գտնվել որոնումներում. մոդուլը չի արգելափակում ո՛չ մի որոնողական համակարգ և ո՛չ մի արհեստական բանականության կրաուլեր։ Բոլոր ինդեքսավորիչները ստանում են նույն բովանդակությունը, ինչ ցանկացած այցելու, պարզապես ավելի արագ։ Այս հոդվածում բացատրվում է, թե ինչպես է աշխատում քեշը, ինչպիսին է կառավարման վահանակը (էկրանի նկարներով), ինչպես պարզել, արդյոք ձեր էջերը տեղավորվում են օպերատիվ հիշողության մեջ և որքան լրացուցիչ RAM կպահանջվի, ինչ անվտանգության կանոններ են գործում և ինչպես տեղադրել մոդուլը։

Համառոտ

Խնդիրը՝ կրաուլերների ծանրաբեռնվածությունը Odoo կայքերում

Odoo-ն ամբողջական ERP համակարգ է, իսկ կայքը նրա բազմաթիվ մոդուլներից մեկն է։ Յուրաքանչյուր էջ, որ պահանջում է այցելուն կամ ռոբոտը, անցնում է նույն ճանապարհը. դիմումի մշակում, տվյալների բազայի հարցում, ապրանքների և գների տվյալների բեռնում, QWeb ձևանմուշի ձևավորում, թարգմանությունների տեղադրում և արդյունքի տրամադրում։ Էջից կախված՝ սա տևում է մի քանի հարյուր միլիվայրկյան և այդ ընթացքում զբաղեցնում է սակավաթիվ աշխատանքային պրոցեսներից մեկը։

Որոնողական համակարգերի և արհեստական բանականության ինդեքսավորիչների համար սա մշտական խնդիր է.

• Շատ լեզուներ, շատ հասցեներ. 46 լեզվով առկա մեկ էջը կրաուլերի համար 46 տարբեր հասցե է։
• Յուրաքանչյուր հասցե պահանջվում է առանձին, հաճախ բազմաթիվ բաշխված ուղարկողների կողմից միաժամանակ։ Դասական բրաուզերային քեշն այստեղ չի օգնում, քանի որ յուրաքանչյուր դիմում նոր հասցեի է վերաբերում։
• Քիչ աշխատանքային պրոցեսներ. Odoo ծառայությունը սովորաբար աշխատում է մի բուռ պրոցեսներով։ Եթե դրանք զբաղված են կրաուլերների հարցումներով, իրական այցելուները սպասում են հերթում։
• Նույն բովանդակությունը՝ նորից ու նորից. բլոգի հոդվածը հազվադեպ է փոխվում, բայց յուրաքանչյուր դիմման ժամանակ ծախսատար կերպով նորից հավաքվում է։

Ակնհայտ ելքը՝ կրաուլերներին արգելելը, այն ընկերության համար, որը ցանկանում է գտնվել, տարբերակ չէ։ Որոնողական համակարգերում և արհեստական բանականության պատասխաններում տեսանելիությունը արժեքավոր է։ Ավելի լավ է էջերն այնքան արագ տրամադրել, որ ծանրաբեռնվածությունը գրեթե նշանակություն չունենա։ Հենց դա էլ անում է էջերի քեշը։

Ինչպես է աշխատում էջերի քեշը

Մոդուլը միանում է Odoo-ի դիմումների մուտքին (ir.http)։ Յուրաքանչյուր էջի դիմման ժամանակ միլիվայրկյանի մասնիկի ընթացքում որոշում է՝ կարո՞ղ է արդյոք էջը տրվել քեշից, և եթե այո՝ տրամադրում է առանց տվյալների բազայի, առանց ձևանմուշի և առանց ձևավորման։

1. Ստուգում. դիտարկվում է միայն թույլատրված ուղու վրա (խանութ, կատեգորիաներ, ապրանքներ, բլոգ) անանուն GET դիմումը՝ առանց որոնման պարամետրերի։ Մնացած ամեն ինչ Odoo-ով անցնում է ինչպես միշտ։
2. Քեշի բանալի. այն կազմված է կայքից, հոսթի դասից, լեզվից, ուղուց, գնացուցակից, հարկային դիրքից և քուքիների համաձայնության կարգավիճակից։ Հետևաբար այցելուները, որոնք ինչ-որ այլ բան կտեսնեին, երբեք չեն կիսում նույն գրառումը։ Հոսթը նորմալացվում է. Odoo-ն բացարձակ հասցեները միշտ գրում է կայքի դոմենից, ոչ թե դիմումից. դիմման հասցեն որոշում է միայն, թե արդյոք էջը համարվում է հիմնական հասցե (լեզվական հղումներ) և պետք է արդյոք ինդեքսավորվի։ Բոլոր օտար հոսթանունները, ուստի, կիսում են մեկ գրառում՝ noindex նշումով, այլ ոչ թե յուրաքանչյուրը զբաղեցնում է սեփական պատճենը։
3. Հարված. եթե կա արդի գրառում, այն տրվում է։ Էջի CSRF թոքենը այդ ժամանակ յուրաքանչյուր դիմման համար նորից է սահմանվում։ Բլոգի հոդվածների դիմումները շարունակում են հաշվվել։
4. Վրիպում. եթե գրառումը բացակայում է կամ հնացել է, Odoo-ն էջը ձևավորում է սովորականի պես։ Եթե արդյունքը կարելի է քեշավորել (կարգավիճակ 200, HTML, առանց քուքիի, տեքստում առանց սեսիայի ID-ի), այն պահվում է. հաջորդ դիմումը հարված կլինի։
5. Տեսանելի է վերնագրում. յուրաքանչյուր պատասխան կրում է X-Page-Cache: HIT կամ MISS վերնագիրը։ Այսպես ցանկացած գործիքով կարելի է ստուգել, թե ինչ է տեղի ունեցել։

Որքանո՞վ է ավելի արագ

Մեր փորձարկման համակարգում (մեր կայքերի պատճենը, մի քանի հարյուր էջ) մեկ էջի ձևավորման միջին ժամանակը մոտ 490 միլիվայրկյան էր, իսկ քեշից տրամադրումը՝ մոտ 23 միլիվայրկյան. մոտավորապես քսան անգամ ավելի արագ։ Որքան ծախսատար է էջը, այնքան մեծ է շահույթը։ Երկու արժեքներից վահանակը հաշվում է նաև գնահատված խնայված սերվերային ժամանակը։

Ֆայլ թե RAM՝ պահոցի ընտրություն

Քեշն ունի երկու պահոց։ Երկուսն էլ ընդհանուր տեսանելի են Odoo-ի բոլոր աշխատանքային պրոցեսների համար, ուստի յուրաքանչյուր էջ գոյություն ունի միայն մեկ անգամ, այլ ոչ թե մեկ անգամ յուրաքանչյուր պրոցեսի համար։

Տեղադրումների մեծ մասի համար Ավտոմատ ռեժիմը ճիշտ ընտրությունն է. երբ տեղ կա, ստանում եք RAM-ի արագություն, իսկ հակառակ դեպքում առանց միջամտության անցնում եք ֆայլերի։

Տեղավորվո՞ւմ է կայքը օպերատիվ հիշողության մեջ։ Իսկ որքա՞ն RAM է պակասում

RAM քեշն հնարավո՞ր է, թե ոչ, կախված է երեք բանից՝ էջերի քանակից, դրանց միջին չափից և հասանելի հիշողությունից։ Վահանակը դա հաշվարկում է ձեզ համար.

• Էջերի քանակ. յուրաքանչյուր կայքի համար հաշվում է հրապարակված ապրանքները, խանութի ցանկի էջերը, կատեգորիաները, բլոգի հոդվածները և բլոգի ցանկերը և բազմապատկում լեզուների քանակով։
• Էջի չափ. հենց որ էջեր հայտնվում են քեշում, չափվում է իրական միջինը. մինչ այդ գործում է ենթադրյալ արժեք։
• Տեղ քեշի համար. ամենափոքր արժեքը սահմանված RAM-բյուջեից, tmpfs-ի չափից և հասանելի օպերատիվ հիշողության կեսից։ Սերվերը երբեք չպետք է քեշի պատճառով հիշողության պակասի մեջ հայտնվի։
• Եզրակացություն. «տեղավորվում է պահուստով», «նեղ է», «չափազանց մեծ է» կամ «RAM քեշը հասանելի չէ»։ «Տեղավորվում է» գործում է, երբ պահանջը հասանելի տարածքի առավելագույնը 80 տոկոսն է։

Նոր. որքա՞ն լրացուցիչ RAM կպահանջվեր

Երբ քեշը չի տեղավորվում, ուզում ենք իմանալ՝ ինչը պետք է փոխել։ Դրա համար վահանակը եզրակացության տակ նշում է կոնկրետ տող. «Լրացուցիչ RAM RAM քեշի համար. այս սերվերում մոտավորապես … ավելի շատ օպերատիվ հիշողություն» – կամ «չի պահանջվում», եթե տարածքն արդեն բավարար է։ Եթե սերվերի փոխարեն միայն որևէ կարգավորում է չափազանց փոքր, ներքևում նշվում է, թե որը. մոդուլի RAM-բյուջեն կամ tmpfs-ի չափը (/dev/shm)։

Դրա հետևում կանգնած հաշվարկը պարզ է և հետևելի.

1. Պահանջ = էջեր × էջի միջին չափ։
2. Պահուստով = պահանջը բաժանած 0,8-ի։ Այս արժեքը պետք է տեղավորվի RAM-բյուջեի և tmpfs-ի մեջ, որպեսզի եզրակացությունը լինի «տեղավորվում է»։
3. Ազատ հիշողություն. քանի որ քեշը կարող է օգտագործել հասանելի օպերատիվ հիշողության առավելագույնը կեսը, սերվերին որպես ազատ հիշողություն պետք է առնվազն 2-րդ քայլի արժեքի կրկնապատիկը։ Եթե ինչ-որ բան պակասում է, տարբերությունը լրացուցիչ պահանջվող RAM-ն է։

Նկարում բերված օրինակը (12 000 էջ՝ յուրաքանչյուրը 25 ԿԲ) հաշվարկային օգնություն է, այլ ոչ թե մեր էջերի չափում։ Փոքր կայքերի համար բավական են մի քանի տասնյակ մեգաբայթեր. էկրանի նկարների օրինակային տվյալները բավարարվեցին մոտ 13 ՄԲ-ով։

Կարևոր է գնահատման համար. գնահատականը չի հաշվում գնացուցակների կամ երկրների լրացուցիչ տարբերակները։ Ով դրանցից շատ է օգտագործում, թող որոշ պահուստ նախատեսի։ Եվ ևս մեկ բան. չափազանց փոքր RAM-բյուջեն ամենահաճախակի պատճառն է, թե ինչու է ավտոմատը մնում ֆայլերի վրա, այլ ոչ թե օպերատիվ հիշողության բացակայությունը։ Վահանակն այդ դեպքում ցույց է տալիս հենց այդ տողը։

Փոփոխություններն ու թարգմանությունները մաքրում են քեշը

Քեշը օգտագործելի է միայն այն դեպքում, եթե երբեք հնացած էջեր չի տրամադրում։ Զուտ ժամանակային սահմանաչափը («ամեն տասներկու ժամը մեկ մերժել») չափազանց կոպիտ կլիներ. փոխված գինը կամ ուղղված վրիպակը պետք է մինչև տասներկու ժամ սպասեին։ Դրա համար մոդուլն աշխատում է ըստ բովանդակության։

1. Տվյալների բազայի տրիգերներ. բոլոր աղյուսակների վրա, որոնք կարող են ազդել էջի վրա (ապրանքներ, տարբերակներ, նկարներ, պաշար, հատկանիշներ, կատեգորիաներ, գներ, հարկեր, գնացուցակներ, բլոգի հոդվածներ և պիտակներ, գործընկերների և ընկերությունների տվյալներ, դիտումներ, assets, ընտրացանկեր, լեզուներ, կայքի կարգավորումներ), տեղադրված են PostgreSQL տրիգերներ։ Դրանք յուրաքանչյուր փոփոխությունը գրանցում են փոփոխությունների մատյանում։
2. Կախվածություններ և տվյալների բազայի վիճակ. յուրաքանչյուր քեշավորված էջ հիշում է, թե որ գրառումներն է ցուցադրում և ինչ վիճակի տվյալների բազայով է ստեղծվել։
3. Համեմատություն. եթե կա մատյանի գրառում, որը ծագել է այս վիճակից հետո և վերաբերում է այդ գրառումներից որևէ մեկին, էջը հնացած է։
4. Նոր քեշավորում. հաջորդ դիմման ժամանակ հնացած էջը մերժվում է, նորից ձևավորվում և նորից պահվում։

Թարգմանություններն էլ ընդգրկված են

Odoo 19-ը թարգմանված տեքստերը պահում է նույն գրառման մեջ, ինչ բնօրինակ տեքստը (որպես JSON դաշտ)։ Փոփոխված թարգմանությունը, հետևաբար, տվյալների բազայի համար լրիվ սովորական տողի փոփոխություն է – և տրիգերը տեսնում է այն։ Սա հավասարապես վերաբերում է ինտերֆեյսով խմբագրմանը, ներմուծումներին, ինտերֆեյսներին և տվյալների բազայում ուղղակիորեն գրող սկրիպտներին։ 46 լեզվով ավտոմատ թարգմանությունը, այսպիսով, անվավեր է դարձնում հենց այն էջերը, որոնց տեքստը փոխվել է, և ոչ ավելին։

• Նպատակային, այլ ոչ թե համատարած. փոփոխված ապրանքն անվավեր է դարձնում իր էջերը, այն ցանկերը, որոնցում այն գտնվում է, և համապատասխան կատեգորիան։ Մնացածը մնում է քեշում։
• Գլոբալ փոփոխությունները (ձևանմուշներ, assets, լեզուներ, ընտրացանկեր, հարկեր, արժույթներ) անվավեր են դարձնում ամեն ինչ միանգամից, քանի որ կարող են ազդել ցանկացած էջի վրա։
• Հաշվիչները մնում են դուրս. բլոգի հոդվածների դիմումների հաշվիչը փոխվում է յուրաքանչյուր այցի ժամանակ. այն միտումնավոր չի առաջացնում անվավերացում, հակառակ դեպքում քեշը հայտնի հոդվածների համար անարդյունավետ կլիներ։
• Անվտանգության ցանց. դրանից բացի գոյություն ունի էջի առավելագույն տարիք (լռելյայն՝ 12 ժամ)։
• Քեշը գրելու սխալ չի առաջացնում. տրիգերի ներսի սխալը գրանցվում է որպես նախազգուշացում և չի խափանում հենց պահպանումը։

Կառավարման վահանակ և վիճակագրություն

Ամեն ինչ, ինչ անհրաժեշտ է շահագործման համար, գտնվում է մեկ տեղում. Odoo-ում՝ Կայք → Հաշվետվություններ → Էջերի քեշ։ Ընդհանուր տեսք բաժինը վահանակն է (կարգավորումներով), Ընթացք բաժինը ցույց է տալիս թվերը ըստ օրերի և կայքերի։

Էկրանի նկար մեր կայքերի պատճեններով փորձարկման համակարգից. կայքերի անվանումները փոխարինված են տեղապահներով։

Կարգավորումներ

Կարգավիճակ և վիճակագրություն

Կարգավիճակը ցույց է տալիս ակտիվ պահոցը՝ իր սահմանով, քեշավորված էջերի քանակն ու չափը և փոփոխությունների հետևումը. վերջին 24 ժամվա ընթացքում քանի փոփոխություն է գրանցվել և քանի աղյուսակ է վերահսկվում։ Եթե վերահսկումը բացակայում է, վահանակը հստակ զգուշացնում է, քանի որ այդ դեպքում քեշին վստահել չի կարելի։ Վերևի կոճակները թույլ են տալիս անմիջապես կատարել սպասարկումը, դատարկել քեշը կամ ստուգել տրիգերները և անհրաժեշտության դեպքում նորից ստեղծել։

Վիճակագրությունը (Այսօր, 7 օր, 30 օր) ներառում է.

• Քեշից և Ձևավորված. հարվածներ և վրիպումներ, դրանցից՝ հարվածների մասնաբաժինը
• Հեռացված (փոփոխված/ժամկետանց). քանի էջ է մերժվել փոփոխության կամ ժամկետի ավարտի պատճառով
• Ձևավորման ժամանակ և քեշի ժամանակ. միջինը մեկ էջի համար՝ համեմատությամբ
• Գնահատված խնայված սերվերային ժամանակ և քեշից տրված տվյալների ծավալ

Թվերը յուրաքանչյուր աշխատանքային պրոցես հավաքում է առանձին և գրում րոպեում մեկ անգամ. 90 օրից հին տողերը մաքրում է սպասարկման առաջադրանքը։

Ընթացքը՝ դիագրամի, pivot-ի և ցանկի տեսքով

Ընթացք բաժնում հասանելի են օրական արժեքները ըստ կայքերի – դիագրամի, pivot աղյուսակի կամ ցանկի տեսքով։ Այսպես կարող եք տեսնել, արդյոք հարվածների մասնաբաժինը վերագործարկումից կամ մեծ փոփոխությունից հետո նորից աճում է, և որ կայքն է քեշից ստանում ամենաշատ տրաֆիկը։

Անվտանգություն՝ ինչը երբեք չի տրվում քեշից

Էջերի քեշը երբեք չպետք է հանգեցնի նրան, որ որևէ մեկը տեսնի ուրիշի բովանդակությունը։ Դրա համար մոդուլը գործում է հետևյալ սկզբունքով. կասկածի դեպքում չքեշավորել։

• Միայն անանուն այցելուներ. ով մուտք է գործել, զամբյուղ ունի կամ բերում է սեսիայի այլ վիճակ, միշտ ստանում է սովորաբար ձևավորված էջը։
• Միայն որոնման պարամետրերից զերծ GET. որոնումները, ֆիլտրերը, տեսակավորումները, ձևերը, զամբյուղը և վճարումը մնում են անձեռնմխելի։
• Միայն կարգավիճակ 200 և HTML. սխալի էջերը, վերահասցեավորումները և ֆայլերը չեն պահվում։
• Քեշում սեսիայի ID-ներ չկան. էջը, որը պարունակում է սեսիայի ID կամ սահմանում է քուքի, չի պահվում (և գրանցվում է որպես նախազգուշացում)։
• CSRF թոքեն՝ յուրաքանչյուր դիմման համար. քեշավորված էջի թոքենը տեղապահ է և յուրաքանչյուր տրամադրման ժամանակ նորից է տեղադրվում։
• Նուրբ բանալի. կայքը, լեզուն, գնացուցակը, հարկային դիրքը և քուքիների համաձայնությունը քեշի բանալու մաս են կազմում. ով այլ բան է տեսնում, ստանում է այլ գրառում։
• Մի քանի տվյալների բազա. յուրաքանչյուր տվյալների բազա ունի սեփական գրառումներ, սեփական մատյան և սեփական վիճակագրություն։
• Տվյալների արտահոսք չկա. քեշը գտնվում է տեղական՝ սերվերի վրա (ֆայլ կամ RAM)։ Երրորդ կողմերին տվյալներ չեն փոխանցվում։

Որոնողական համակարգեր և արհեստական բանականության ինդեքսավորիչներ՝ ոչինչ չի արգելափակվում

Որոշ օպերատորներ կրաուլերների ծանրաբեռնվածությանը արձագանքում են արգելափակումներով։ Դա պաշտպանում է սերվերը, բայց արժե տեսանելիություն։ Մոդուլն ընտրում է հակառակ ճանապարհը.

• Նույն բովանդակությունը բոլորի համար. որոնողական համակարգերը, արհեստական բանականության ինդեքսավորիչները և այցելուները ստանում են նույն էջը։ Չկա առանձին «կրաուլերային տարբերակ» և չկա բրաուզերի նույնացուցիչով ճանաչում։
• Ավելի արագ պատասխանները օգնում են ինդեքսավորմանը. 500-ի փոխարեն 20 միլիվայրկյանում պատասխանող էջը պակաս է ծանրաբեռնում crawl budget-ը, և կրաուլերները նույն ժամանակում կարող են ավելի շատ էջեր ընդգրկել։
• Արդի բովանդակություն. քանի որ փոփոխությունները էջերն անմիջապես անվավեր են դարձնում, կրաուլերները երբեք հնացած տարբերակ չեն տեսնում – կարևոր է, եթե բովանդակությունը խնամում եք որոնման և արհեստական բանականության պատասխանների համար։
• Կառուցվածքային տվյալները պահպանվում են. JSON-LD-ն, մետա-տվյալները և hreflang հղումները քեշավորված էջի մաս են կազմում. կայքի քարտեզներին և ֆայլերին քեշը չի դիպչում։

Եթե դրանից բացի ցանկանում եք սահմանափակել ծանրաբեռնվածությունը, դա առանձին որոշում է, որը կարող եք գիտակցաբար կայացնել – մոդուլը դա ձեզ չի պարտադրում։

HTML-ի մինիմիզացում և սեղմված տրամադրում

Քեշը խնայում է ոչ միայն հաշվարկային ժամանակ, այլև տվյալների ծավալ։ Մոդուլը HTML-ը մինիմիզացնում է պահելուց առաջ և տրամադրում է սեղմված, եթե բրաուզերը կամ կրաուլերը դա առաջարկում է.

• Մինիմիզացում (պարամետր website_page_cache.minify). HTML մեկնաբանությունները հանվում են, բացատները միավորվում են։ Ամբողջությամբ հեռացվում են միայն այնտեղ, որտեղ բրաուզերը դրանք այնուամենայնիվ անտեսում է, օրինակ՝ բլոկային տարրերի միջև։ Ներտողային տարրերի միջև հեռավորությունները մնում են, pre-ը, textarea-ը և սկրիպտները մնում են անփոփոխ, կառուցվածքային տվյալները (JSON-LD) նորից գրվում են կոմպակտ կերպով։ Էջից կախված՝ էջերը 10-ից 30 %-ով փոքր են։ Յոթ իրական էջերով փորձարկման ժամանակ տեքստը, տարրերի քանակը, բոլոր տարրերի դիրքը և էկրանի նկարը համընկնում էին բնօրինակի հետ։ Առաջին տրամադրումը (MISS) մինիմիզացված է հենց այնպես, ինչպես յուրաքանչյուր հաջորդը (HIT)։
• Սեղմում (պարամետր website_page_cache.compress). քեշի էջերը ուղարկվում են gzip-ով (Content-Encoding: gzip, Vary: Accept-Encoding)։ Asset-ների խոշոր փաթեթները (CSS և JavaScript՝ մինչև մի քանի ՄԲ) Odoo-ն ինքը տրամադրում է չսեղմված. մոդուլը դրանք սեղմում է մեկ անգամ, պատճենը պահում է սկավառակի վրա և հետո տրամադրում է անմիջապես։ Այսպես 2,1 ՄԲ CSS-ից ստացվեց 0,27 ՄԲ, 4,8 ՄԲ JavaScript-ից՝ 1,1 ՄԲ։ Հին պատճեններն մաքրում է սպասարկման առաջադրանքը։
• Համակարգչի վերագործարկումից հետո. RAM քեշը պահպանվում է Odoo-ի վերագործարկումների ժամանակ, բայց ոչ սերվերի վերագործարկման ժամանակ։ Դրա համար սպասարկման առաջադրանքը այն աստիճանաբար արտացոլում է սկավառակի վրա (պարամետր website_page_cache.persist) և գործարկման ժամանակ վերականգնում է։ Վերականգնված գրառումը դեռ վավե՞ր է, ստուգում է նույն մեխանիզմը, ինչ այլ դեպքերում՝ տարիքը և փոփոխությունների մատյանը։ Մինիմիզացումը այդ ժամանակ նորից չի հաշվարկվում։

Տեղադրում և կարգավորումներ

1. Ձեռք բերել մոդուլը. GitHub-ից ներբեռնել սկզբնական կոդը և տեղադրել ձեր Odoo 19 տեղադրման addons ուղու մեջ՝ github.com/Alex0176/odoo-website-page-cache
2. Տեղադրել. odoo-bin -d <Datenbank> -i website_page_cache --stop-after-init։ Դրանով ստեղծվում են փոփոխությունների մատյանը, տրիգերները և սպասարկման առաջադրանքը (10 րոպե մեկ)։
3. Վերագործարկել ծառայությունը, որպեսզի բոլոր աշխատանքային պրոցեսները բեռնեն մոդուլը։
4. Բացել վահանակը. Կայք → Հաշվետվություններ → Էջերի քեշ։ Ստուգել, արդյոք փոփոխությունների հետևումը լրիվ է, և ընտրել պահոցը (լռելյայն՝ ավտոմատ)։
5. Ստուգել. խանութի կամ բլոգի էջը երկու անգամ պահանջել և դիտել X-Page-Cache վերնագիրը. առաջին անգամ MISS, հետո HIT։

Կարգավորումները առկա են որպես համակարգային պարամետրեր (website_page_cache.enabled, .backend, .ttl_hours, .max_mb_file, .max_mb_ram) և սովորաբար խմբագրվում են վահանակում։ Մոդուլը թարգմանված է գերմաներեն։ Ապատեղադրումը նորից լրիվ հեռացնում է տրիգերները, մատյանը և բոլոր քեշավորված էջերը։

Խորհուրդ RAM քեշի համար. վահանակի RAM-բյուջեն և tmpfs-ի չափը (/dev/shm, մոնտաժման տարբերակ size=) պետք է համապատասխանեն պահանջին։ Երկուսն էլ ձեզ կոնկրետ արժեքներով նշում է «Տեղավորվո՞ւմ է օպերատիվ հիշողության մեջ» ստուգումը։

Սահմանափակումներ, որոնք պետք է իմանալ

• Կարճ ուշացում փոփոխություններից հետո. փոփոխությունների մատյանի ինդեքսը թարմացվում է երկու վայրկյան մեկ։ Մինչ այդ փոփոխված էջը դեռ կարող է տրվել հին տարբերակով։
• Պաշարից կախված տեքստերը թարմացվում են պաշարի փոփոխությունների և առավելագույն տարիքի միջոցով։
• Տարածքի պահանջի գնահատում. գնացուցակի կամ երկրի գծով լրացուցիչ տարբերակները հաշվի չեն առնված. նախատեսեք որոշ պահուստ։
• Ամենինչի փոխարինող չէ. քեշը թեթևացնում է այն հարցումները, որոնք կարող է սպասարկել։ Մուտք գործած օգտատերերը, որոնումները և ձևերը շարունակում են անցնել Odoo-ով։
• Առաջին դիմումը մնում է դանդաղ. սերվերի վերագործարկումից (RAM) կամ գլոբալ փոփոխությունից հետո յուրաքանչյուր էջ մեկ անգամ ձևավորվում է սովորական կարգով, նախքան քեշում հայտնվելը։

Հաճախ տրվող հարցեր

Ի՞նչ է Odoo-ի էջերի քեշը

Բաց կոդով մոդուլ (website_page_cache, Odoo 19, LGPL-3), որը հանրային խանութի և բլոգի էջերը անանուն այցելուների համար տրամադրում է քեշից, այլ ոչ թե յուրաքանչյուր դիմման ժամանակ նորից ձևավորում։ Քեշը ըստ ընտրության գտնվում է ֆայլերում կամ օպերատիվ հիշողության մեջ։

Արգելափակո՞ւմ է մոդուլը որոնողական համակարգերին կամ արհեստական բանականության կրաուլերներին

Ոչ։ Որոնողական համակարգերը և արհեստական բանականության ինդեքսավորիչները ստանում են նույն էջերը, ինչ ցանկացած այլ այցելու, պարզապես ավելի արագ։ Չկա արգելափակում, չկա դանդաղեցում և չկա կրաուլերների համար առանձին տարբերակ։

Փոփոխված էջերն ու թարգմանությունները ավտոմատ կերպով նորի՞ց են քեշավորվում

Այո։ PostgreSQL տրիգերները համապատասխան աղյուսակների յուրաքանչյուր փոփոխության մասին հայտնում են մատյանին. տուժած էջերը մերժվում են և հաջորդ դիմման ժամանակ նորից ձևավորվում ու պահվում։ Թարգմանություններն ընդգրկված են, քանի որ Odoo 19-ը դրանք պահում է նույն գրառման մեջ։

Ընտրե՞մ ֆայլ, թե՞ RAM

Սովորաբար Ավտոմատ. մոդուլն օգտագործում է RAM-ը, քանի դեռ բոլոր էջերը տեղավորվում են, իսկ հակառակ դեպքում անցնում է ֆայլերի։ Ֆայլերը հարմար են, երբ քեշը պետք է վերապրի վերագործարկումները կամ RAM-ը սակավ է. RAM-ը ամենաարագ տարբերակն է։

Ինչպե՞ս իմանալ, արդյոք իմ կայքը տեղավորվում է օպերատիվ հիշողության մեջ

Վահանակում՝ Կայք → Հաշվետվություններ → Էջերի քեշ։ «Տեղավորվո՞ւմ է օպերատիվ հիշողության մեջ» բաժինը հաշվում է էջերը ըստ կայքի և լեզվի, չափում է էջի չափը և համեմատում է պահանջը RAM-բյուջեի, tmpfs-ի չափի և հասանելի հիշողության հետ։

Որքա՞ն լրացուցիչ RAM է պահանջվում RAM քեշի համար

Վահանակը դա նշում է առանձին տողով։ Հաշվարկը հետևյալն է. պահանջ = էջեր × էջի չափ. անվտանգության պահուստով՝ բաժանած 0,8-ի։ Քանի որ քեշը կարող է օգտագործել հասանելի հիշողության առավելագույնը կեսը, դրա կրկնապատիկն է պահանջվող ազատ հիշողությունը. տարբերությունը լրացուցիչ RAM-ն է։ Եթե միայն RAM-բյուջեն կամ tmpfs-ն է չափազանց փոքր, վահանակը նշում է կարգավորումը՝ թիրախային արժեքի հետ միասին։

Կարո՞ղ է քեշը որևէ մեկին ուրիշի բովանդակությունը ցույց տալ

Ոչ։ Քեշավորվում է միայն որոնման պարամետրերից զերծ անանուն GET դիմումների համար։ Մուտք գործած օգտատերերը, զամբյուղները, ձևերը և որոնումները երբեք չեն տրվում քեշից. լեզուն, գնացուցակը, հարկային դիրքը և քուքիների համաձայնությունը բանալու մաս են կազմում։

Ինչպե՞ս անջատել քեշը վթարային դեպքում

Վահանակում անջատեք «Ակտիվ» անջատիչը կամ website_page_cache.enabled համակարգային պարամետրը սահմանեք 0։ Սա բոլոր աշխատանքային պրոցեսներում գործում է առավելագույնը 30 վայրկյանից հետո։ Ապատեղադրումը դրանից բացի հեռացնում է տրիգերները, մատյանը և քեշավորված էջերը։

Ինչպե՞ս ճանաչել, որ էջը քեշից է եկել

X-Page-Cache պատասխանի վերնագրով. HIT նշանակում է՝ քեշից, MISS նշանակում է՝ նոր ձևավորված և պահված։

Փոքրացնո՞ւմ և սեղմո՞ւմ է մոդուլը HTML-ը

Այո։ Քեշավորված էջերը պահպանողականորեն մինիմիզացվում են (մեկնաբանությունները և ավելորդ բացատները հանվում են, բովանդակությունն ու տեսքը մնում են նույնը) և քեշի հարվածների ժամանակ տրամադրվում են gzip-ով. asset-ների փաթեթները սեղմվում են մեկ անգամ և տրամադրվում սկավառակից։ Երկուսն էլ կարելի է անջատել website_page_cache.minify և website_page_cache.compress պարամետրերով։

Biricon IT Services-ի աջակցությունը

Ձեր Odoo կայքը կրաուլերների ծանրաբեռնվածության տակ դանդաղ է արձագանքում, կամ ցանկանո՞ւմ եք խանութն ու բլոգն ավելի արագ և ավելի տեսանելի դարձնել։ Մենք աջակցում ենք ծանրաբեռնվածության վերլուծությանը, էջերի քեշի կարգավորմանը, օպերատիվ հիշողության և աշխատանքային պրոցեսների չափագրմանը և ձեր Odoo կայքի բազմալեզու որոնողական օպտիմիզացմանը։ Մոդուլի սկզբնական կոդը կգտնեք GitHub-ում։

Կապ հաստատել հիմա

Վիճակը՝ 2026 թ. նոյեմբերի 10։ Չափված արժեքները ծագում են օրինակային տվյալներով փորձարկման համակարգից և այլ տեղադրումների համար երաշխիք չեն։