გვერდების ქეში Odoo-სთვის: მაღაზია და ბლოგი RAM-იდან ან ფაილიდან – სწრაფად ვიზიტორებისთვის, საძიებო სისტემებისა და ხელოვნური ინტელექტისთვის

2026 წლის 10 ნოემბერი  |  საკუთარი დამუშავება  |  Odoo, წარმადობა და საძიებო სისტემები

Odoo-ს ვებგვერდი ყოველ მოთხოვნაზე თითოეულ გვერდს თავიდან აგენერირებს: მონაცემთა ბაზის მოთხოვნები, შაბლონები, თარგმანები, ფასები. ერთი ვიზიტორისთვის ეს შეუმჩნეველია. თუმცა როცა საძიებო სისტემები და ხელოვნური ინტელექტის ინდექსატორები ბევრ ენაზე ასობით ან ათასობით გვერდს ითხოვენ, ეს მუდმივ დატვირთვად იქცევა და რეალური მომხმარებლებიც ელოდებიან. ამისთვის შევქმენით Odoo 19-ის მოდული website_page_cache და GitHub-ზე გამოვაქვეყნეთ ღია კოდით (LGPL-3): ანონიმური ვიზიტორების მიერ გახსნილი მაღაზიისა და ბლოგის გვერდები თითქმის სტატიკურად მოდის ქეშიდან — ან ფაილებიდან, ან ოპერატიული მეხსიერებიდან (RAM), ხოლო ნებისმიერი ცვლილება – თარგმანისაც – დაზარალებულ გვერდებს ქეშიდან ავტომატურად შლის.

მნიშვნელოვანია ყველასთვის, ვისაც სურს, რომ მისი პოვნა შესაძლებელი იყოს: მოდული არც ერთ საძიებო სისტემას და არც ხელოვნური ინტელექტის კრაულერს არ ბლოკავს. ყველა ინდექსატორი იმავე შიგთავსს იღებს, რასაც ნებისმიერი ვიზიტორი, უბრალოდ უფრო სწრაფად. ეს სტატია განმარტავს, როგორ მუშაობს ქეში, როგორ გამოიყურება დაფა (ეკრანის სურათებით), როგორ გაიგებთ, ეტევა თუ არა თქვენი გვერდები ოპერატიულ მეხსიერებაში და რამდენი დამატებითი RAM იქნებოდა საჭირო, რა უსაფრთხოების წესები მოქმედებს და როგორ დააყენოთ მოდული.

მოკლე შეჯამება

პრობლემა: კრაულერების დატვირთვა Odoo-ს ვებგვერდებზე

Odoo სრულფასოვანი ERP სისტემაა, ვებგვერდი კი ერთ-ერთი მრავალი მოდულიდან. ყოველი გვერდი, რომელსაც ვიზიტორი ან რობოტი ითხოვს, ერთსა და იმავე გზას გადის: მოთხოვნის დამუშავება, მონაცემთა ბაზის გამოკითხვა, პროდუქტისა და ფასის მონაცემების ჩატვირთვა, QWeb შაბლონის რენდერი, თარგმანების ჩასმა და შედეგის მიწოდება. გვერდის მიხედვით ამას რამდენიმე ასეული მილიწამი სჭირდება და ამ დროის განმავლობაში ერთ-ერთ მცირერიცხოვან სამუშაო პროცესს იკავებს.

საძიებო სისტემებისა და ხელოვნური ინტელექტის ინდექსატორებისთვის ეს მუდმივი თემაა:

• ბევრი ენა, ბევრი მისამართი: გვერდი, რომელიც 46 ენაზეა, კრაულერისთვის 46 სხვადასხვა მისამართია.
• ყოველი მისამართი ცალ-ცალკე მოითხოვება, ხშირად ბევრი განაწილებული გამგზავნის მიერ ერთდროულად. კლასიკური ბრაუზერის ქეში აქ ვერ ეხმარება, რადგან ყოველი მოთხოვნა ახალ მისამართს ეხება.
• ცოტა სამუშაო პროცესი: Odoo-ს სერვისი ჩვეულებრივ რამდენიმე პროცესით მუშაობს. თუ ისინი კრაულერების მოთხოვნებითაა დაკავებული, რეალური ვიზიტორები რიგში ელოდებიან.
• ერთი და იგივე შიგთავსი, ისევ და ისევ თავიდან: ბლოგის სტატია იშვიათად იცვლება, მაგრამ ყოველ მოთხოვნაზე ძვირადღირებულად თავიდან გროვდება.

აშკარა გამოსავალი – კრაულერების გამორიცხვა – კომპანიისთვის, რომელსაც სურს, რომ მისი პოვნა შესაძლებელი იყოს, არ არის ვარიანტი. საძიებო სისტემებში და ხელოვნური ინტელექტის პასუხებში ხილვადობა ფასეულია. უკეთესია, გვერდები იმდენად სწრაფად მიეწოდოს, რომ დატვირთვას თითქმის მნიშვნელობა აღარ ჰქონდეს. ზუსტად ამას აკეთებს გვერდების ქეში.

როგორ მუშაობს გვერდების ქეში

მოდული Odoo-ს მოთხოვნების შესასვლელს უერთდება (ir.http). ყოველ გვერდზე მიმართვისას მილიწამის მეასედებში წყვეტს, შეიძლება თუ არა გვერდი ქეშიდან მოვიდეს, და მაშინ მას მონაცემთა ბაზის, შაბლონისა და რენდერის გარეშე აწვდის.

1. შემოწმება: მხოლოდ ანონიმური GET-მოთხოვნა საძიებო პარამეტრების გარეშე დაშვებულ გზაზე (მაღაზია, კატეგორიები, პროდუქტები, ბლოგი) განიხილება. ყველაფერი დანარჩენი, ჩვეულებრივ, Odoo-ში გადის.
2. ქეშის გასაღები: იგი შედგება ვებგვერდის, ჰოსტის კლასის, ენის, გზის, ფასთა სიის, საგადასახადო პოზიციისა და ქუქიების თანხმობის სტატუსისგან. ვიზიტორები, რომლებიც განსხვავებულს იხილავდნენ, ამიტომ არასდროს იზიარებენ ერთ ჩანაწერს. ჰოსტი ნორმალიზდება: Odoo აბსოლუტურ მისამართებს ყოველთვის ვებგვერდის დომენიდან წერს და არა მოთხოვნიდან; მოთხოვნის მისამართი მხოლოდ იმას წყვეტს, ითვლება თუ არა გვერდი მთავარ მისამართად (ენის მითითებები) და უნდა დაიინდექსოს თუ არა. ამიტომ ყველა უცხო ჰოსტის სახელი ერთ ჩანაწერს იზიარებს noindex-მითითებით, იმის ნაცვლად, რომ თითოეულმა საკუთარი ასლი დაიკავოს.
3. დაჯახება: თუ აქტუალური ჩანაწერი არსებობს, ის მიეწოდება. გვერდში CSRF ტოკენი ამ დროს ყოველ მოთხოვნაზე თავიდან ისმება. ბლოგის სტატიების ნახვები კვლავ ითვლება.
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 დღეზე ძველ სტრიქონებს სერვისული სამუშაო ასუფთავებს.

დინამიკა დიაგრამის, პივოტისა და სიის სახით

განყოფილებაში დინამიკა ხელმისაწვდომია ყოველდღიური მნიშვნელობები თითოეული ვებგვერდისთვის – დიაგრამის, პივოტ-ცხრილისა თუ სიის სახით. ასე ხედავთ, ისევ იზრდება თუ არა დაჯახების მაჩვენებელი გადატვირთვის ან დიდი ცვლილების შემდეგ და რომელი ვებგვერდი იღებს ქეშიდან ყველაზე მეტ ტრაფიკს.

უსაფრთხოება: რა არასდროს მოდის ქეშიდან

გვერდების ქეშმა არასდროს უნდა გამოიწვიოს ის, რომ ვინმემ სხვისი შიგთავსი იხილოს. ამიტომ მოდული პრინციპით მოქმედებს: ეჭვის შემთხვევაში არ დაიქეშო.

• მხოლოდ ანონიმური ვიზიტორები: ვინც ავტორიზებულია, კალათა აქვს ან სხვა სესიის მდგომარეობა მოაქვს, ყოველთვის ჩვეულებრივად დარენდერებულ გვერდს იღებს.
• მხოლოდ GET საძიებო პარამეტრების გარეშე: ძიებები, ფილტრები, დალაგებები, ფორმები, კალათა და გადახდა ხელუხლებელი რჩება.
• მხოლოდ სტატუსი 200 და HTML: შეცდომის გვერდები, გადამისამართებები და ფაილები არ ინახება.
• სესიის ID-ები ქეშში არა: გვერდი, რომელიც სესიის ID-ს შეიცავს ან ქუქის აყენებს, არ ინახება (და გაფრთხილების სახით ილოგება).
• CSRF ტოკენი ყოველ მოთხოვნაზე: დაქეშილ გვერდში ტოკენი ჩანაცვლებაა და ყოველ მიწოდებაზე თავიდან ისმება.
• დახვეწილი გასაღები: ვებგვერდი, ენა, ფასთა სია, საგადასახადო პოზიცია და ქუქიების თანხმობა ქეშის გასაღების ნაწილია; ვინც სხვას ხედავს, სხვა ჩანაწერს იღებს.
• რამდენიმე მონაცემთა ბაზა: თითოეულ მონაცემთა ბაზას საკუთარი ჩანაწერები, საკუთარი ჟურნალი და საკუთარი სტატისტიკა აქვს.
• მონაცემთა გაჟონვის გარეშე: ქეში სერვერზე ლოკალურად ინახება (ფაილი ან RAM). მონაცემები მესამე მხარეს არ გადაეცემა.

საძიებო სისტემები და ხელოვნური ინტელექტის ინდექსატორები: არაფერი იბლოკება

ზოგი ოპერატორი კრაულერების დატვირთვაზე ბლოკირებით რეაგირებს. ეს სერვერს იცავს, მაგრამ ხილვადობას უზარალებს. მოდული საპირისპირო გზას ირჩევს:

• ყველასთვის ერთი და იგივე შიგთავსი: საძიებო სისტემები, ხელოვნური ინტელექტის ინდექსატორები და ვიზიტორები ერთსა და იმავე გვერდს იღებენ. არ არსებობს ცალკე „კრაულერის ვერსია“ და არც ბრაუზერის იდენტიფიკატორით ამოცნობა.
• უფრო სწრაფი პასუხები ინდექსაციას ეხმარება: გვერდი, რომელიც 500-ის ნაცვლად 20 მილიწამში პასუხობს, კრაულინგის ბიუჯეტს ნაკლებად ტვირთავს და კრაულერებს იმავე დროში მეტი გვერდის დაფიქსირება შეუძლიათ.
• აქტუალური შიგთავსი: რადგან ცვლილებები გვერდებს მაშინვე აუქმებს, კრაულერები არასდროს ხედავენ მოძველებულ ვერსიას – ეს მნიშვნელოვანია, თუ შიგთავსს ძიებისა და ხელოვნური ინტელექტის პასუხებისთვის ინახავთ.
• სტრუქტურირებული მონაცემები შენარჩუნებულია: JSON-LD, მეტა-მონაცემები და hreflang-მითითებები დაქეშილი გვერდის ნაწილია; საიტის რუკებს და ფაილებს ქეში არ ეხება.

თუ დამატებით დატვირთვის შეზღუდვა გსურთ, ეს ცალკე გადაწყვეტილებაა, რომელსაც შეგნებულად მიიღებთ – მოდული მას თქვენზე არ გვრის.

HTML-ის მინიმიზაცია და შეკუმშული მიწოდება

ქეში მხოლოდ გამოთვლის დროს კი არა, მონაცემთა მოცულობასაც ზოგავს. მოდული HTML-ს შენახვამდე მინიმიზებს და შეკუმშულად აწვდის, თუ ბრაუზერი ან კრაულერი ამას გვთავაზობს:

• მინიმიზაცია (პარამეტრი website_page_cache.minify): HTML-კომენტარები იშლება, თეთრი სივრცე ერთიანდება. სრულად მხოლოდ იქ იშლება, სადაც ბრაუზერი მას მაინც უგულებელყოფს, მაგალითად ბლოკურ ელემენტებს შორის. ინლაინ ელემენტებს შორის დაშორებები რჩება, 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-დან და მოთავსება თქვენი Odoo 19 ინსტალაციის addons-გზაში: 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-ზე.

დაგვიკავშირდით ახლავე

მდგომარეობა: 2026 წლის 10 ნოემბერი. გაზომვის მნიშვნელობები სატესტო სისტემიდანაა მაგალითის მონაცემებით და სხვა ინსტალაციებზე გარანტიას არ წარმოადგენს.