Məzmuna keçin

Odoo üçün səhifə keşi: mağaza və bloq RAM-dan və ya fayldan – ziyarətçilər, axtarış sistemləri və Sİ üçün sürətli

Açıq mənbəli website_page_cache modulu açıq Odoo səhifələrini demək olar ki, statik şəkildə təqdim edir, dəyişikliklər və tərcümələr zamanı aktual qalır və idarə panelində RAM-ın lazım olub-olmadığını və nə qədər lazım olduğunu göstərir
10 noyabr 2026 tərəfindən
Odoo üçün səhifə keşi: mağaza və bloq RAM-dan və ya fayldan – ziyarətçilər, axtarış sistemləri və Sİ üçün sürətli

10 noyabr 2026  |  Öz hazırlığımız  |  Odoo, performans və axtarış sistemləri

Odoo veb-saytları üçün səhifə keşi: açıq mağaza və bloq səhifələrini hər sorğuda yenidən render etmək əvəzinə fayldan və ya RAM-dan təqdim etmək

Odoo veb-saytı hər səhifəni hər sorğuda yenidən yaradır: verilənlər bazası sorğuları, şablonlar, tərcümələr, qiymətlər. Tək bir ziyarətçi üçün bu hiss olunmur. Lakin axtarış sistemləri və Sİ indeksatorları çoxlu dildə yüzlərlə və ya minlərlə səhifəni sorğulayanda bu, daimi yükə çevrilir və real müştərilər də gözləməli olur. Buna görə biz Odoo 19 üçün website_page_cache modulunu hazırladıq və GitHub-da Open Source (LGPL-3) kimi dərc etdik: anonim açılan mağaza və bloq səhifələri demək olar ki, statik şəkildə keşdən verilir – ya fayllardan, ya da operativ yaddaşdan (RAM), hər dəyişiklik isə – tərcümədəki dəyişiklik də daxil olmaqla – təsirlənən səhifələri keşdən avtomatik silir.

Tapılmaq istəyən hər kəs üçün vacibdir: modul heç bir axtarış sistemini və heç bir Sİ krouleri bloklamır. Bütün indeksatorlar hər ziyarətçi ilə eyni məzmunu alır, sadəcə daha sürətli. Bu məqalə keşin necə işlədiyini, idarə panelinin necə göründüyünü (ekran görüntüləri ilə), səhifələrinizin operativ yaddaşa sığıb-sığmadığını və əlavə nə qədər RAM lazım olacağını necə müəyyən edəcəyinizi, hansı təhlükəsizlik qaydalarının qüvvədə olduğunu və modulu necə quraşdıracağınızı izah edir.

Qısa xülasə

MövzuNə keçərlidir
Modulwebsite_page_cache Odoo 19 üçün, LGPL-3 lisenziyası, GitHub-da açıq
Nə keşlənir?Hər veb-saytın hər dilində açıq mağaza və bloq səhifələri (siyahılar, kateqoriyalar, məhsullar, məqalələr)
Kimin üçün?Yalnız anonim ziyarətçilər üçün, yalnız axtarış parametrləri olmayan GET sorğuları, yalnız HTML ilə 200 statusu
Saxlama yeriDiskdə fayllar və ya RAM (tmpfs, bütün iş proseslərinin ortaq istifadəsində); avtomatik olaraq lazım olan yerə görə
AktuallıqHər dəyişiklik (tərcümələr, importlar, skriptlər də daxil olmaqla) verilənlər bazası triggerləri vasitəsilə jurnal qeydi yaradır və təsirlənən səhifələri etibarsız edir
İdarə paneliParametrlər, vəziyyət, statistika (uğurlu sorğular, buraxılmış sorğular, qənaət edilən server vaxtı) və «əlavə lazım olan RAM» daxil olmaqla «Operativ yaddaşa sığırmı?» yoxlaması
Axtarış sistemləri və SİHeç nə bloklanmır və məhdudlaşdırılmır; hamı eyni səhifələri alır, sadəcə daha sürətli
Təcili dayandırmaBir açar (enabled = 0) keşi bütün iş proseslərində 30 saniyə ərzində söndürür

Problem: Odoo veb-saytlarında kroulerlərin yükü

Odoo tam hüquqlu ERP sistemidir, veb-sayt isə onun çoxsaylı modullarından biridir. Ziyarətçinin və ya robotun açdığı hər səhifə eyni yolu keçir: sorğunun emalı, verilənlər bazasına müraciət, məhsul və qiymət məlumatlarının yüklənməsi, QWeb şablonunun render edilməsi, tərcümələrin əlavə olunması və nəticənin təqdim edilməsi. Səhifədən asılı olaraq bu bir neçə yüz millisaniyə çəkir və bu müddətdə az sayda iş proseslərindən birini məşğul edir.

Axtarış sistemləri və Sİ indeksatorları üçün bu, daimi məsələdir:

  • Çox dil, çox ünvan: 46 dildə mövcud olan səhifə krouler üçün 46 fərqli ünvandır.
  • Hər ünvan ayrıca sorğulanır, çox vaxt çoxsaylı paylanmış göndəricilər tərəfindən eyni vaxtda. Klassik brauzer keşi burada kömək etmir, çünki hər sorğu yeni ünvana aiddir.
  • Az iş prosesi: Odoo xidməti adətən bir ovuc prosesla işləyir. Onlar krouler sorğuları ilə məşğul olanda real ziyarətçilər növbədə gözləyir.
  • Eyni məzmun, dəfələrlə yenidən: bloq məqaləsi nadir hallarda dəyişir, lakin hər sorğuda zəhmətlə yenidən tərtib olunur.

Ən aşkar çıxış yolu – kroulerləri bloklamaq – tapılmaq istəyən şirkət üçün variant deyil. Axtarış sistemlərində və Sİ cavablarında görünmək qiymətlidir. Səhifələri elə sürətlə təqdim etmək daha yaxşıdır ki, yük demək olar ki, hiss olunmasın. Səhifə keşi məhz bunu edir.

Səhifə keşi necə işləyir

Modul Odoo-nun sorğu girişinə qoşulur (ir.http). Hər səhifə sorğusunda millisaniyənin bir hissəsində səhifənin keşdən verilə biləcəyini qərara alır və onu verilənlər bazası, şablon və render olmadan təqdim edir.

Axın diaqramı: sorğu, yoxlama, keş açarı, uğurlu və ya buraxılmış sorğu, saxlama və təqdimat

  1. Yoxlama: yalnız icazə verilən yolda (mağaza, kateqoriyalar, məhsullar, bloq) axtarış parametrləri olmayan anonim GET sorğusu nəzərə alınır. Qalan hər şey həmişəki kimi Odoo-dan keçir.
  2. Keş açarı: o, veb-saytdan, host sinfindən, dildən, yoldan, qiymət siyahısından, vergi mövqeyindən və kuki razılığı vəziyyətindən ibarətdir. Buna görə fərqli şey görəcək ziyarətçilər heç vaxt bir qeydi bölüşmür. Host bu zaman normallaşdırılır: Odoo mütləq ünvanları həmişə sorğudan deyil, veb-saytın domenindən yazır; sorğu ünvanı yalnız səhifənin əsas ünvan sayılıb-sayılmayacağını (dil istinadları) və indekslənib-indekslənməyəcəyini müəyyən edir. Buna görə bütün yad host adları hər biri üçün ayrıca surət yaratmaq əvəzinə, noindex qeydi ilə birlikdə bir qeydi bölüşür.
  3. Uğurlu sorğu: aktual qeyd varsa, o təqdim olunur. Səhifədəki CSRF tokeni bu zaman hər sorğu üçün yenidən təyin edilir. Bloq məqalələrinin açılışları sayılmağa davam edir.
  4. Buraxılmış sorğu: qeyd yoxdursa və ya köhnəlibsə, Odoo səhifəni həmişəki kimi render edir. Nəticə keşlənə bilərsə (status 200, HTML, kuki yoxdur, mətndə sessiya ID-si yoxdur), saxlanılır; növbəti sorğu uğurlu olur.
  5. Başlıqda görünür: hər cavab X-Page-Cache: HIT və ya MISS başlığını daşıyır. Beləliklə, hər hansı alətlə nə baş verdiyini yoxlamaq olar.

Nə qədər sürətli?

Bizim test sistemimizdə (veb-saytlarımızın surəti, bir neçə yüz səhifə) bir səhifənin orta render müddəti təxminən 490 millisaniyə, keşdən təqdimat isə təxminən 23 millisaniyə idi: təxminən iyirmi dəfə. Səhifə nə qədər mürəkkəbdirsə, qazanc da bir o qədər böyükdür. İdarə paneli hər iki dəyərdən təxmini qənaət edilmiş server vaxtını da hesablayır.

Fayl, yoxsa RAM: saxlama yerinin seçimi

Keşin iki saxlama yeri var. Hər ikisi bütün Odoo iş proseslərinə ortaq görünür, ona görə hər səhifə proses başına bir dəfə deyil, yalnız bir dəfə mövcuddur.

Fayl keşi və RAM keşinin müqayisəsi və avtomatikanın qərar qaydası

ParametrSəhifələr harada yerləşir?Xüsusiyyətlər
FayllarOdoo məlumat qovluğunda, hər verilənlər bazası üçün ayrıca qovluqyenidən başlatmalardan sağ çıxır; əməliyyat sistemi tez-tez istifadə olunan səhifələri onsuz da yaddaşda saxlayır
Operativ yaddaş/dev/shm altında tmpfsən sürətli təqdimat; serverin yenidən başladılması zamanı itir və sadəcə yenidən qurulur
Avtomatikhər şey sığdıqca RAM; əks halda fayllarXidmət tapşırığı (hər 10 dəqiqədən bir) qiymətləndirməyə əsasən qərar verir; seçim daim dəyişməsin deyə «sığır» və «sərhəddədir» hallarında RAM-da qalır

Əksər quraşdırmalar üçün Avtomatik düzgün seçimdir: yer olduqda RAM sürətini alırsınız, əks halda müdaxilə olmadan fayllara keçilir.

Veb-sayt operativ yaddaşa sığırmı? Və nə qədər RAM çatışmır?

RAM keşinin mümkün olub-olmaması üç şeydən asılıdır: səhifələrin sayından, onların orta ölçüsündən və mövcud yaddaşdan. İdarə paneli bunu sizin üçün hesablayır:

  • Səhifə sayı: hər veb-sayt üzrə dərc olunmuş məhsulları, mağaza siyahı səhifələrini, kateqoriyaları, bloq məqalələrini və bloq siyahılarını sayır və dillərin sayına vurur.
  • Səhifə ölçüsü: səhifələr keşə düşən kimi faktiki orta dəyər ölçülür; o vaxta qədər təxmini dəyər qüvvədədir.
  • Keş üçün yer: təyin edilmiş RAM büdcəsi, tmpfs ölçüsü və mövcud operativ yaddaşın yarısı arasından ən kiçik dəyər. Server keşə görə heç vaxt yaddaş çatışmazlığına düşməməlidir.
  • Qiymətləndirmə: «ehtiyatla sığır», «sərhəddədir», «çox böyükdür» və ya «RAM keşi əlçatan deyil». «Sığır» ehtiyac mövcud yerin ən çoxu 80 faizi olduqda keçərlidir.

Hər veb-sayt üzrə səhifə sayı, yer ehtiyacı və əlavə lazım olan RAM göstəricisi ilə idarə panelinin Operativ yaddaşa sığırmı? bölməsi

Yeni: Əlavə nə qədər RAM lazım olardı?

Keş sığmayanda nəyi dəyişmək lazım olduğunu bilmək istəyirsiniz. Ona görə idarə paneli qiymətləndirmənin altında konkret bir sətir göstərir: «RAM keşi üçün əlavə RAM: bu serverdə təxminən … artıq operativ yaddaş» – yer artıq kifayət edirsə, «lazım deyil». Server əvəzinə yalnız bir parametr çox kiçikdirsə, altında hansı olduğu göstərilir: modulun RAM büdcəsi və ya tmpfs-in ölçüsü (/dev/shm).

RAM büdcəsi çox kiçik olan idarə paneli: Xeyr qiymətləndirməsi və RAM büdcəsini ən azı lazım olan dəyərə qaldırmaq tələbi

Bunun arxasındakı hesablama sadə və izlənə biləndir:

Hesablama nümunəsi: 12 000 səhifə × 25 KB təxminən 300 MB ehtiyac verir, ehtiyatla təxminən 375 MB, bunun üçün ən azı 750 MB boş yaddaş lazımdır

  1. Ehtiyac = səhifələr × orta səhifə ölçüsü.
  2. Ehtiyatla = ehtiyacın 0,8-ə bölünməsi. Qiymətləndirmənin «sığır» olması üçün bu dəyər RAM büdcəsinə və tmpfs-ə sığmalıdır.
  3. Boş yaddaş: keş mövcud operativ yaddaşın ən çoxu yarısını istifadə edə bildiyinə görə, serverə boş mövcud yaddaş kimi 2-ci addımdakı dəyərin ən azı iki misli lazımdır. Nəsə çatışmırsa, fərq əlavə lazım olan RAM-dır.

Şəkildəki nümunə (hər biri 25 KB olan 12 000 səhifə) hesablama köməkçisidir, səhifələrimizin ölçməsi deyil. Kiçik veb-saytlar üçün bir neçə on meqabayt kifayət edir; ekran görüntülərindəki nümunə məlumatlar təxminən 13 MB ilə kifayətləndi.

Düzgün qiymətləndirmə üçün vacibdir: təxmin əlavə qiymət siyahısı və ya ölkə variantlarını saymır. Onlardan çox istifadə edən müəyyən ehtiyat nəzərə almalıdır. Və bir də: çox kiçik RAM büdcəsi avtomatikanın fayllarda qalmasının ən çox rast gəlinən səbəbidir – operativ yaddaşın çatışmaması deyil. İdarə paneli bu halda məhz bu sətri göstərir.

Dəyişikliklər və tərcümələr keşi təmizləyir

Keş yalnız heç vaxt köhnəlmiş səhifə təqdim etmədikdə yararlıdır. Sırf vaxt limiti («hər on iki saatdan bir at») çox kobud olardı: dəyişdirilmiş qiymət və ya düzəldilmiş yazı xətası on iki saata qədər gözləməli olardı. Ona görə modul məzmuna əsasən işləyir.

Etibarsızlaşdırma prosesi: dəyişiklik, verilənlər bazası triggeri, dəyişiklik jurnalı, müqayisə, səhifə atılır, növbəti sorğuda yenidən render

  1. Verilənlər bazası triggerləri: səhifəyə təsir edə bilən bütün cədvəllərdə (məhsullar, variantlar, şəkillər, ehtiyat, atributlar, kateqoriyalar, qiymətlər, vergilər, qiymət siyahıları, bloq məqalələri və teqlər, tərəfdaş və şirkət məlumatları, görünüşlər, aktivlər, menyular, dillər, veb-sayt parametrləri) PostgreSQL triggerləri var. Onlar hər dəyişikliyi dəyişiklik jurnalına yazır.
  2. Asılılıqlar və verilənlər bazası vəziyyəti: hər keşlənmiş səhifə hansı qeydləri göstərdiyini və hansı verilənlər bazası vəziyyəti ilə yaradıldığını yadda saxlayır.
  3. Müqayisə: həmin vəziyyətdən sonra yaranmış və bu qeydlərdən birinə aid jurnal qeydi varsa, səhifə köhnəlmişdir.
  4. Yenidən keşləmə: növbəti sorğuda köhnəlmiş səhifə atılır, yenidən render olunur və təzədən saxlanılır.

Tərcümələr də əhatə olunur

Odoo 19 tərcümə olunmuş mətnləri orijinal mətnlə eyni qeyddə (JSON sahəsi kimi) saxlayır. Dəyişdirilmiş tərcümə verilənlər bazası üçün sıradan bir sətir dəyişikliyidir – və trigger onu görür. Bu, interfeys vasitəsilə redaktə üçün, importlar üçün, interfeyslər üçün və birbaşa verilənlər bazasına yazan skriptlər üçün eyni dərəcədə keçərlidir. 46 dilə avtomatik tərcümə beləliklə, məhz mətni dəyişən səhifələri etibarsız edir, artıq heç nəyi.

  • Ümumi deyil, məqsədyönlü: dəyişdirilmiş məhsul öz səhifələrini, içində olduğu siyahıları və aid kateqoriyanı etibarsız edir. Qalanı keşdə qalır.
  • Qlobal dəyişikliklər (şablonlar, aktivlər, dillər, menyular, vergilər, valyutalar) hər səhifəyə təsir edə biləcəyi üçün hər şeyi birdən etibarsız edir.
  • Sayğaclar kənarda qalır: bloq məqalələrinin baxış sayğacı hər ziyarətdə dəyişir; o, qəsdən etibarsızlaşdırmaya səbəb olmur, əks halda populyar məqalələrdə keş təsirsiz olardı.
  • Təhlükəsizlik şəbəkəsi: əlavə olaraq hər səhifə üçün maksimum yaş var (standart 12 saat).
  • Keş yazma xətasına səbəb olmur: trigger daxilində xəta xəbərdarlıq kimi jurnala yazılır və əsl saxlamanın uğursuz olmasına səbəb olmur.

İdarə paneli və statistika

İşləmək üçün lazım olan hər şey bir yerdədir: Odoo-da Veb-sayt → Hesabatlar → Səhifə keşi altında. İcmal bölməsi idarə panelidir (parametrlərlə birlikdə), Tarixçə bölməsi isə rəqəmləri gün və veb-sayt üzrə göstərir.

Odoo-da səhifə keşinin idarə paneli: parametrlər, vəziyyət, statistika və Operativ yaddaşa sığırmı yoxlaması

Veb-saytlarımızın surətlərinin olduğu test sistemindən ekran görüntüsü; veb-sayt adları yer tutucularla əvəz edilib.

Parametrlər

ParametrMənası
AktivƏsas açar. Söndürüldükdə Odoo yenidən hər səhifəni əvvəlki kimi təqdim edir, bütün proseslərdə ən gec 30 saniyə sonra.
Saxlama yeriAvtomatik, Fayllar və ya Operativ yaddaş
Maksimum yaş (saat)Təhlükəsizlik şəbəkəsi; səhifələr dəyişikliklərdən asılı olmayaraq bu müddətdən sonra yenilənir
RAM büdcəsi (MB)RAM keşinin tuta biləcəyi operativ yaddaşın maksimumu; eyni zamanda «sığır» qiymətləndirməsi üçün sərhəd
Disk limiti (MB)Fayl keşinin maksimum ölçüsü; ən köhnə qeydlər əvvəlcə silinir

Vəziyyət və statistika

Vəziyyət aktiv saxlama yerini limiti ilə birlikdə, keşlənmiş səhifələrin sayını və ölçüsünü və dəyişikliklərin izlənməsini göstərir: son 24 saatda neçə dəyişiklik qeydə alınıb və neçə cədvəl izlənir. İzləmə çatışmırsa, idarə paneli aydın şəkildə xəbərdarlıq edir, çünki onda keşə etibar etmək olmaz. Yuxarıdakı düymələr xidməti dərhal icra etməyə, keşi təmizləməyə və ya triggerləri yoxlayıb lazım olduqda yenidən yaratmağa imkan verir.

Statistikaya (Bu gün, 7 gün, 30 gün) aşağıdakılar daxildir:

  • Keşdən və Render edilib: uğurlu və buraxılmış sorğular, onlardan uğur faizi
  • Silinib (dəyişdirilib/vaxtı bitib): neçə səhifənin dəyişiklik və ya müddətin bitməsi səbəbilə atıldığı
  • Render vaxtı və keş vaxtı: bir səhifə üzrə orta müqayisədə
  • Təxmini qənaət edilmiş server vaxtı və keşdən verilən məlumat həcmi

Rəqəmləri hər iş prosesi ayrıca toplayır və dəqiqədə bir dəfə yazır; 90 gündən köhnə sətirləri xidmət tapşırığı təmizləyir.

Qrafik, pivot və siyahı şəklində tarixçə

Tarixçə altında hər veb-sayt üzrə gündəlik dəyərlər mövcuddur – qrafik, pivot cədvəl və ya siyahı kimi. Beləliklə, yenidən başlatmadan və ya böyük dəyişiklikdən sonra uğur faizinin yenidən artıb-artmadığını və hansı veb-saytın keşdən ən çox trafik aldığını görürsünüz.

Hər veb-sayt üzrə uğurlu, buraxılmış və atılmış səhifələrlə pivot cədvəl kimi səhifə keşi tarixçəsi

Təhlükəsizlik: nə heç vaxt keşdən verilmir

Səhifə keşi heç vaxt kiminsə başqasının məzmununu görməsinə səbəb olmamalıdır. Buna görə modul bu prinsiplə hərəkət edir: şübhə olduqda keşləmə.

  • Yalnız anonim ziyarətçilər: sistemə daxil olan, səbəti olan və ya başqa sessiya vəziyyəti gətirən hər kəs həmişə normal render edilmiş səhifəni alır.
  • Yalnız axtarış parametrləri olmayan GET: axtarışlar, filtrlər, çeşidləmələr, formalar, səbət və ödəniş toxunulmaz qalır.
  • Yalnız status 200 və HTML: xəta səhifələri, yönləndirmələr və fayllar saxlanılmır.
  • Keşdə sessiya ID-ləri yoxdur: sessiya ID-si olan və ya kuki təyin edən səhifə saxlanılmır (və xəbərdarlıq kimi jurnala yazılır).
  • Hər sorğu üçün CSRF tokeni: keşlənmiş səhifədəki token yer tutucudur və hər təqdimatda yenidən daxil edilir.
  • İncə açar: veb-sayt, dil, qiymət siyahısı, vergi mövqeyi və kuki razılığı keş açarının hissəsidir; fərqli şey görən başqa qeyd alır.
  • Bir neçə verilənlər bazası: hər verilənlər bazasının öz qeydləri, öz jurnalı və öz statistikası var.
  • Məlumat sızması yoxdur: keş serverdə lokal yerləşir (fayl və ya RAM). Üçüncü tərəflərə heç bir məlumat ötürülmür.

Axtarış sistemləri və Sİ indeksatorları: heç nə bloklanmır

Bəzi operatorlar krouler yükünə blokla cavab verir. Bu serveri qoruyur, lakin görünürlüyə başa gəlir. Modul əks yolu seçir:

  • Hamı üçün eyni məzmun: axtarış sistemləri, Sİ indeksatorları və ziyarətçilər eyni səhifəni alır. Ayrıca «krouler versiyası» yoxdur və brauzer identifikatoru üzrə tanıma yoxdur.
  • Daha sürətli cavablar indekslənməyə kömək edir: 500 yox, 20 millisaniyəyə cavab verən səhifə crawl büdcəsini daha az yükləyir və kroulerlər eyni vaxtda daha çox səhifəni əhatə edə bilir.
  • Aktual məzmun: dəyişikliklər səhifələri dərhal etibarsız etdiyinə görə, kroulerlər heç vaxt köhnə versiyanı görmür – axtarış və Sİ cavabları üçün məzmunu qoruyursunuzsa, bu vacibdir.
  • Strukturlaşdırılmış məlumatlar qorunur: JSON-LD, meta məlumatlar və hreflang istinadları keşlənmiş səhifənin hissəsidir; sayt xəritələrinə və fayllara keş toxunmur.

Əlavə olaraq yükü məhdudlaşdırmaq istəyirsinizsə, bu ayrı bir qərardır və onu şüurlu şəkildə verə bilərsiniz – modul bunu sizə tətbiq etmir.

HTML-in minimallaşdırılması və sıxılmış təqdimatı

Keş yalnız hesablama vaxtına deyil, həm də məlumat həcminə qənaət edir. Modul HTML-i saxlamazdan əvvəl minimallaşdırır və brauzer və ya krouler dəstəkləyəndə sıxılmış şəkildə təqdim edir:

  • Minimallaşdırma (parametr website_page_cache.minify): HTML şərhləri düşür, boşluqlar birləşdirilir. Tam silinmə yalnız brauzerin onsuz da nəzərə almadığı yerlərdə, məsələn blok elementləri arasında baş verir. Sətir daxili elementlər arasındakı məsafələr qalır, pre, textarea və skriptlər dəyişməz qalır, strukturlaşdırılmış məlumatlar (JSON-LD) yığcam şəkildə yenidən yazılır. Səhifədən asılı olaraq səhifələr 10-30 % kiçilir. Yeddi real səhifə ilə sınaqda mətn, element sayı, bütün elementlərin mövqeyi və ekran görüntüsü orijinalla eyni idi. İlk təqdimat (MISS) sonrakı hər təqdimat (HIT) kimi minimallaşdırılmışdır.
  • Sıxma (parametr website_page_cache.compress): keşdən gələn səhifələr gzip ilə göndərilir (Content-Encoding: gzip, Vary: Accept-Encoding). Böyük aktiv paketlərini (CSS və JavaScript, bir neçə MB-a qədər) Odoo özü sıxılmamış təqdim edir; modul onları bir dəfə sıxır, surəti diskdə saxlayır və sonra birbaşa təqdim edir. Beləliklə, 2,1 MB CSS 0,27 MB, 4,8 MB JavaScript isə 1,1 MB oldu. Köhnə surətləri xidmət tapşırığı təmizləyir.
  • Kompüterin yenidən başladılmasından sonra: RAM keşi Odoo-nun yenidən başladılması zamanı qorunur, lakin serverin yenidən başladılması zamanı qorunmur. Ona görə xidmət tapşırığı onu mərhələli şəkildə diskə əks etdirir (parametr website_page_cache.persist) və başlanğıcda bərpa edir. Bərpa olunmuş qeydin hələ də etibarlı olub-olmadığını həmişəki mexanizm yoxlayır: yaş və dəyişiklik jurnalı. Minimallaşdırma bu zaman yenidən hesablanmır.

Quraşdırma və parametrlər

  1. Modulu əldə edin: mənbə kodunu GitHub-dan yükləyin və Odoo 19 quraşdırmanızın addons yoluna qoyun: github.com/Alex0176/odoo-website-page-cache
  2. Quraşdırın: odoo-bin -d <Datenbank> -i website_page_cache --stop-after-init. Bu zaman dəyişiklik jurnalı, triggerlər və xidmət tapşırığı (hər 10 dəqiqədən bir) yaranır.
  3. Xidməti yenidən başladın, ki, bütün iş prosesləri modulu yükləsin.
  4. İdarə panelini açın: Veb-sayt → Hesabatlar → Səhifə keşi. Dəyişikliklərin izlənməsinin tam olub-olmadığını yoxlayın və saxlama yerini seçin (standart: avtomatik).
  5. Yoxlayın: mağaza və ya bloq səhifəsini iki dəfə açın və X-Page-Cache başlığına baxın: ilk dəfə MISS, sonra HIT.

Parametrlər sistem parametrləri kimi mövcuddur (website_page_cache.enabled, .backend, .ttl_hours, .max_mb_file, .max_mb_ram) və adətən idarə panelində idarə olunur. Modul alman dilinə tərcümə edilib. Silmə triggerləri, jurnalı və bütün keşlənmiş səhifələri yenidən tam şəkildə aradan qaldırır.

RAM keşi üçün məsləhət: idarə panelindəki RAM büdcəsi və tmpfs-in ölçüsü (/dev/shm, qoşulma seçimi size=) ehtiyaca uyğun olmalıdır. Hər ikisini «Operativ yaddaşa sığırmı?» yoxlaması konkret dəyərlərlə bildirir.

Bilməli olduğunuz məhdudiyyətlər

  • Dəyişikliklərdən sonra qısa gecikmə: dəyişiklik jurnalının indeksi hər iki saniyədən bir yenilənir. O vaxta qədər dəyişdirilmiş səhifə hələ köhnə versiyada təqdim oluna bilər.
  • Ehtiyatdan asılı mətnlər ehtiyat dəyişiklikləri və maksimum yaş vasitəsilə yenilənir.
  • Yer ehtiyacının təxmini: qiymət siyahısı və ya ölkə üzrə əlavə versiyalar nəzərə alınmır; müəyyən ehtiyat planlaşdırın.
  • Hər şeyin əvəzi deyil: keş xidmət edə biləcəyi sorğuların yükünü azaldır. Daxil olmuş istifadəçilər, axtarışlar və formalar yenə Odoo-dan keçir.
  • İlk sorğu yavaş qalır: serverin yenidən başladılmasından (RAM) və ya qlobal dəyişiklikdən sonra hər səhifə keşə düşməzdən əvvəl bir dəfə normal render edilir.

Tez-tez verilən suallar

Odoo üçün səhifə keşi nədir?

Açıq mənbəli modul (website_page_cache, Odoo 19, LGPL-3) anonim ziyarətçilər üçün açıq mağaza və bloq səhifələrini hər sorğuda yenidən render etmək əvəzinə keşdən təqdim edir. Keş seçimə görə fayllarda və ya operativ yaddaşda yerləşir.

Modul axtarış sistemlərini və ya Sİ kroulerlərini bloklayırmı?

Xeyr. Axtarış sistemləri və Sİ indeksatorları hər hansı digər ziyarətçi ilə eyni səhifələri alır, sadəcə daha sürətli. Nə blok, nə məhdudiyyət, nə də ayrıca krouler versiyası var.

Dəyişdirilmiş səhifələr və tərcümələr avtomatik yenidən keşlənirmi?

Bəli. PostgreSQL triggerləri aidiyyatı cədvəllərdəki hər dəyişikliyi jurnala bildirir; təsirlənən səhifələr atılır və növbəti sorğuda yenidən render olunub saxlanılır. Tərcümələr əhatə olunur, çünki Odoo 19 onları eyni qeyddə saxlayır.

Fayl, yoxsa RAM seçməliyəm?

Adətən Avtomatik: modul bütün səhifələr sığdıqca RAM-dan istifadə edir, əks halda fayllara keçir. Keşin yenidən başlatmalardan sağ çıxması lazımdırsa və ya RAM azdırsa, fayllar uyğundur; RAM ən sürətli variantdır.

Veb-saytımın operativ yaddaşa sığıb-sığmadığını necə öyrənim?

İdarə panelində Veb-sayt → Hesabatlar → Səhifə keşi altında. «Operativ yaddaşa sığırmı?» bölməsi səhifələri hər veb-sayt və dil üzrə sayır, səhifə ölçüsünü ölçür və ehtiyacı RAM büdcəsi, tmpfs ölçüsü və mövcud yaddaşla müqayisə edir.

RAM keşi üçün əlavə nə qədər RAM lazımdır?

İdarə paneli bunu ayrıca sətir kimi göstərir. Hesablama: ehtiyac = səhifələr × səhifə ölçüsü; təhlükəsizlik ehtiyatı ilə 0,8-ə bölünür. Keş mövcud yaddaşın ən çoxu yarısını istifadə edə bildiyinə görə, bunun iki misli lazım olan boş yaddaşdır; fərq əlavə RAM-dır. Yalnız RAM büdcəsi və ya tmpfs çox kiçikdirsə, idarə paneli parametri hədəf dəyəri ilə birlikdə göstərir.

Keş kiməsə başqasının məzmununu göstərə bilərmi?

Xeyr. Yalnız axtarış parametrləri olmayan anonim GET sorğuları üçün keşlənir. Daxil olmuş istifadəçilər, səbətlər, formalar və axtarışlar heç vaxt keşdən gəlmir; dil, qiymət siyahısı, vergi mövqeyi və kuki razılığı açarın hissəsidir.

Keşi təcili halda necə söndürüm?

İdarə panelində «Aktiv» açarını söndürün və ya website_page_cache.enabled sistem parametrini 0 edin. Bu, bütün iş proseslərində ən gec 30 saniyə sonra qüvvəyə minir. Silmə də triggerləri, jurnalı və keşlənmiş səhifələri aradan qaldırır.

Səhifənin keşdən gəldiyini necə bilim?

X-Page-Cache cavab başlığına görə: HIT keşdən deməkdir, MISS təzə render edilib və saxlanılıb deməkdir.

Modul HTML-i kiçildirmi və sıxırmı?

Bəli. Keşlənmiş səhifələr mühafizəkar şəkildə minimallaşdırılır (şərhlər və artıq boşluqlar düşür, məzmun və görünüş eyni qalır) və keş uğurlarında gzip ilə təqdim olunur; aktiv paketləri bir dəfə sıxılır və diskdən təqdim edilir. Hər ikisini website_page_cache.minify və website_page_cache.compress parametrləri ilə söndürmək olar.

Biricon IT Services tərəfindən dəstək

Odoo veb-saytınız krouler yükü altında ləng cavab verir, yoxsa mağaza və bloqunuzu daha sürətli və daha görünən etmək istəyirsiniz? Odoo veb-saytınızın yükünün təhlilində, səhifə keşinin qurulmasında, operativ yaddaş və iş proseslərinin ölçüləndirilməsində və çoxdilli axtarış sistemi optimallaşdırmasında sizə dəstək oluruq. Modulun mənbə kodunu GitHub-da tapa bilərsiniz.

İndi bizimlə əlaqə saxlayın

Vəziyyət: 10 noyabr 2026. Ölçülmüş dəyərlər nümunə məlumatları olan test sistemindən götürülüb və digər quraşdırmalar üçün zəmanət deyil.