Кеш на страниците за Odoo: магазин и блог от RAM или файл – бързи за посетители, търсачки и AI

10 ноември 2026  |  Собствена разработка  |  Odoo, производителност и търсачки

Един уебсайт на Odoo генерира всяка страница отново при всяко извикване: заявки към базата данни, шаблони, преводи, цени. За един-единствен посетител това е незабележимо. Но когато търсачки и AI индексатори извличат стотици или хиляди страници на много езици, това се превръща в постоянно натоварване и истинските клиенти трябва да чакат. Затова разработихме модула за Odoo 19 website_page_cache и го публикувахме в GitHub като Open Source (LGPL-3): страниците на магазина и блога, извиквани анонимно, се отдават почти като статични от кеш – или от файлове, или от оперативната памет (RAM), а всяка промяна – включително на превод – автоматично премахва засегнатите страници от кеша.

Важно за всички, които искат да бъдат намирани: модулът не блокира нито една търсачка и нито един AI робот. Всички индексатори получават същото съдържание като всеки посетител, само че по-бързо. Тази статия обяснява как работи кешът, как изглежда таблото (със снимки на екрана), как да разберете, дали страниците ви се събират в оперативната памет и колко допълнителна RAM би била необходима, какви правила за сигурност важат и как да инсталирате модула.

Накратко

Проблемът: натоварване от роботи върху уебсайтове на Odoo

Odoo е цялостна ERP система, а уебсайтът е един от многото ѝ модули. Всяка страница, която извиква посетител или робот, минава по един и същ път: обработка на заявката, запитване към базата данни, зареждане на данни за продукти и цени, рендиране на QWeb шаблона, вмъкване на преводи и предоставяне на резултата. В зависимост от страницата това отнема няколкостотин милисекунди и през това време заема един от малкото работни процеси.

За търсачките и AI индексаторите това е постоянен проблем:

• Много езици, много адреси: страница, налична на 46 езика, за един робот са 46 различни адреса.
• Всеки адрес се извлича поотделно, често от много разпределени източници едновременно. Класическият кеш на браузъра тук не помага, защото всяко извличане засяга нов адрес.
• Малко работни процеси: една услуга на Odoo обикновено работи с шепа процеси. Когато са заети със заявки от роботи, истинските посетители чакат на опашка.
• Същото съдържание, отново и отново: една статия в блога се променя рядко, но при всяко извикване се сглобява наново с големи усилия.

Очевидният изход – да се блокират роботите – не е вариант за фирма, която иска да бъде намирана. Видимостта в търсачките и в отговорите на AI е ценна. По-добре е страниците да се предоставят толкова бързо, че натоварването почти да не се усеща. Точно това прави кешът на страниците.

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

Модулът се включва във входа за заявки на Odoo (ir.http). При всяко извикване на страница той за части от милисекундата решава дали страницата може да дойде от кеша и тогава я предоставя без база данни, без шаблон и без рендиране.

1. Проверка: идва предвид само анонимно GET-извикване без параметри за търсене към разрешен път (магазин, категории, продукти, блог). Всичко останало минава през Odoo както обикновено.
2. Ключ на кеша: състои се от уебсайт, клас на хоста, език, път, ценова листа, данъчна позиция и състояние на съгласието за бисквитки. Затова посетители, които биха видели нещо различно, никога не споделят един запис. Хостът се нормализира: Odoo винаги изписва абсолютните адреси от домейна на уебсайта, а не от заявката; адресът на заявката решава само дали страницата се счита за основен адрес (езикови препратки) и дали да бъде индексирана. Всички чужди имена на хостове затова споделят един запис заедно с указанието noindex, вместо да заемат по едно свое копие.
3. Попадение: ако има актуален запис, той се предоставя. CSRF токенът в страницата се задава наново при всяка заявка. Извикванията на статии в блога продължават да се отчитат.
4. Пропуск: ако записът липсва или е остарял, Odoo рендира страницата по обичайния начин. Ако резултатът може да се кешира (статус 200, HTML, без бисквитка, без идентификатор на сесия в текста), той се записва; следващото извикване е попадение.
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) таблица или като списък. Така виждате дали процентът попадения отново расте след рестартиране или голяма промяна и кой уебсайт получава най-много трафик от кеша.

Сигурност: какво никога не идва от кеша

Кешът на страници никога не бива да води до това, че някой вижда съдържанието на друг. Затова модулът следва принципа: при съмнение не кеширай.

• Само анонимни посетители: който е влязъл в профила си, има количка или носи друго състояние на сесията, винаги получава нормално рендираната страница.
• Само GET без параметри за търсене: търсения, филтри, сортирания, формуляри, количка и каса остават недокоснати.
• Само статус 200 и HTML: страници с грешки, пренасочвания и файлове не се записват.
• Без идентификатори на сесии в кеша: страница, която съдържа идентификатор на сесия или задава бисквитка, не се записва (и се отбелязва като предупреждение).
• CSRF токен за всяка заявка: токенът в кешираната страница е заместител и се вмъква наново при всяко предоставяне.
• Фин ключ: уебсайтът, езикът, ценовата листа, данъчната позиция и съгласието за бисквитки са част от ключа на кеша; който вижда нещо различно, получава друг запис.
• Няколко бази данни: всяка база данни има свои записи, свой журнал и своя статистика.
• Без изтичане на данни: кешът се намира локално на сървъра (файл или RAM). Никакви данни не се предават на трети страни.

Търсачки и AI индексатори: нищо не се блокира

Някои оператори реагират на натоварването от роботи с блокиране. Това защитава сървъра, но струва видимост. Модулът тръгва по обратния път:

• Еднакво съдържание за всички: търсачките, AI индексаторите и посетителите получават една и съща страница. Няма отделна „версия за роботи“ и няма разпознаване по идентификатор на браузъра.
• По-бързите отговори помагат на индексирането: страница, която отговаря за 20, а не за 500 милисекунди, натоварва по-малко бюджета за обхождане (crawl budget) и роботите могат да обхванат повече страници за същото време.
• Актуално съдържание: тъй като промените обезсилват страниците веднага, роботите никога не виждат остаряла версия – важно, ако поддържате съдържание за търсене и отговори на AI.
• Структурираните данни се запазват: 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?

Open Source модул (website_page_cache, Odoo 19, LGPL-3), който предоставя публични страници на магазина и блога за анонимни посетители от кеш, вместо да ги рендира наново при всяко извикване. Кешът се намира по избор във файлове или в оперативната памет.

Блокира ли модулът търсачки или AI роботи?

Не. Търсачките и AI индексаторите получават същите страници като всеки друг посетител, само по-бързо. Няма блокиране, няма ограничаване и няма отделна версия за роботи.

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

Да. 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. Измерените стойности идват от тестова система с примерни данни и не са гаранция за други инсталации.