Кеш на страници за Odoo: продавница и блог од RAM или датотека – брзо за посетители, пребарувачи и ИИ

10 ноември 2026  |  Сопствен развој  |  Odoo, перформанси и пребарувачи

Една Odoo веб-страница ја генерира секоја страница одново при секое отворање: барања до базата на податоци, шаблони, преводи, цени. За еден посетител тоа е незабележливо. Но кога пребарувачите и ИИ индексаторите ќе побараат стотици или илјадници страници на многу јазици, тоа станува трајно оптоварување, а заедно со нив чекаат и вистинските клиенти. Затоа го развивме модулот website_page_cache за Odoo 19 и го објавивме на GitHub како отворен код (LGPL-3): анонимно отворените страници од продавницата и блогот се испорачуваат речиси како статични од кеш – или од датотеки или од работна меморија (RAM), а секоја промена – вклучително и на превод – ги отстранува засегнатите страници автоматски од кешот.

Важно за сите што сакаат да бидат пронајдени: модулот не блокира ниту еден пребарувач ниту еден ИИ-робот за индексирање. Сите индексатори ја добиваат истата содржина како секој посетител, само побрзо. Овој напис објаснува како работи кешот, како изгледа контролната табла (со слики од екран), како да препознаете дали вашите страници се собираат во работната меморија и колку дополнителна RAM би била потребна, кои безбедносни правила важат и како се инсталира модулот.

Накратко

Проблемот: оптоварување од роботи за индексирање на Odoo веб-страници

Odoo е целосен ERP-систем, а веб-страницата е еден од многуте модули. Секоја страница што ја отвора посетител или робот го поминува истиот пат: се обработува барањето, се прашува базата на податоци, се вчитуваат податоци за производи и цени, се рендерира QWeb-шаблонот, се вметнуваат преводите и се испорачува резултатот. Во зависност од страницата, тоа трае неколку стотици милисекунди и за тоа време зафаќа еден од малкуте работни процеси.

За пребарувачите и ИИ индексаторите тоа е трајна тема:

• Многу јазици, многу адреси: Страница што постои на 46 јазици за роботот за индексирање е 46 различни адреси.
• Секоја адреса се бара поединечно, често истовремено од многу распоредени испраќачи. Класичен кеш на прелистувачот тука не помага, бидејќи секое барање се однесува на нова адреса.
• Малку работни процеси: Odoo-услугата обично работи со неколку процеси. Ако се зафатени со барања од роботи, вистинските посетители чекаат на ред.
• Иста содржина, постојано одново: Еден напис на блогот се менува ретко, но при секое отворање се составува одново со голем напор.

Очигледниот излез – да се исклучат роботите – за фирма што сака да биде пронајдена не е опција. Видливоста во пребарувачите и во одговорите на ИИ е вредна. Подобро е страниците да се испорачуваат толку брзо што оптоварувањето речиси веќе не се чувствува. Токму тоа го прави кешот на страници.

Како работи кешот на страници

Модулот се закачува на влезот за барања на Odoo (ir.http). При секое отворање на страница, за дел од милисекунда одлучува дали страницата смее да дојде од кешот и тогаш ја испорачува без база на податоци, без шаблон и без рендерирање.

1. Проверка: Во предвид доаѓа само анонимно GET-барање без параметри за пребарување на дозволена патека (продавница, категории, производи, блог). Сè друго минува како и обично низ Odoo.
2. Клуч на кешот: Се состои од веб-страница, класа на хост, јазик, патека, ценовник, даночна позиција и статус на согласност за колачиња. Затоа посетителите што би виделе нешто друго никогаш не делат ист запис. Хостот при тоа се нормализира: Odoo апсолутните адреси ги пишува секогаш од доменот на веб-страницата, а не од барањето; адресата од барањето одлучува само дали страницата важи како главна адреса (јазични врски) и дали треба да се индексира. Сите туѓи имиња на хостови затоа делат еден запис заедно со noindex-напомена, наместо секое да зафаќа своја копија.
3. Погодок: Ако има актуелен запис, тој се испорачува. CSRF-токенот во страницата при тоа се поставува одново за секое барање. Отворањата на написите на блогот и понатаму се броjат.
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 KB) е помош за пресметка, а не мерење на нашите страници. За мали веб-страници доволни се неколку десетици мегабајти; примерните податоци на сликите од екран се снајдоа со околу 13 MB.

Важно за подредување: проценката не брои дополнителни верзии по ценовник или земја. Кој користи многу такви, нека планира малку резерва. И уште: премал RAM-буџет е најчестата причина автоматиката да остане на датотеки – а не недостигот на работна меморија. Контролната табла во тој случај го прикажува токму тој ред.

Промените и преводите го чистат кешот

Кешот е употреблив само ако никогаш не испорачува застарени страници. Чисто временско ограничување („отфрли на секои дванаесет часа“) би било премногу грубо: променета цена или поправена печатна грешка би чекала до дванаесет часа. Затоа модулот работи според содржината.

1. Тригери на базата на податоци: На сите табели што можат да влијаат на страница (производи, варијанти, слики, залихи, атрибути, категории, цени, даноци, ценовници, написи на блогот и клучни зборови, податоци за партнери и фирми, прикази, ресурси, менија, јазици, поставки на веб-страницата) стојат PostgreSQL-тригери. Тие секоја промена ја впишуваат во дневник на промени.
2. Зависности и состојба на базата на податоци: Секоја кеширана страница помни кои записи ги прикажува и со која состојба на базата на податоци е создадена.
3. Споредба: Ако има запис во дневникот што настанал по таа состојба и се однесува на еден од тие записи, страницата е застарена.
4. Повторно кеширање: При следното отворање застарената страница се отфрла, се рендерира одново и повторно се зачувува.

Преводите се исто така опфатени

Odoo 19 ги чува преведените текстови во истиот запис како и оригиналниот текст (како JSON-поле). Променет превод за базата на податоци е затоа сосема обична промена на ред – и тригерот ја гледа. Тоа важи подеднакво за уредување преку интерфејсот, за увози, за интерфејси и за скрипти што пишуваат директно во базата. Автоматски превод на 46 јазици ги поништува токму страниците чиј текст се променил, и ништо повеќе.

• Таргетирано, а не паушално: Променет производ ги поништува неговите страници, списоците во кои се наоѓа и припаѓачката категорија. Останатото останува во кешот.
• Глобални промени (шаблони, ресурси, јазици, менија, даноци, валути) поништуваат сè одеднаш, бидејќи можат да влијаат на секоја страница.
• Бројачите остануваат надвор: Бројачот на прикази на написите на блогот се менува при секоја посета; тој намерно не предизвикува поништување, инаку кешот би бил бескорисен за популарните написи.
• Безбедносна мрежа: Дополнително постои максимална старост по страница (стандардно 12 часа).
• Никаква грешка при запишување поради кешот: Грешка во тригер се запишува како предупредување и не го прекинува самото зачувување.

Контролна табла и статистика

Сè што ви треба за работа е на едно место: во Odoo под Веб-страница → Извештаи → Кеш на страници. Делот Преглед е контролната табла (со поставките), делот Историја ги прикажува броевите по ден и веб-страница.

Слика од екран од тест-систем со копии на нашите веб-страници; имињата на веб-страниците се заменети со местодржачи.

Поставки

Статус и статистика

Статусот го прикажува активното место за чување со границата, бројот и големината на кешираните страници и следењето на промените: колку промени се регистрирани во последните 24 часа и колку табели се следат. Ако недостасува следење, контролната табла јасно предупредува, бидејќи тогаш на кешот не смее да му се верува. Копчињата горе овозможуваат веднаш да се изврши одржувањето, да се испразни кешот или да се проверат тригерите и по потреба да се создадат одново.

Статистиката (Денес, 7 дена, 30 дена) содржи:

• Од кешот и Рендерирано: погодоци и промашувања, од нив стапка на погодоци
• Отстрането (променето/истечено): колку страници се отфрлени поради промена или истек
• Време на рендерирање и време од кешот: просекот по страница во споредба
• Проценето заштедено време на серверот и количина на податоци од кешот

Броевите ги собира секој работен процес за себе и ги запишува еднаш во минута; редовите постари од 90 дена ги чисти работата за одржување.

Историја како дијаграм, pivot и список

Под Историја се достапни дневните вредности по веб-страница – како дијаграм, како pivot-табела или како список. Така гледате дали стапката на погодоци по рестарт или по голема промена повторно расте и која веб-страница добива најмногу сообраќај од кешот.

Безбедност: што никогаш не доаѓа од кешот

Кешот на страници никогаш не смее да доведе до тоа некој да ја види содржината на друг. Затоа модулот постапува по принципот: во сомнеж не кеширај.

• Само анонимни посетители: Кој е најавен, има кошничка или носи друга состојба на сесија, секогаш ја добива нормално рендерираната страница.
• Само GET без параметри за пребарување: Пребарувањата, филтрите, сортирањата, формуларите, кошничката и наплатата остануваат недопрени.
• Само статус 200 и HTML: Страниците со грешка, пренасочувањата и датотеките не се зачувуваат.
• Без ID на сесии во кешот: Страница што содржи ID на сесија или поставува колаче не се зачувува (и се запишува како предупредување).
• CSRF-токен по барање: Токенот во кешираната страница е местодржач и при секоја испорака се вметнува одново.
• Фин клуч: Веб-страница, јазик, ценовник, даночна позиција и согласност за колачиња се дел од клучот на кешот; кој гледа нешто друго, добива друг запис.
• Повеќе бази на податоци: Секоја база на податоци има свои записи, свој дневник и своја статистика.
• Без истекување на податоци: Кешот е локално на серверот (датотека или RAM). Никакви податоци не се пренесуваат на трети лица.

Пребарувачи и ИИ индексатори: ништо не се блокира

Некои оператори на оптоварување од роботи реагираат со блокади. Тоа го штити серверот, но чини видливост. Модулот го избира спротивниот пат:

• Иста содржина за сите: Пребарувачите, ИИ индексаторите и посетителите ја добиваат истата страница. Нема посебна „верзија за роботи“ и нема препознавање според идентификаторот на прелистувачот.
• Побрзите одговори му помагаат на индексирањето: Страница што одговара за 20 наместо за 500 милисекунди помалку го оптоварува буџетот за индексирање, а роботите за исто време можат да опфатат повеќе страници.
• Актуелна содржина: Бидејќи промените веднаш ги поништуваат страниците, роботите никогаш не гледаат застарена верзија – важно е ако одржувате содржини за пребарување и одговори на ИИ.
• Структурираните податоци се задржуваат: JSON-LD, мета-податоците и hreflang-упатувањата се дел од кешираната страница; мапите на страницата и датотеките кешот не ги допира.

Ако дополнително сакате да го ограничите оптоварувањето, тоа е посебна одлука што можете свесно да ја донесете – модулот не ви ја наметнува.

Намалување на HTML и компримирана испорака

Кешот не штеди само време за пресметување, туку и обем на податоци. Модулот го намалува HTML-от пред да го зачува и го испорачува компримиран, ако прелистувачот или роботот тоа го поддржуваат:

• Намалување (параметар website_page_cache.minify): HTML-коментарите отпаѓаат, празниот простор се спојува. Целосно се отстранува само таму каде прелистувачот и онака го игнорира, на пример меѓу блок-елементи. Растојанијата меѓу inline-елементите остануваат, pre, textarea и скриптите остануваат непроменети, структурираните податоци (JSON-LD) се препишуваат компактно. Во зависност од страницата, страниците се 10–30 % помали. При тестот со седум вистински страници, текстот, бројот на елементи, позицијата на сите елементи и сликата од екран беа идентични со оригиналот. Првата испорака (MISS) е минимизирана исто како и секоја следна (HIT).
• Компримирање (параметар website_page_cache.compress): Страниците од кешот излегуваат преку gzip (Content-Encoding: gzip, Vary: Accept-Encoding). Големите пакети ресурси (CSS и JavaScript, до неколку MB) Odoo ги испорачува некомпримирани; модулот ги компримира еднаш, ја става копијата на дискот и потоа ја испорачува директно. Од 2,1 MB CSS така станаа 0,27 MB, од 4,8 MB JavaScript 1,1 MB. Старите копии ги чисти работата за одржување.
• По рестарт на компјутерот: RAM-кешот останува при рестарт на Odoo, но не и при рестарт на серверот. Затоа работата за одржување постепено го огледува на дискот (параметар website_page_cache.persist) и го враќа при стартување. Дали вратениот запис сè уште важи го проверува истиот механизам како инаку: старост и дневник на промени. Минимизирањето при тоа не се пресметува одново.

Инсталација и поставки

1. Преземете го модулот: изворниот код преземете го од GitHub и ставете го во addons-патека на вашата Odoo 19 инсталација: 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; пакетите ресурси се компримираат еднаш и се испорачуваат од дискот. Двете може да се исклучат преку параметрите website_page_cache.minify и website_page_cache.compress.

Поддршка од Biricon IT Services

Вашата Odoo веб-страница реагира бавно при оптоварување од роботи, или сакате продавницата и блогот да ги направите побрзи и повидливи? Ве поддржуваме при анализата на оптоварувањето, при поставувањето на кешот на страници, при димензионирањето на работната меморија и работните процеси и при повеќејазичната оптимизација за пребарувачи на вашата Odoo веб-страница. Изворниот код на модулот ќе го најдете на GitHub.

Јавете ни се сега

Состојба: 10 ноември 2026. Измерените вредности потекнуваат од тест-систем со примерни податоци и не се ветување за други инсталации.