Orri-cachea Odoo-rentzat: denda eta bloga RAMetik edo fitxategitik – azkarra bisitarientzat, bilatzaileentzat eta IArentzat

2026ko azaroaren 10a  |  Garapen propioa  |  Odoo, errendimendua eta bilatzaileak

Odoo webgune batek orri bakoitza berriro errendatzen du deia egiten den bakoitzean: datu-baseko kontsultak, txantiloiak, itzulpenak, prezioak. Bisitari bakar batentzat hori ez da nabaritzen. Baina bilatzaileek eta IA indexatzaileek ehunka edo milaka orri eskatzen dituztenean hizkuntza askotan, etengabeko karga bihurtzen da, eta benetako bezeroek ere itxaron behar dute. Horretarako website_page_cache Odoo 19 modulua garatu dugu, eta GitHuben kode irekiko (LGPL-3) gisa argitaratu dugu: anonimo gisa irekitako denda- eta blog-orriak ia estatikoki cachetik datoz, edo fitxategietatik edo memoria nagusitik (RAM), eta aldaketa orok – baita itzulpen batenak ere – ukitutako orriak automatikoki kentzen ditu cachetik.

Aurkituak izan nahi dutenentzat garrantzitsua: moduluak ez du bilatzailerik ez IA crawlerrik blokeatzen. Indexatzaile guztiek bisitari orok bezalako eduki bera jasotzen dute, azkarrago bakarrik. Artikulu honek azaltzen du nola lan egiten duen cacheak, nolakoa den aginte-panela (pantaila-argazkiekin), nola jakin dezakezun zure orriak memoria nagusian sartzen diren eta zenbat RAM gehiago beharko litzatekeen, zein segurtasun-arau dauden indarrean eta nola instalatu modulua.

Laburpena

Arazoa: crawlerren karga Odoo webguneetan

Odoo ERP sistema oso bat da, eta webgunea bere modulu ugarietako bat besterik ez. Bisitari batek edo robot batek irekitzen duen orri bakoitzak bide bera egiten du: eskaera prozesatu, datu-basea kontsultatu, produktu- eta prezio-datuak kargatu, QWeb txantiloia errendatu, itzulpenak txertatu eta emaitza eman. Horrek orriaren arabera ehun milisegundo batzuk irauten du, eta denbora horretan lan-prozesu gutxietako bat okupatuta dago.

Bilatzaileentzat eta IA indexatzaileentzat hori etengabeko gaia da:

• Hizkuntza asko, helbide asko: 46 hizkuntzatan dagoen orri bat crawler batentzat 46 helbide desberdin da.
• Helbide bakoitza bereizita eskatzen da, sarri hainbat igorle banatuk aldi berean. Nabigatzailearen cache klasikoak ez du laguntzen, eskaera bakoitza helbide berri bati dagokiolako.
• Lan-prozesu gutxi: Odoo zerbitzu bat prozesu-sorta txiki batekin ibiltzen da normalean. Crawlerren eskaerek okupatuta daudenean, benetako bisitariak ilaran itxaroten dute.
• Eduki bera, behin eta berriz: blog-artikulu bat gutxitan aldatzen da, baina eskaera bakoitzean lan handiz berreraikitzen da.

Irtenbide begi-bistakoa – crawlerrak kanpoan uztea – aurkituak izan nahi duen enpresa batentzat ez da aukera bat. Bilatzaileetako eta IA erantzunetako ikusgarritasuna baliotsua da. Hobe da orriak hain azkar ematea non karga ia nabaritzen ez den. Hori da, hain zuzen, orri-cacheak egiten duena.

Nola funtzionatzen duen orri-cacheak

Moduluak Odoo-ren eskaera-sarreran txertatzen da (ir.http). Orri bat eskatzen den bakoitzean, milisegundo baten zati batean erabakitzen du orria cachetik eman daitekeen, eta orduan datu-baserik, txantiloirik eta errenderizaziorik gabe ematen du.

1. Egiaztapena: Bilaketa-parametrorik gabeko GET deia anonimo bat, baimendutako bide batean (denda, kategoriak, produktuak, bloga), baino ez da aintzat hartzen. Gainerako guztia Odoo-tik igarotzen da betiko moduan.
2. Cache-gakoa: Webgunea, ostalari-klasea, hizkuntza, bidea, prezio-zerrenda, zerga-posizioa eta cookieen baimen-egoera osatzen dute. Beste zerbait ikusiko lukeen bisitariak, beraz, ez du inoiz sarrera bera partekatzen. Ostalaria normalizatu egiten da: Odoo-k helbide absolutuak beti webgunearen domeinutik idazten ditu, ez eskaeratik; eskaeraren helbideak orria helbide nagusitzat hartzen den (hizkuntza-erreferentziak) eta indexatu behar den bakarrik erabakitzen du. Kanpoko ostalari-izen guztiek, beraz, sarrera bakarra partekatzen dute, noindex oharrarekin, bakoitzak bere kopia okupatu beharrean.
3. Arrakasta: Sarrera eguneratua badago, eman egiten da. Orriko CSRF tokena eskaera bakoitzeko berriro ezartzen da. Blog-artikuluen bisitak zenbatzen jarraitzen dira.
4. Hutsegitea: Sarrera falta bada edo zaharkituta badago, Odoo-k orria ohi bezala errendatzen du. Emaitza cachean gordetzeko modukoa bada (200 egoera, HTML, cookierik ez, testuan saio-IDrik ez), gorde egiten da; hurrengo deia arrakasta izango da.
5. Goiburuan ikusgai: Erantzun orok X-Page-Cache: HIT edo MISS goiburua darama. Horrela edozein tresnarekin egiazta daiteke zer gertatu den.

Zenbat azkarragoa?

Gure proba-sisteman (gure webguneen kopia, ehun orri batzuk) orri baten batez besteko errenderizazio-denbora gutxi gorabehera 490 milisegundokoa izan zen, eta cachetik ematea gutxi gorabehera 23 milisegundokoa: hogei bider azkarrago, gutxi gorabehera. Zenbat eta orri konplexuagoa, orduan eta irabazi handiagoa. Aginte-panelak bi balioetatik aurrezten den zerbitzari-denbora zenbatetsia ere kalkulatzen du.

Fitxategia ala RAMa: biltegiratze-lekua aukeratu

Cacheak bi biltegiratze-leku ditu. Biak Odoo-ren lan-prozesu guztientzat ikusgai daude, beraz orri bakoitza behin bakarrik dago, ez prozesu bakoitzeko behin.

Instalazio gehienetan Automatikoa da aukera egokia: RAMaren abiadura lortzen duzu lekua dagoenean, eta bestela, esku-hartzerik gabe, fitxategietara itzultzen da.

Webgunea memoria nagusian sartzen al da? Eta zenbat RAM falta da?

RAM cachea posible den ala ez hiru gauzaren araberakoa da: orri kopurua, haien batez besteko tamaina eta eskuragarri dagoen memoria. Aginte-panelak kalkulua zuretzat egiten du:

• Orri kopurua: Webgune bakoitzeko argitaratutako produktuak, dendako zerrenda-orriak, kategoriak, blog-artikuluak eta blog-zerrendak zenbatzen ditu, eta hizkuntza kopuruaz biderkatzen.
• Orriaren tamaina: Orriak cachean daudenean benetako batez bestekoa neurtzen da;ordura arte, balio ezarri bat erabiltzen da.
• Cachearentzako lekua: hauetako baliorik txikiena: ezarritako RAM aurrekontua, tmpfs-aren tamaina eta eskuragarri dagoen memoria nagusiaren erdia. Zerbitzaria ez da inoiz cachea dela eta memoria-estutasunean egon behar.
• Epaia: «sartzen da erreserbarekin», «justu», «handiegia» edo «RAM cachea ez dago eskuragarri». «Sartzen da» esaten da beharra eskuragarri dagoen lekuaren ehuneko 80 gehienez denean.

Berria: zenbat RAM gehigarri beharko litzateke?

Cachea sartzen ez bada, zer aldatu behar den jakin nahi da. Horregatik aginte-panelak epaiaren azpian lerro zehatz bat ematen du: «RAM cachearentzako RAM gehigarria: gutxi gorabehera … memoria nagusi gehiago zerbitzari honetan» – edo «batere ez», lekua nahikoa bada. Zerbitzaria ez, ezarpen bat bakarrik bada txikiegia, azpian zein den adierazten da: moduluaren RAM aurrekontua edo tmpfs-aren tamaina (/dev/shm).

Atzean dagoen kalkulua erraza da eta jarraitzeko modukoa:

1. Beharra = orriak × batez besteko orri-tamaina.
2. Erreserbarekin = beharra 0,8z zatituta. Balio horrek RAM aurrekontuan eta tmpfs-an sartu behar du, epaia «sartzen da» izan dadin.
3. Memoria librea: Cacheak eskuragarri dagoen memoria nagusiaren erdia gehienez erabil dezakeenez, zerbitzariak 2. urratseko balioaren bikoitza behar du gutxienez memoria libre eskuragarri gisa. Zerbait falta bada, aldea da beharrezko RAM gehigarria.

Irudiko adibidea (25 KBko 12.000 orri) kalkulu-laguntza bat da, ez gure orrien neurketa. Webgune txikietan hamarka megabyte nahikoak dira; pantaila-argazkietako adibide-datuek 13 MB inguruarekin nahikoa izan zuten.

Interpretaziorako garrantzitsua: zenbatespenak ez ditu prezio-zerrenda edo herrialde bidezko bertsio gehigarriak zenbatzen. Asko erabiltzen badituzu, aurreikusi erreserba pixka bat. Eta gainera: RAM aurrekontu txikiegia da automatikoak fitxategietan geratzeko arrazoi ohikoena – ez memoria nagusi faltak. Kasu horretan aginte-panelak, hain zuzen, lerro hori erakusten du.

Aldaketek eta itzulpenek cachea garbitzen dute

Cachea erabilgarria da inoiz orri zaharkiturik ematen ez badu bakarrik. Denbora-muga hutsa («hamabi orduro baztertu») latzegia litzateke: prezio aldatu batek edo akats ortografiko zuzendu batek hamabi ordu arte itxaron beharko luke. Moduluak, beraz, edukian oinarrituta lan egiten du.

1. Datu-baseko triggerrak: Orri bati eragin diezaioketen taula guztietan (produktuak, aldaerak, irudiak, stocka, atributuak, kategoriak, prezioak, zergak, prezio-zerrendak, blog-artikuluak eta etiketak, bazkide- eta enpresa-datuak, ikuspegiak, asset-ak, menuak, hizkuntzak, webguneko ezarpenak) PostgreSQL trigger-ak daude. Aldaketa guztiak aldaketa-egunkari batean erregistratzen dituzte.
2. Mendekotasunak eta datu-basearen egoera: Cachean gordetako orri bakoitzak gogoratzen du zein erregistro erakusten dituen eta zein datu-base egoerarekin sortu zen.
3. Alderaketa: Egoera horren ondoren sortu den eta erregistro horietako bati eragiten dion egunkari-sarrerarik badago, orria zaharkituta dago.
4. Berriro cachean gorde: Hurrengo deian orri zaharkitua baztertu, berriro errendatu eta berriro gordetzen da.

Itzulpenak ere estaltzen dira

Odoo 19-k itzulitako testuak jatorrizko testuaren erregistro berean gordetzen ditu (JSON eremu gisa). Itzulpen aldatu bat, beraz, datu-basearentzat lerro-aldaketa guztiz arrunta da – eta trigger-ak ikusten du. Hori berdin da erabiltzaile-interfazearen bidezko editatzean, inportazioetan, interfazeetan eta datu-basean zuzenean idazten duten script-etan. 46 hizkuntzako itzulpen automatiko batek, beraz, testua aldatu zaien orriak bakarrik baliogabetzen ditu, ez gehiago.

• Zehatz, ez orokorrean: Produktu aldatu batek bere orriak, bera agertzen den zerrendak eta dagokion kategoria baliogabetzen ditu. Gainerakoak cachean geratzen dira.
• Aldaketa globalek (txantiloiak, asset-ak, hizkuntzak, menuak, zergak, monetak) dena baliogabetzen dute batera, orri guztiei eragin diezaieketelako.
• Kontagailuak kanpo geratzen dira: Blog-artikuluen bisita-kontagailua bisita bakoitzean aldatzen da; nahita ez du baliogabetzerik eragiten, bestela cachea eraginkortasunik gabe geratuko litzateke artikulu ezagunetan.
• Segurtasun-sarea: Gainera, orri bakoitzak gehienezko adin bat du (lehenetsia 12 ordu).
• Cacheak ez du gordetze-errorerik eragiten: Trigger baten barruko errore bat ohar gisa erregistratzen da eta ez du benetako gordetzea hutsegiten.

Aginte-panela eta estatistikak

Funtzionamendurako behar duzun guztia leku bakarrean dago: Odoo-n Webgunea → Txostenak → Orri-cachea atalean. Ikuspegi orokorra atala aginte-panela da (ezarpenekin), Historia atalak zenbakiak erakusten ditu egunez eta webguneka.

Gure webguneen kopiak dituen proba-sistema baten pantaila-argazkia; webguneen izenak leku-markekin ordeztu dira.

Ezarpenak

Egoera eta estatistikak

Egoerak aktibo dagoen biltegiratze-lekua erakusten du mugarekin, cacheratutako orrien kopurua eta tamaina, eta aldaketen jarraipena: azken 24 orduetan zenbat aldaketa erregistratu diren eta zenbat taula zaintzen diren. Zaintzaren bat falta bada, aginte-panelak argi ohartarazten du, orduan cachean ezin delako fidatu. Goiko botoiek mantentze-lana berehala exekutatzeko, cachea hustuteko edo trigger-ak egiaztatu eta behar izanez gero berriro sortzeko aukera ematen dute.

Estatistikak (Gaur, 7 egun, 30 egun) hauek ditu:

• Cachetik eta Errendatua: arrakastak eta hutsegiteak, eta horietatik arrakasta-tasa
• Kenduta (aldatua/iraungia): zenbat orri baztertu diren aldaketa edo iraungitzea dela eta
• Errenderizazio-denbora eta cache-denbora: orriko batez bestekoa, alderatuta
• Aurrezten den zerbitzari-denbora zenbatetsia eta cachetik emandako datu-kopurua

Zenbakiak lan-prozesu bakoitzak bere aldetik biltzen ditu eta minutuko behin idazten ditu; 90 egun baino zaharragoak diren lerroak mantentze-lanak garbitzen ditu.

Historia diagrama, pibot-taula eta zerrenda gisa

Historia atalean eguneko balioak daude eskuragarri webgune bakoitzeko – diagrama, pibot-taula edo zerrenda gisa. Horrela ikus dezakezu arrakasta-tasa berriro igotzen den berrabiarazte baten edo aldaketa handi baten ondoren, eta zein webgunek jasotzen duen trafiko gehien cachetik.

Segurtasuna: zer ez den inoiz cachetik etortzen

Orri-cache batek ez du inoiz eragin behar norbaitek beste batenaren edukia ikustea. Moduluak, beraz, printzipio honi jarraitzen dio: zalantzarik badago, ez cachean gorde.

• Bisitari anonimoak bakarrik: Saioa hasita duenak, saskia duenak edo beste saio-egoeraren bat dakarrenak beti errendatutako orri arrunta jasotzen du.
• Bilaketa-parametrorik gabeko GET bakarrik: Bilaketek, iragazkiek, ordenaketek, inprimakiek, saskiak eta ordainketak ukitu gabe jarraitzen dute.
• 200 egoera eta HTML bakarrik: Errore-orriak, birbideratzeak eta fitxategiak ez dira gordetzen.
• Saio-IDrik ez cachean: Saio-ID bat duen edo cookie bat ezartzen duen orria ez da gordetzen (eta ohar gisa erregistratzen da).
• CSRF tokena eskaera bakoitzeko: Cacheratutako orriko tokena leku-marka bat da, eta emate bakoitzean berria ezartzen da.
• Gako zehatza: Webgunea, hizkuntza, prezio-zerrenda, zerga-posizioa eta cookieen baimena cache-gakoaren parte dira; beste zerbait ikusten duenak beste sarrera bat jasotzen du.
• Datu-base anitz: Datu-base bakoitzak bere sarrerak, bere egunkaria eta bere estatistikak ditu.
• Datu-ihesik ez: Cachea zerbitzarian bertan dago (fitxategia edo RAMa). Ez da daturik hirugarrenei transferitzen.

Bilatzaileak eta IA indexatzaileak: ez da ezer blokeatzen

Operadore batzuek crawlerren kargari blokeoekin erantzuten diete. Horrek zerbitzaria babesten du, baina ikusgarritasuna galtzen da. Moduluak kontrako bidea hautatzen du:

• Eduki bera guztientzat: Bilatzaileek, IA indexatzaileek eta bisitariek orri bera jasotzen dute. Ez dago «crawler bertsio» berezirik eta ez dago nabigatzaile-identifikatzailean oinarritutako detekziorik.
• Erantzun azkarragoek indexazioa laguntzen dute: 500 milisegundo beharrean 20an erantzuten duen orriak crawl-aurrekontua gutxiago karga dezake, eta crawlerrek denbora berean orri gehiago bil ditzakete.
• Eduki eguneratuak: Aldaketek orriak berehala baliogabetzen dituztenez, crawlerrek ez dute inoiz bertsio zaharkiturik ikusten – garrantzitsua da edukiak bilaketarako eta IA erantzunetarako zaintzen badituzu.
• Datu egituratuak mantentzen dira: JSON-LD, meta-datuak eta hreflang erreferentziak cacheratutako orriaren parte dira; guneko mapak eta fitxategiak ez ditu cacheak ukitzen.

Gainera karga mugatu nahi baduzu, hori erabaki bereizia da, kontzienteki hartu dezakezuna – moduluak ez dizu inposatzen.

HTMLa minimizatu eta konprimituta eman

Cacheak ez du kalkulu-denbora bakarrik aurrezten, datu-bolumena ere bai. Moduluak HTMLa minimizatzen du gorde aurretik, eta konprimituta ematen du nabigatzaileak edo crawlerrak onartzen duenean:

• Minimizazioa (parametroa website_page_cache.minify): HTML iruzkinak kentzen dira, zuriuneak bateratzen dira. Nabigatzaileak hala ere alde batera uzten dituen lekuetan bakarrik kentzen dira osorik, adibidez bloke-elementuen artean. Lerroko elementuen arteko tarteak mantentzen dira, pre, textarea eta script-ak aldatu gabe geratzen dira, datu egituratuak (JSON-LD) trinko berridazten dira. Orriaren arabera, orriak % 10 eta 30 artean txikiagoak dira. Zazpi benetako orrirekin egindako probetan, testua, elementu kopurua, elementu guztien posizioa eta pantaila-argazkia jatorrizkoaren berdinak ziren. Lehen emaitza (MISS) gainerakoak (HIT) bezain minimizatuta dago.
• Konpresioa (parametroa website_page_cache.compress): Cachetik datozen orriak gzip bidez ateratzen dira (Content-Encoding: gzip, Vary: Accept-Encoding). Asset pakete handiak (CSS eta JavaScript, MB batzuetaraino) Odoo-k berak ematen ditu konprimitu gabe; moduluak behin konprimitzen ditu, kopia diskoan uzten du eta ondoren zuzenean ematen du. 2,1 MB CSS-tik 0,27 MB lortu ziren, eta 4,8 MB JavaScript-etik 1,1 MB. Kopia zaharrak mantentze-lanak garbitzen ditu.
• Ordenagailua berrabiarazi ondoren: RAM cachea Odoo-ren berrabiarazteetan mantentzen da, baina ez zerbitzariaren berrabiaraztean. Horregatik mantentze-lanak urratsez urrats diskora islatzen du (parametroa website_page_cache.persist) eta abiaraztean berrezartzen du. Berrezarritako sarrera batek baliozkoa izaten jarraitzen duen mekanismo berak egiaztatzen du, beti bezala: adina eta aldaketa-egunkaria. Minimizazioa ez da berriro kalkulatzen.

Instalazioa eta ezarpenak

1. Modulua eskuratu: iturburu-kodea GitHubetik deskargatu eta zure Odoo 19 instalazioko addons bide batean kokatu: github.com/Alex0176/odoo-website-page-cache
2. Instalatu: odoo-bin -d <Datenbank> -i website_page_cache --stop-after-init. Horrekin aldaketa-egunkaria, trigger-ak eta mantentze-lana (10 minuturo) sortzen dira.
3. Zerbitzua berrabiarazi, lan-prozesu guztiek modulua kargatu dezaten.
4. Aginte-panela ireki: Webgunea → Txostenak → Orri-cachea. Egiaztatu aldaketen jarraipena osoa dela eta aukeratu biltegiratze-lekua (lehenetsia: automatikoa).
5. Egiaztatu: Denda- edo blog-orri bat bi aldiz eskatu eta X-Page-Cache goiburua ikusi: lehen aldian MISS, ondoren HIT.

Ezarpenak sistema-parametro gisa daude (website_page_cache.enabled, .backend, .ttl_hours, .max_mb_file, .max_mb_ram) eta normalean aginte-panelean zaintzen dira. Modulua alemanera itzulita dago. Desinstalatzeak trigger-ak, egunkaria eta cacheratutako orri guztiak erabat kentzen ditu.

Aholkua RAM cachearentzat: aginte-paneleko RAM aurrekontuak eta tmpfs-aren tamainak (/dev/shm, muntatze-aukera size=) beharrarekin bat etorri behar dute. Biak «Memoria nagusian sartzen al da?» egiaztapenak ematen dizkizu balio zehatzekin.

Ezagutu beharreko mugak

• Atzerapen laburra aldaketen ondoren: Aldaketa-egunkariaren indizea bi segundoro freskatzen da. Aldatutako orri bat harik eta ordura arte bertsio zaharrean eman daiteke.
• Stockaren araberako testuak stock-aldaketen eta gehienezko adinaren bidez eguneratzen dira.
• Leku-beharraren zenbatespena: Prezio-zerrenda edo herrialde bidezko bertsio gehigarriak ez daude barne; erreserba pixka bat aurreikusi.
• Ez da dena ordezkatzen: Cacheak zerbitzatzeko baimena duen eskaerak arintzen ditu. Saioa hasita duten erabiltzaileek, bilaketek eta inprimakiek Odoo-tik igarotzen jarraitzen dute.
• Lehen deia motela izaten jarraitzen du: Zerbitzariaren berrabiarazte baten (RAM) edo aldaketa global baten ondoren, orri bakoitza behin normal errendatzen da cachean egon aurretik.

Ohiko galderak

Zer da Odoo-rentzako orri-cachea?

Kode irekiko modulu bat (website_page_cache, Odoo 19, LGPL-3), denda- eta blog-orri publikoak bisitari anonimoentzat cachetik ematen dituena, deia egiten den bakoitzean berriro errendatu beharrean. Cachea fitxategietan edo memoria nagusian egon daiteke, aukeran.

Moduluak bilatzaileak edo IA crawlerrak blokeatzen al ditu?

Ez. Bilatzaileek eta IA indexatzaileek beste edozein bisitarik bezalako orri berak jasotzen dituzte, azkarrago bakarrik. Ez dago blokeorik, moteltzerik edo crawler-bertsio berezirik.

Aldatutako orriak eta itzulpenak automatikoki berriro cacheratzen al dira?

Bai. PostgreSQL trigger-ek taula garrantzitsuen aldaketa orok egunkari bati jakinarazten diote; ukitutako orriak baztertzen dira eta hurrengo deian berriro errendatu eta gordetzen dira. Itzulpenak estalita daude, Odoo 19-k erregistro berean gordetzen dituelako.

Fitxategia ala RAMa aukeratu behar dut?

Normalean Automatikoa: moduluak RAMa erabiltzen du orri guztiak sartzen diren bitartean, eta bestela fitxategietara jotzen du. Fitxategiak egokiak dira cachea berrabiarazteak gainditzea nahi denean edo RAMa urri dagoenean; RAMa da aldaera azkarrena.

Nola jakin dezaket nire webgunea memoria nagusian sartzen den?

Aginte-panelean, Webgunea → Txostenak → Orri-cachea atalean. «Memoria nagusian sartzen al da?» atalak orriak zenbatzen ditu webgune eta hizkuntza bakoitzeko, orriaren tamaina neurtzen du eta beharra RAM aurrekontuarekin, tmpfs-aren tamainarekin eta eskuragarri dagoen memoriarekin alderatzen du.

Zenbat RAM gehigarri behar da RAM cache baterako?

Aginte-panelak lerro propio batean ematen du. Honela kalkulatzen da: beharra = orriak × orri-tamaina; segurtasun-erreserbarekin 0,8z zatituta. Cacheak eskuragarri dagoen memoriaren erdia gehienez erabil dezakeenez, horren bikoitza da libre behar den memoria; aldea da RAM gehigarria. RAM aurrekontua edo tmpfs bakarrik txikiegia bada, aginte-panelak ezarpena eta helburu-balioa adierazten ditu.

Cacheak beste norbaiten edukia erakuts diezaioke norbaiti?

Ez. Bilaketa-parametrorik gabeko GET deia anonimoetarako bakarrik gordetzen da cachean. Saioa hasita duten erabiltzaileak, saskiak, inprimakiak eta bilaketak ez dira inoiz cachetik etortzen; hizkuntza, prezio-zerrenda, zerga-posizioa eta cookieen baimena gakoaren parte dira.

Nola desaktibatzen dut cachea larrialdi batean?

Aginte-panelean «Aktibo» etengailua itzali edo website_page_cache.enabled sistema-parametroa 0 balioan ezarri. Hori prozesu guztietan indarrean dago 30 segundo igaro ondoren gehienez. Desinstalatzeak, gainera, trigger-ak, egunkaria eta cacheratutako orriak kentzen ditu.

Nola jakin dezaket orri bat cachetik etorri den?

X-Page-Cache erantzun-goiburuan: HIT cachetik dator esan nahi du, MISS berriki errendatu eta gorde dela esan nahi du.

Moduluak HTMLa txikiagotzen eta konprimitzen al du?

Bai. Cacheratutako orriak kontserbadoreki minimizatzen dira (iruzkinak eta soberako zuriuneak kentzen dira, edukia eta itxura berdin geratzen dira) eta cache-arrakastetan gzip bidez ematen dira; asset paketeak behin konprimitzen dira eta diskotik ematen. Biak website_page_cache.minify eta website_page_cache.compress parametroen bidez desaktiba daitezke.

Biricon IT Services-en laguntza

Zure Odoo webgunea astun dabil crawlerren kargarekin, edo zure denda eta bloga azkarragoak eta ikusgarriagoak egin nahi dituzu? Laguntzen dugu kargaren analisian, orri-cachearen ezarpenean, memoria nagusiaren eta lan-prozesuen dimentsionamenduan eta zure Odoo webguneko bilatzaileen optimizazio eleaniztunean. Moduluaren iturburu-kodea GitHuben aurkituko duzu.

Jarri gurekin harremanetan orain

Data: 2026ko azaroaren 10a. Neurketa-balioak adibide-datuak dituen proba-sistema batetik datoz eta ez dira bermea beste instalazioetarako.