Ves al contingut

Memòria cau de pàgines per a Odoo: botiga i blog des de RAM o fitxer – ràpid per a visitants, cercadors i IA

El mòdul de codi obert website_page_cache serveix les pàgines públiques d'Odoo gairebé com a estàtiques, es manté actualitzat en modificacions i traduccions i mostra al tauler si cal RAM i quanta
10 de novembre de 2026 per
Memòria cau de pàgines per a Odoo: botiga i blog des de RAM o fitxer – ràpid per a visitants, cercadors i IA

10 de novembre de 2026  |  Desenvolupament propi  |  Odoo, rendiment i cercadors

Memòria cau de pàgines per a llocs web d'Odoo: pàgines públiques de botiga i de blog des de fitxer o RAM, en lloc de renderitzar-les de nou a cada consulta

Un lloc web d'Odoo renderitza cada pàgina de nou a cada consulta: consultes a la base de dades, plantilles, traduccions, preus. Per a un sol visitant, això passa desapercebut. Però quan cercadors i indexadors d'IA sol·liciten centenars o milers de pàgines en moltes llengües, es converteix en una càrrega permanent, i els clients reals també han d'esperar. Per això hem desenvolupat el mòdul d'Odoo 19 website_page_cache i l'hem publicat a GitHub com a Open Source (LGPL-3): les pàgines de botiga i de blog consultades de manera anònima es serveixen gairebé com a estàtiques des d'una memòria cau, ja sigui des de fitxers o des de la memòria de treball (RAM), i cada modificació – també la d'una traducció – elimina automàticament de la memòria cau les pàgines afectades.

Important per a tothom qui vulgui ser trobat: el mòdul no bloqueja cap cercador ni cap rastrejador d'IA. Tots els indexadors reben els mateixos continguts que qualsevol visitant, només que més de pressa. Aquest article explica com funciona la memòria cau, quin aspecte té el tauler (amb captures de pantalla), com podeu saber si les vostres pàgines caben a la memòria de treball i quanta RAM addicional caldria, quines regles de seguretat s'apliquen i com instal·lar el mòdul.

Resum

TemaAixò s'aplica
Mòdulwebsite_page_cache per a Odoo 19, llicència LGPL-3, públic a GitHub
Què es desa a la memòria cau?Pàgines de botiga i de blog públiques (llistes, categories, productes, articles) en totes les llengües de cada lloc web
Per a qui?Només per a visitants anònims, només consultes GET sense paràmetres de cerca, només estat 200 amb HTML
Ubicació d'emmagatzematgeFitxers al disc o RAM (tmpfs, compartida per tots els processos de treball); automàtic segons l'espai necessari
ActualitatCada modificació (també traduccions, importacions, scripts) genera mitjançant disparadors de la base de dades una entrada al registre i invalida les pàgines afectades
TaulerConfiguració, estat, estadístiques (encerts, fallades, temps de servidor estalviat) i la comprovació «Hi cap a la memòria de treball?», inclosa la indicació de «RAM addicional necessària»
Cercadors i IANo es bloqueja ni es limita res; tothom rep les mateixes pàgines, només que més de pressa
Fre d'emergènciaUn interruptor (enabled = 0) desactiva la memòria cau a tots els processos de treball en 30 segons

El problema: la càrrega dels rastrejadors als llocs web d'Odoo

Odoo és un sistema ERP complet i el lloc web n'és un mòdul entre molts. Cada pàgina que sol·licita un visitant o un robot segueix el mateix camí: processar la sol·licitud, consultar la base de dades, carregar dades de productes i preus, renderitzar la plantilla QWeb, inserir les traduccions i lliurar el resultat. Segons la pàgina, això triga unes quantes centenes de mil·lisegons i durant aquest temps ocupa un dels pocs processos de treball.

Per als cercadors i indexadors d'IA això és un tema permanent:

  • Moltes llengües, moltes adreces: una pàgina disponible en 46 llengües són 46 adreces diferents per a un rastrejador.
  • Cada adreça se sol·licita per separat, sovint des de molts remitents distribuïts alhora. Una memòria cau de navegador clàssica no hi ajuda, perquè cada consulta afecta una adreça nova.
  • Pocs processos de treball: un servei d'Odoo funciona normalment amb un grapat de processos. Si estan ocupats amb sol·licituds de rastrejadors, els visitants reals esperen a la cua.
  • El mateix contingut, una vegada i una altra: un article de blog canvia poques vegades, però es torna a muntar amb molt d'esforç a cada consulta.

La sortida òbvia – bloquejar els rastrejadors – no és una opció per a una empresa que vol ser trobada. La visibilitat als cercadors i a les respostes d'IA té valor. Millor és servir les pàgines tan de pressa que la càrrega gairebé no es noti. Això és exactament el que fa la memòria cau de pàgines.

Com funciona la memòria cau de pàgines

El mòdul s'enganxa a l'entrada de sol·licituds d'Odoo (ir.http). A cada consulta de pàgina decideix, en una fracció de mil·lisegon, si la pàgina pot sortir de la memòria cau, i aleshores la serveix sense base de dades, sense plantilla i sense renderitzat.

Diagrama de flux: sol·licitud, comprovació, clau de memòria cau, encert o fallada, desament i lliurament

  1. Comprovació: només es considera una consulta GET anònima sense paràmetres de cerca en una ruta permesa (botiga, categories, productes, blog). Tota la resta passa per Odoo com sempre.
  2. Clau de memòria cau: consta del lloc web, la classe d'amfitrió, la llengua, la ruta, la tarifa, la posició fiscal i l'estat del consentiment de galetes. Els visitants que veurien una altra cosa no comparteixen mai, doncs, una entrada. L'amfitrió es normalitza: Odoo escriu sempre les adreces absolutes a partir del domini del lloc web, no de la sol·licitud; l'adreça de la sol·licitud només decideix si la pàgina compta com a adreça principal (enllaços d'idioma) i si s'ha d'indexar. Tots els noms d'amfitrió aliens comparteixen, doncs, una sola entrada amb l'avís noindex, en lloc d'ocupar cadascun una còpia pròpia.
  3. Encert: si hi ha una entrada vigent, es lliura. El testimoni CSRF de la pàgina es torna a establir a cada sol·licitud. Les consultes d'articles de blog continuen comptant-se.
  4. Fallada: si l'entrada falta o és obsoleta, Odoo renderitza la pàgina com sempre. Si el resultat es pot desar a la memòria cau (estat 200, HTML, sense galeta, sense identificador de sessió al text), es desa; la consulta següent és un encert.
  5. Visible a la capçalera: cada resposta porta la capçalera X-Page-Cache: HIT o MISS. Així es pot comprovar amb qualsevol eina què ha passat.

Quant més de pressa?

Al nostre sistema de proves (còpia dels nostres llocs web, unes quantes centenes de pàgines), el temps mitjà de renderitzat d'una pàgina va ser de uns 490 mil·lisegons i el lliurament des de la memòria cau, de uns 23 mil·lisegons: unes vint vegades més ràpid. Com més costosa és una pàgina, més gran és el guany. El tauler calcula, a partir dels dos valors, també el temps de servidor estalviat estimat.

Fitxer o RAM: triar la ubicació d'emmagatzematge

La memòria cau coneix dues ubicacions d'emmagatzematge. Totes dues són visibles en comú per a tots els processos de treball d'Odoo, de manera que cada pàgina existeix només una vegada, no una per procés.

Comparació de la memòria cau de fitxers i la memòria cau en RAM, i la regla de decisió de l'automàtic

ConfiguracióOn són les pàgines?Característiques
FitxersDirectori a la carpeta de dades d'Odoo, per base de dadessobreviu als reinicis; el sistema operatiu manté a la memòria les pàgines d'ús freqüent de totes maneres
Memòria de treballtmpfs a /dev/shmlliurament més ràpid; es perd en reiniciar el servidor i simplement es torna a construir
AutomàticRAM mentre hi càpiga tot; si no, fitxersUna tasca de manteniment (cada 10 minuts) decideix a partir de l'estimació; amb «cap» i «just» es manté a la RAM perquè l'elecció no canviï constantment

Per a la majoria d'instal·lacions, Automàtic és l'opció correcta: obteniu velocitat de RAM quan hi ha espai i, si no, torneu als fitxers sense intervenció.

Hi cap el lloc web a la memòria de treball? I quanta RAM hi falta?

Que sigui possible una memòria cau en RAM depèn de tres coses: del nombre de pàgines, de la seva mida mitjana i de la memòria disponible. El tauler ho calcula per vosaltres:

  • Nombre de pàgines: per a cada lloc web compta els productes publicats, les pàgines de llistat de la botiga, les categories, els articles de blog i els llistats de blog, i ho multiplica pel nombre de llengües.
  • Mida de la pàgina: tan bon punt hi ha pàgines a la memòria cau, es mesura la mitjana real; fins aleshores s'aplica un valor suposat.
  • Espai per a la memòria cau: el valor més petit entre el pressupost de RAM configurat, la mida del tmpfs i la meitat de la memòria de treball disponible. El servidor no ha de quedar mai sense memòria per culpa de la memòria cau.
  • Veredicte: «hi cap amb reserva», «just», «massa gran» o «memòria cau en RAM no disponible». «Hi cap» s'aplica quan la necessitat és, com a màxim, el 80 per cent de l'espai disponible.

Secció del tauler Hi cap a la memòria de treball? amb el nombre de pàgines per lloc web, l'espai necessari i la indicació de la RAM addicional necessària

Novetat: quanta RAM addicional caldria?

Si la memòria cau no hi cap, cal saber què s'ha de canviar. Per això el tauler indica, sota el veredicte, una línia concreta: «RAM addicional per a una memòria cau en RAM: aproximadament … més de memòria de treball en aquest servidor» – o «cap» si l'espai ja és suficient. Si el que és massa petit no és el servidor sinó només una configuració, a sota es diu quina: el pressupost de RAM del mòdul o la mida del tmpfs (/dev/shm).

Tauler amb un pressupost de RAM massa petit: veredicte No i la sol·licitud d'augmentar el pressupost de RAM com a mínim fins al valor necessari

El càlcul que hi ha al darrere és senzill i comprensible:

Exemple de càlcul: 12.000 pàgines per 25 KB donen unes 300 MB de necessitat, amb reserva unes 375 MB, per a això almenys 750 MB de memòria lliure

  1. Necessitat = pàgines × mida mitjana de la pàgina.
  2. Amb reserva = necessitat dividida per 0,8. Aquest valor ha de cabre al pressupost de RAM i al tmpfs perquè el veredicte sigui «hi cap».
  3. Memòria lliure: com que la memòria cau pot utilitzar com a màxim la meitat de la memòria de treball disponible, el servidor necessita com a mínim el doble del valor del pas 2 com a memòria lliure disponible. Si en falta, la diferència és la RAM addicional necessària.

L'exemple de la imatge (12.000 pàgines de 25 KB) és una ajuda de càlcul, no una mesura de les nostres pàgines. Per a llocs web petits n'hi ha prou amb unes quantes desenes de megabytes; les dades d'exemple de les captures de pantalla es van conformar amb uns 13 MB.

Important per situar-ho: l'estimació no compta versions addicionals per tarifa o per país. Qui en fa servir moltes ha de preveure una mica de reserva. I també: un pressupost de RAM massa petit és el motiu més freqüent pel qual l'automàtic es queda amb fitxers – no pas la manca de memòria de treball. En aquest cas, el tauler mostra precisament aquesta línia.

Les modificacions i les traduccions netegen la memòria cau

Una memòria cau només és útil si no serveix mai pàgines obsoletes. Un simple límit de temps («descartar cada dotze hores») seria massa tosc: un preu canviat o una errada corregida hauria d'esperar fins a dotze hores. Per això el mòdul treballa segons el contingut.

Procés d'invalidació: modificació, disparador de la base de dades, registre de canvis, comparació, pàgina descartada, nou renderitzat a la consulta següent

  1. Disparadors de la base de dades: a totes les taules que poden influir en una pàgina (productes, variants, imatges, estoc, atributs, categories, preus, impostos, tarifes, articles de blog i etiquetes, dades de partners i d'empreses, vistes, assets, menús, llengües, configuració del lloc web) hi ha disparadors de PostgreSQL. Anoten cada modificació en un registre de canvis.
  2. Dependències i estat de la base de dades: cada pàgina desada recorda quins registres mostra i l'estat de la base de dades amb què es va generar.
  3. Comparació: si hi ha una entrada al registre posterior a aquest estat que afecta un d'aquests registres, la pàgina és obsoleta.
  4. Tornar a desar: a la consulta següent, la pàgina obsoleta es descarta, es renderitza de nou i es torna a desar.

Les traduccions també estan cobertes

Odoo 19 desa els textos traduïts al mateix registre que el text original (com a camp JSON). Una traducció modificada és, doncs, per a la base de dades, un canvi de fila del tot normal – i el disparador la veu. Això val igualment per a l'edició a través de la interfície, per a les importacions, per a les interfícies i per als scripts que escriuen directament a la base de dades. Una traducció automàtica a 46 llengües invalida, doncs, exactament les pàgines el text de les quals ha canviat, i res més.

  • Dirigit en lloc de general: un producte modificat invalida les seves pàgines, les llistes on apareix i la categoria corresponent. La resta es queda a la memòria cau.
  • Els canvis globals (plantilles, assets, llengües, menús, impostos, monedes) invaliden tot alhora, perquè poden afectar qualsevol pàgina.
  • Els comptadors queden fora: el comptador de visites dels articles de blog canvia a cada visita; deliberadament no provoca cap invalidació, perquè si no la memòria cau seria inútil per als articles populars.
  • Xarxa de seguretat: a més, hi ha una antiguitat màxima per pàgina (per defecte 12 hores).
  • Cap error d'escriptura causat per la memòria cau: un error dins d'un disparador es registra com a advertència i no fa fallar el desament real.

Tauler i estadístiques

Tot el que necessiteu per al funcionament és en un sol lloc: a Odoo, a Lloc web → Informes → Memòria cau de pàgines. La secció Visió general és el tauler (amb la configuració) i la secció Evolució mostra les xifres per dia i per lloc web.

Tauler de la memòria cau de pàgines a Odoo: configuració, estat, estadístiques i la comprovació Hi cap a la memòria de treball

Captura de pantalla d'un sistema de proves amb còpies dels nostres llocs web; els noms dels llocs web s'han substituït per marcadors de posició.

Configuració

ConfiguracióSignificat
ActiuInterruptor principal. Desactivat, Odoo torna a servir cada pàgina com abans, a tots els processos en 30 segons com a màxim.
Ubicació d'emmagatzematgeAutomàtic, fitxers o memòria de treball
Antiguitat màxima (hores)Xarxa de seguretat; les pàgines es renoven passat aquest temps, independentment dels canvis
Pressupost de RAM (MB)Com a màxim aquesta quantitat de memòria de treball pot ocupar la memòria cau en RAM; alhora és el límit del veredicte «hi cap»
Límit de disc (MB)Mida màxima de la memòria cau de fitxers; les entrades més antigues s'eliminen primer

Estat i estadístiques

L'estat mostra la ubicació d'emmagatzematge activa amb el seu límit, el nombre i la mida de les pàgines desades i el seguiment de canvis: quants canvis s'han registrat en les últimes 24 hores i quantes taules es vigilen. Si falta una vigilància, el tauler avisa clarament, perquè aleshores no es pot confiar en la memòria cau. Els botons de la part superior permeten executar el manteniment de seguida, buidar la memòria cau o comprovar els disparadors i tornar-los a crear si cal.

Les estadístiques (Avui, 7 dies, 30 dies) contenen:

  • De la memòria cau i Renderitzat: encerts i fallades, i d'aquí la taxa d'encerts
  • Eliminat (modificat/caducat): quantes pàgines s'han descartat per modificació o caducitat
  • Temps de renderitzat i temps de memòria cau: la mitjana per pàgina, comparada
  • Temps de servidor estalviat estimat i volum de dades servit des de la memòria cau

Les xifres les recull cada procés de treball per separat i les escriu un cop per minut; les files de més de 90 dies les neteja la tasca de manteniment.

Evolució com a diagrama, taula dinàmica i llista

A Evolució hi ha disponibles els valors diaris per lloc web – com a diagrama, com a taula dinàmica o com a llista. Així podeu veure si la taxa d'encerts torna a pujar després d'un reinici o d'una gran modificació, i quin lloc web rep més trànsit des de la memòria cau.

Evolució de la memòria cau de pàgines com a taula dinàmica amb encerts, fallades i pàgines descartades per lloc web

Seguretat: què no surt mai de la memòria cau

Una memòria cau de pàgines no pot fer mai que algú vegi els continguts d'un altre. Per això el mòdul segueix el principi: en cas de dubte, no desar a la memòria cau.

  • Només visitants anònims: qui ha iniciat sessió, té un carretó o porta qualsevol altre estat de sessió rep sempre la pàgina renderitzada amb normalitat.
  • Només GET sense paràmetres de cerca: les cerques, els filtres, les ordenacions, els formularis, el carretó i la caixa queden intactes.
  • Només estat 200 i HTML: les pàgines d'error, les redireccions i els fitxers no es desen.
  • Cap identificador de sessió a la memòria cau: una pàgina que conté un identificador de sessió o que estableix una galeta no es desa (i es registra com a advertència).
  • Testimoni CSRF per sol·licitud: el testimoni de la pàgina desada és un marcador de posició i es torna a inserir a cada lliurament.
  • Clau fina: el lloc web, la llengua, la tarifa, la posició fiscal i el consentiment de galetes formen part de la clau de la memòria cau; qui veu una altra cosa rep una altra entrada.
  • Diverses bases de dades: cada base de dades té les seves pròpies entrades, el seu propi registre i les seves pròpies estadístiques.
  • Cap fuita de dades: la memòria cau és local al servidor (fitxer o RAM). No es transmeten dades a tercers.

Cercadors i indexadors d'IA: no es bloqueja res

Alguns operadors responen a la càrrega dels rastrejadors amb bloquejos. Això protegeix el servidor, però costa visibilitat. El mòdul tria el camí contrari:

  • Els mateixos continguts per a tothom: cercadors, indexadors d'IA i visitants reben la mateixa pàgina. No hi ha cap «versió per a rastrejadors» ni cap detecció segons l'identificador del navegador.
  • Respostes més ràpides ajuden a la indexació: una pàgina que respon en 20 en lloc de 500 mil·lisegons consumeix menys pressupost de rastreig, i els rastrejadors poden cobrir més pàgines en el mateix temps.
  • Continguts actuals: com que les modificacions invaliden les pàgines a l'instant, els rastrejadors no veuen mai una versió obsoleta – important si manteniu continguts per a la cerca i per a les respostes d'IA.
  • Les dades estructurades es conserven: JSON-LD, metadades i referències hreflang formen part de la pàgina desada; els mapes de lloc i els fitxers no els toca la memòria cau.

Si a més voleu limitar la càrrega, és una decisió independent que podeu prendre conscientment – el mòdul no us la imposa.

Minimitzar l'HTML i servir-lo comprimit

La memòria cau no estalvia només temps de càlcul, sinó també volum de dades. El mòdul minimitza l'HTML abans de desar-lo i el serveix comprimit quan el navegador o el rastrejador ho admet:

  • Minimitzar (paràmetre website_page_cache.minify): els comentaris HTML desapareixen i els espais en blanc es condensen. Només s'eliminen del tot allà on el navegador els ignora de totes maneres, per exemple entre elements de bloc. Els espais entre elements en línia es conserven, pre, textarea i els scripts queden sense canvis, i les dades estructurades (JSON-LD) es tornen a escriure de forma compacta. Segons la pàgina, les pàgines són entre un 10 i un 30 % més petites. En la prova amb set pàgines reals, el text, el nombre d'elements, la posició de tots els elements i la captura de pantalla van ser idèntics a l'original. El primer lliurament (MISS) està tan minimitzat com tots els següents (HIT).
  • Comprimir (paràmetre website_page_cache.compress): les pàgines de la memòria cau surten amb gzip (Content-Encoding: gzip, Vary: Accept-Encoding). Els grans paquets d'assets (CSS i JavaScript, fins a alguns MB) Odoo mateix els serveix sense comprimir; el mòdul els comprimeix una vegada, desa la còpia al disc i després els serveix directament. Així, 2,1 MB de CSS es van convertir en 0,27 MB i 4,8 MB de JavaScript en 1,1 MB. Les còpies antigues les neteja la tasca de manteniment.
  • Després de reiniciar la màquina: la memòria cau en RAM es conserva en reiniciar Odoo, però no en reiniciar el servidor. Per això la tasca de manteniment la reflecteix progressivament al disc (paràmetre website_page_cache.persist) i la restaura a l'inici. Si una entrada restaurada encara és vàlida ho comprova el mateix mecanisme de sempre: antiguitat i registre de canvis. La minimització no es recalcula en aquest cas.

Instal·lació i configuració

  1. Obtenir el mòdul: baixeu el codi font de GitHub i col·loqueu-lo en una ruta d'addons de la vostra instal·lació d'Odoo 19: github.com/Alex0176/odoo-website-page-cache
  2. Instal·lar: odoo-bin -d <Datenbank> -i website_page_cache --stop-after-init. Així es creen el registre de canvis, els disparadors i la tasca de manteniment (cada 10 minuts).
  3. Reiniciar el servei, perquè tots els processos de treball carreguin el mòdul.
  4. Obrir el tauler: Lloc web → Informes → Memòria cau de pàgines. Comproveu que el seguiment de canvis és complet i trieu la ubicació d'emmagatzematge (valor per defecte: automàtic).
  5. Comprovar: sol·liciteu dues vegades una pàgina de botiga o de blog i mireu la capçalera X-Page-Cache: la primera vegada MISS, després HIT.

La configuració es troba com a paràmetres del sistema (website_page_cache.enabled, .backend, .ttl_hours, .max_mb_file, .max_mb_ram) i normalment es gestiona al tauler. El mòdul està traduït a l'alemany. Desinstal·lar elimina de nou completament els disparadors, el registre i totes les pàgines desades.

Consell per a la memòria cau en RAM: el pressupost de RAM del tauler i la mida del tmpfs (/dev/shm, opció de muntatge size=) han d'ajustar-se a la necessitat. Totes dues coses les indica la comprovació «Hi cap a la memòria de treball?» amb valors concrets.

Límits que heu de conèixer

  • Breu retard després de les modificacions: l'índex del registre de canvis s'actualitza cada dos segons. Fins aleshores, una pàgina modificada encara es pot servir en la versió antiga.
  • Els textos que depenen de l'estoc s'actualitzen mitjançant els canvis d'estoc i l'antiguitat màxima.
  • Estimació de l'espai necessari: no s'hi inclouen les versions addicionals per tarifa o per país; preveieu una mica de reserva.
  • No substitueix tot: la memòria cau alleugereix les sol·licituds que pot atendre. Els usuaris amb sessió iniciada, les cerques i els formularis continuen passant per Odoo.
  • La primera consulta continua sent lenta: després d'un reinici del servidor (RAM) o d'un canvi global, cada pàgina es renderitza una vegada amb normalitat abans d'arribar a la memòria cau.

Preguntes freqüents

Què és la memòria cau de pàgines per a Odoo?

Un mòdul de codi obert (website_page_cache, Odoo 19, LGPL-3) que serveix des d'una memòria cau les pàgines públiques de botiga i de blog als visitants anònims, en lloc de renderitzar-les de nou a cada consulta. La memòria cau és, a elecció, en fitxers o a la memòria de treball.

El mòdul bloqueja cercadors o rastrejadors d'IA?

No. Els cercadors i els indexadors d'IA reben les mateixes pàgines que qualsevol altre visitant, només que més de pressa. No hi ha bloqueig, ni limitació, ni versió pròpia per a rastrejadors.

Les pàgines i traduccions modificades es tornen a desar automàticament a la memòria cau?

Sí. Els disparadors de PostgreSQL comuniquen a un registre cada modificació de les taules rellevants; les pàgines afectades es descarten i, a la consulta següent, es renderitzen de nou i es desen. Les traduccions estan cobertes perquè Odoo 19 les desa al mateix registre.

He de triar fitxer o RAM?

Normalment Automàtic: el mòdul fa servir la RAM mentre hi càpiguen totes les pàgines i, si no, passa a fitxers. Els fitxers són adequats si la memòria cau ha de sobreviure als reinicis o si la RAM és justa; la RAM és la variant més ràpida.

Com puc saber si el meu lloc web hi cap a la memòria de treball?

Al tauler, a Lloc web → Informes → Memòria cau de pàgines. La secció «Hi cap a la memòria de treball?» compta les pàgines per lloc web i llengua, mesura la mida de la pàgina i compara la necessitat amb el pressupost de RAM, la mida del tmpfs i la memòria disponible.

Quanta RAM addicional cal per a una memòria cau en RAM?

El tauler ho indica en una línia pròpia. El càlcul és: necessitat = pàgines × mida de la pàgina; amb reserva de seguretat, dividit per 0,8. Com que la memòria cau pot utilitzar com a màxim la meitat de la memòria disponible, el doble d'això és la memòria lliure necessària; la diferència és la RAM addicional. Si només el pressupost de RAM o el tmpfs són massa petits, el tauler indica la configuració amb el valor objectiu.

Pot la memòria cau mostrar a algú continguts aliens?

No. Només es desa a la memòria cau per a consultes GET anònimes sense paràmetres de cerca. Els usuaris amb sessió iniciada, els carretons, els formularis i les cerques no surten mai de la memòria cau; la llengua, la tarifa, la posició fiscal i el consentiment de galetes formen part de la clau.

Com desactivo la memòria cau en cas d'emergència?

Al tauler, desactiveu l'interruptor «Actiu» o establiu el paràmetre del sistema website_page_cache.enabled a 0. Això s'aplica a tots els processos de treball en 30 segons com a màxim. A més, una desinstal·lació elimina els disparadors, el registre i les pàgines desades.

Com sé si una pàgina ha sortit de la memòria cau?

Per la capçalera de resposta X-Page-Cache: HIT vol dir de la memòria cau, MISS vol dir renderitzada de nou i desada.

El mòdul fa l'HTML més petit i el comprimeix?

Sí. Les pàgines desades es minimitzen de manera conservadora (els comentaris i els espais en blanc superflus desapareixen, el contingut i l'aspecte es mantenen) i, en els encerts de la memòria cau, es serveixen amb gzip; els paquets d'assets es comprimeixen una vegada i es serveixen des del disc. Tots dos es poden desactivar mitjançant els paràmetres website_page_cache.minify i website_page_cache.compress.

Suport de Biricon IT Services

El vostre lloc web d'Odoo reacciona lentament amb càrrega de rastrejadors, o voleu fer la botiga i el blog més ràpids i més visibles? Us donem suport en l'anàlisi de la càrrega, en la configuració de la memòria cau de pàgines, en el dimensionament de la memòria de treball i dels processos de treball i en l'optimització multilingüe per a cercadors del vostre lloc web d'Odoo. El codi font del mòdul el trobareu a GitHub.

Poseu-vos en contacte amb nosaltres

Data: 10 de novembre de 2026. Els valors de mesura provenen d'un sistema de proves amb dades d'exemple i no són cap garantia per a altres instal·lacions.