کش صفحه برای Odoo: فروشگاه و وبلاگ از RAM یا فایل – سریع برای بازدیدکنندگان، موتورهای جست‌وجو و هوش مصنوعی

۱۰ نوامبر ۲۰۲۶  |  توسعه داخلی  |  Odoo، کارایی و موتورهای جست‌وجو

یک وب‌سایت Odoo هر صفحه را در هر بار فراخوانی از نو رندر می‌کند: پرس‌وجوهای پایگاه داده، قالب‌ها، ترجمه‌ها، قیمت‌ها. برای یک بازدیدکننده‌ی تکی این موضوع به چشم نمی‌آید. اما وقتی موتورهای جست‌وجو و ایندکس‌کننده‌های هوش مصنوعی صدها یا هزاران صفحه را به زبان‌های بسیار درخواست می‌کنند، این به باری دائمی تبدیل می‌شود و مشتریان واقعی هم باید منتظر بمانند. برای همین ماژول Odoo 19 با نام website_page_cache را توسعه داده و به‌صورت متن‌باز (LGPL-3) در GitHub منتشر کرده‌ایم: صفحات فروشگاه و وبلاگ که به‌صورت ناشناس باز می‌شوند، تقریباً به‌صورت ایستا از یک کش می‌آیند، یا از فایل‌ها یا از حافظه‌ی اصلی (RAM)، و هر تغییر – حتی در یک ترجمه – صفحات مربوط را به‌طور خودکار دوباره از کش حذف می‌کند.

نکته‌ی مهم برای همه‌ی کسانی که می‌خواهند پیدا شوند: این ماژول هیچ موتور جست‌وجو یا خزنده‌ی هوش مصنوعی را مسدود نمی‌کند. همه‌ی ایندکس‌کننده‌ها همان محتوایی را دریافت می‌کنند که هر بازدیدکننده‌ای می‌گیرد، فقط سریع‌تر. این مطلب توضیح می‌دهد کش چگونه کار می‌کند، داشبورد چه شکلی دارد (همراه با تصاویر صفحه)، چگونه می‌توانید تشخیص دهید آیا صفحات شما در حافظه‌ی اصلی جا می‌شوند و چه مقدار RAM اضافه لازم می‌شد، چه قواعد امنیتی برقرارند و ماژول را چگونه نصب کنید.

خلاصه

مسئله: بار خزنده‌ها بر وب‌سایت‌های Odoo

Odoo یک سامانه‌ی ERP کامل است و وب‌سایت تنها یکی از ماژول‌های بسیار آن است. هر صفحه‌ای که یک بازدیدکننده یا یک ربات باز می‌کند همین مسیر را می‌پیماید: پردازش درخواست، پرس‌وجو از پایگاه داده، بارگذاری داده‌های محصول و قیمت، رندر قالب QWeb، درج ترجمه‌ها و ارسال نتیجه. بسته به صفحه این کار چند صد میلی‌ثانیه طول می‌کشد و در این مدت یکی از پردازه‌های کاریِ اندک اشغال می‌شود.

برای موتورهای جست‌وجو و ایندکس‌کننده‌های هوش مصنوعی این یک مشکل دائمی است:

• زبان‌های بسیار، نشانی‌های بسیار: صفحه‌ای که به ۴۶ زبان موجود است، برای یک خزنده ۴۶ نشانی متفاوت است.
• هر نشانی جداگانه درخواست می‌شود، اغلب هم‌زمان از سوی فرستنده‌های پراکنده‌ی بسیار. کش کلاسیک مرورگر در اینجا کمکی نمی‌کند، زیرا هر درخواست نشانی تازه‌ای را هدف می‌گیرد.
• پردازه‌های کاری اندک: یک سرویس Odoo معمولاً با مشتی پردازه اجرا می‌شود. وقتی این‌ها با درخواست‌های خزنده‌ها اشغال باشند، بازدیدکنندگان واقعی در صف منتظر می‌مانند.
• محتوای یکسان، بارها و بارها از نو: یک مطلب وبلاگ به‌ندرت تغییر می‌کند، اما در هر فراخوانی پرزحمت از نو ساخته می‌شود.

راه‌حل بدیهی – بستن راه خزنده‌ها – برای شرکتی که می‌خواهد پیدا شود گزینه‌ای نیست. دیده‌شدن در موتورهای جست‌وجو و در پاسخ‌های هوش مصنوعی ارزشمند است. بهتر است صفحات چنان سریع ارسال شوند که بار به‌سختی به چشم بیاید. دقیقاً این کار را کش صفحه انجام می‌دهد.

کش صفحه چگونه کار می‌کند

این ماژول به ورودی درخواست‌های Odoo متصل می‌شود (ir.http). در هر فراخوانی صفحه، در کسری از میلی‌ثانیه تصمیم می‌گیرد که آیا صفحه اجازه دارد از کش بیاید، و در آن صورت آن را بدون پایگاه داده، بدون قالب و بدون رندر ارسال می‌کند.

1. بررسی: فقط یک فراخوانی GET ناشناس بدون پارامتر جست‌وجو روی یک مسیر مجاز (فروشگاه، دسته‌بندی‌ها، محصولات، وبلاگ) مطرح می‌شود. هر چیز دیگری مثل همیشه از Odoo می‌گذرد.
2. کلید کش: این کلید از وب‌سایت، رده‌ی میزبان، زبان، مسیر، لیست قیمت، موقعیت مالیاتی و وضعیت رضایت کوکی تشکیل می‌شود. بنابراین بازدیدکنندگانی که چیز دیگری می‌دیدند هرگز یک ورودی را با هم سهیم نمی‌شوند. میزبان در این میان نرمال‌سازی می‌شود: Odoo نشانی‌های مطلق را همیشه از دامنه‌ی وب‌سایت می‌نویسد، نه از درخواست؛ نشانی درخواست فقط تعیین می‌کند که آیا صفحه به‌عنوان نشانی اصلی گرفته شود (ارجاعات زبانی) و آیا باید ایندکس شود. به همین دلیل همه‌ی نام‌های میزبان بیگانه یک ورودی را همراه با نکته‌ی noindex سهیم می‌شوند، به‌جای آن‌که هر کدام یک نسخه‌ی جدا اشغال کنند.
3. برخورد (Hit): اگر ورودی به‌روزی وجود داشته باشد، ارسال می‌شود. توکن CSRF صفحه در این حالت برای هر درخواست از نو تنظیم می‌شود. بازدید مطالب وبلاگ همچنان شمرده می‌شود.
4. ناکامی (Miss): اگر ورودی وجود نداشته باشد یا کهنه باشد، Odoo صفحه را مثل همیشه رندر می‌کند. اگر نتیجه برای کش مناسب باشد (وضعیت 200، HTML، بدون کوکی، بدون شناسه‌ی نشست در متن)، ذخیره می‌شود؛ فراخوانی بعدی یک برخورد است.
5. دیده‌شدن در سرآیند: هر پاسخ سرآیند X-Page-Cache: HIT یا MISS را دارد. به این ترتیب با هر ابزاری می‌توان بررسی کرد که چه اتفاقی افتاده است.

چقدر سریع‌تر؟

در سامانه‌ی آزمایشی ما (نسخه‌ی کپی وب‌سایت‌هایمان، چند صد صفحه) میانگین زمان رندر یک صفحه حدود ۴۹۰ میلی‌ثانیه و ارسال از کش حدود ۲۳ میلی‌ثانیه بود: تقریباً بیست برابر. هر چه صفحه پرهزینه‌تر باشد، سود بیشتر است. داشبورد از این دو مقدار، زمان سرور صرفه‌جویی‌شده‌ی تخمینی را نیز محاسبه می‌کند.

فایل یا RAM: انتخاب محل ذخیره‌سازی

کش دو محل ذخیره‌سازی دارد. هر دو برای همه‌ی پردازه‌های کاری Odoo به‌طور مشترک قابل‌مشاهده‌اند، پس هر صفحه فقط یک‌بار وجود دارد، نه یک‌بار به ازای هر پردازه.

برای بیشتر نصب‌ها خودکار انتخاب درست است: وقتی جا هست از سرعت RAM بهره می‌برید و در غیر این صورت بدون دخالت به فایل‌ها بازمی‌گردید.

آیا وب‌سایت در حافظه‌ی اصلی جا می‌شود؟ و چه مقدار RAM کم است؟

ممکن بودن یک کش RAM به سه چیز بستگی دارد: تعداد صفحات، اندازه‌ی میانگین آن‌ها و حافظه‌ی در دسترس. داشبورد این را برای شما محاسبه می‌کند:

• تعداد صفحات: به ازای هر وب‌سایت، محصولات منتشرشده، صفحات فهرست فروشگاه، دسته‌بندی‌ها، مطالب وبلاگ و فهرست‌های وبلاگ را می‌شمارد و در تعداد زبان‌ها ضرب می‌کند.
• اندازه‌ی صفحه: به‌محض آن‌که صفحاتی در کش باشند، میانگین واقعی اندازه‌گیری می‌شود؛ تا آن زمان یک مقدار فرضی به کار می‌رود.
• فضا برای کش: کوچک‌ترین مقدار از میان بودجه‌ی RAM تنظیم‌شده، اندازه‌ی tmpfs و نیمی از حافظه‌ی اصلی در دسترس. سرور نباید هرگز به‌خاطر کش دچار کمبود حافظه شود.
• حکم: «با ذخیره جا می‌شود»، «به‌زحمت»، «بیش‌ازحد بزرگ» یا «کش RAM در دسترس نیست». «جا می‌شود» زمانی صدق می‌کند که نیاز حداکثر ۸۰ درصد فضای در دسترس باشد.

جدید: چه مقدار RAM اضافه لازم می‌شد؟

اگر کش جا نشود، می‌خواهید بدانید چه چیزی باید عوض شود. به همین دلیل داشبورد زیر حکم یک سطر مشخص نشان می‌دهد: «RAM اضافه برای کش RAM: حدود … حافظه‌ی اصلی بیشتر روی این سرور» – یا «هیچ» اگر فضا از قبل کافی باشد. اگر به‌جای سرور فقط یک تنظیم بیش‌ازحد کوچک باشد، در ادامه ذکر می‌شود کدام تنظیم: بودجه‌ی RAM ماژول یا اندازه‌ی tmpfs (/dev/shm).

محاسبه‌ی پشت آن ساده و قابل‌پیگیری است:

1. نیاز = صفحات × اندازه‌ی میانگین صفحه.
2. با ذخیره = نیاز تقسیم بر ۰٫۸. این مقدار باید در بودجه‌ی RAM و در tmpfs جا شود تا حکم «جا می‌شود» باشد.
3. حافظه‌ی آزاد: چون کش حداکثر می‌تواند از نیمی از حافظه‌ی اصلی در دسترس استفاده کند، سرور دست‌کم به دو برابر مقدار گام ۲ حافظه‌ی آزاد و در دسترس نیاز دارد. اگر چیزی کم باشد، تفاوت همان RAM اضافه‌ی موردنیاز است.

مثال در تصویر (۱۲٬۰۰۰ صفحه به اندازه‌ی ۲۵ کیلوبایت) یک کمک محاسباتی است، نه اندازه‌گیری صفحات ما. برای وب‌سایت‌های کوچک چند ده مگابایت کافی است؛ داده‌های نمونه در تصاویر صفحه با حدود ۱۳ مگابایت کفایت کردند.

نکته‌ی مهم برای ارزیابی: تخمین نسخه‌های اضافی بر اساس لیست قیمت یا کشور را نمی‌شمارد. اگر از این‌ها زیاد استفاده می‌کنید، کمی ذخیره در نظر بگیرید. و نیز: بودجه‌ی RAM بیش‌ازحد کوچک رایج‌ترین دلیل ماندن حالت خودکار روی فایل‌هاست – نه کمبود حافظه‌ی اصلی. داشبورد در این حالت دقیقاً همین سطر را نشان می‌دهد.

تغییرات و ترجمه‌ها کش را پاک‌سازی می‌کنند

کش فقط زمانی قابل‌استفاده است که هرگز صفحه‌ی کهنه ارسال نکند. یک محدودیت زمانی صرف («هر دوازده ساعت دور بریز») بیش‌ازحد خشن می‌بود: یک قیمت تغییریافته یا یک غلط املایی اصلاح‌شده باید تا دوازده ساعت منتظر می‌ماند. به همین دلیل ماژول بر پایه‌ی محتوا کار می‌کند.

1. تریگرهای پایگاه داده: روی همه‌ی جدول‌هایی که می‌توانند بر یک صفحه اثر بگذارند (محصولات، گونه‌ها، تصاویر، موجودی، ویژگی‌ها، دسته‌بندی‌ها، قیمت‌ها، مالیات‌ها، لیست‌های قیمت، مطالب و برچسب‌های وبلاگ، داده‌های شریک و شرکت، نماها، دارایی‌ها (assets)، منوها، زبان‌ها، تنظیمات وب‌سایت) تریگرهای PostgreSQL نشسته‌اند. آن‌ها هر تغییر را در یک ژورنال تغییرات ثبت می‌کنند.
2. وابستگی‌ها و وضعیت پایگاه داده: هر صفحه‌ی کش‌شده به یاد می‌سپارد که کدام رکوردها را نشان می‌دهد و با چه وضعیتی از پایگاه داده ساخته شده است.
3. تطبیق: اگر ورودی ژورنالی باشد که پس از آن وضعیت پدید آمده و یکی از این رکوردها را بپردازد، صفحه کهنه است.
4. کش مجدد: در فراخوانی بعدی صفحه‌ی کهنه دور ریخته می‌شود، از نو رندر می‌شود و دوباره ذخیره می‌گردد.

ترجمه‌ها نیز پوشش داده می‌شوند

Odoo 19 متن‌های ترجمه‌شده را در همان رکوردی که متن اصلی هست ذخیره می‌کند (به‌صورت فیلد JSON). از دید پایگاه داده، یک ترجمه‌ی تغییریافته بنابراین یک تغییر کاملاً عادی در یک سطر است – و تریگر آن را می‌بیند. این موضوع به‌طور یکسان برای ویرایش از طریق رابط کاربری، درون‌ریزی‌ها، رابط‌ها و اسکریپت‌هایی که مستقیم در پایگاه داده می‌نویسند صدق می‌کند. یک ترجمه‌ی خودکار به ۴۶ زبان بنابراین دقیقاً صفحاتی را از اعتبار می‌اندازد که متنشان تغییر کرده، نه بیشتر.

• هدفمند، نه همگانی: یک محصول تغییریافته صفحات خودش، فهرست‌هایی که در آن‌ها هست و دسته‌بندی مربوط را از اعتبار می‌اندازد. بقیه در کش می‌مانند.
• تغییرات سراسری (قالب‌ها، دارایی‌ها، زبان‌ها، منوها، مالیات‌ها، ارزها) همه‌چیز را یک‌جا از اعتبار می‌اندازند، چون می‌توانند هر صفحه‌ای را تحت تأثیر قرار دهند.
• شمارنده‌ها بیرون می‌مانند: شمارنده‌ی بازدید مطالب وبلاگ در هر بازدید تغییر می‌کند؛ عمداً باعث ابطال نمی‌شود، وگرنه کش برای مطالب محبوب بی‌اثر می‌شد.
• تور ایمنی: افزون بر این، برای هر صفحه یک حداکثر سن وجود دارد (پیش‌فرض ۱۲ ساعت).
• خطای ذخیره‌سازی از جانب کش وجود ندارد: خطا در درون یک تریگر به‌صورت هشدار ثبت می‌شود و ذخیره‌ی اصلی را ناکام نمی‌گذارد.

داشبورد و آمار

هر آنچه برای بهره‌برداری لازم دارید در یک جا قرار دارد: در Odoo زیر وب‌سایت → گزارش‌ها → کش صفحه. بخش نمای کلی همان داشبورد است (همراه با تنظیمات)، بخش روند اعداد را به تفکیک روز و وب‌سایت نشان می‌دهد.

تصویر صفحه از یک سامانه‌ی آزمایشی با نسخه‌های کپی وب‌سایت‌های ما؛ نام وب‌سایت‌ها با نگه‌دارنده جایگزین شده‌اند.

تنظیمات

وضعیت و آمار

وضعیت محل ذخیره‌سازی فعال را همراه با سقف آن، تعداد و اندازه‌ی صفحات کش‌شده و ردیابی تغییرات را نشان می‌دهد: در ۲۴ ساعت گذشته چند تغییر ثبت شده و چند جدول زیر نظر است. اگر پایش جایی کم باشد، داشبورد آشکارا هشدار می‌دهد، زیرا در آن صورت نباید به کش اعتماد کرد. دکمه‌های بالا امکان می‌دهند نگهداری را بلافاصله اجرا کنید، کش را خالی کنید یا تریگرها را بررسی و در صورت نیاز از نو بسازید.

آمار (امروز، ۷ روز، ۳۰ روز) شامل این موارد است:

• از کش و رندرشده: برخوردها و ناکامی‌ها و از آن‌ها نرخ برخورد
• حذف‌شده (تغییریافته/منقضی): چند صفحه به‌دلیل تغییر یا انقضا دور ریخته شده است
• زمان رندر و زمان کش: میانگین هر صفحه در مقایسه
• زمان سرور صرفه‌جویی‌شده‌ی تخمینی و حجم داده از کش

اعداد را هر پردازه‌ی کاری جداگانه جمع می‌کند و دقیقه‌ای یک‌بار می‌نویسد؛ سطرهای قدیمی‌تر از ۹۰ روز را کار نگهداری پاک می‌کند.

روند به‌صورت نمودار، جدول محوری و فهرست

زیر روند مقادیر روزانه به تفکیک وب‌سایت در دسترس است – به‌صورت نمودار، جدول محوری یا فهرست. به این ترتیب می‌بینید که آیا نرخ برخورد پس از یک راه‌اندازی مجدد یا یک تغییر بزرگ دوباره بالا می‌رود و کدام وب‌سایت بیشترین ترافیک را از کش دریافت می‌کند.

امنیت: چه چیزی هرگز از کش نمی‌آید

یک کش صفحه هرگز نباید باعث شود کسی محتوای دیگری را ببیند. ماژول به همین دلیل بر این اصل کار می‌کند: در صورت تردید، کش نکن.

• فقط بازدیدکنندگان ناشناس: کسی که وارد شده باشد، سبد خرید داشته باشد یا وضعیت نشست دیگری همراه بیاورد، همیشه صفحه‌ی رندرشده‌ی عادی را دریافت می‌کند.
• فقط GET بدون پارامتر جست‌وجو: جست‌وجوها، فیلترها، مرتب‌سازی‌ها، فرم‌ها، سبد خرید و پرداخت دست‌نخورده می‌مانند.
• فقط وضعیت 200 و HTML: صفحات خطا، تغییر مسیرها و فایل‌ها ذخیره نمی‌شوند.
• هیچ شناسه‌ی نشستی در کش نیست: صفحه‌ای که شناسه‌ی نشست داشته باشد یا کوکی تنظیم کند ذخیره نمی‌شود (و به‌صورت هشدار ثبت می‌گردد).
• توکن CSRF به ازای هر درخواست: توکن در صفحه‌ی کش‌شده یک نگه‌دارنده است و در هر ارسال از نو جایگزین می‌شود.
• کلید ریزدانه: وب‌سایت، زبان، لیست قیمت، موقعیت مالیاتی و رضایت کوکی جزو کلید کش هستند؛ هر کس چیز دیگری ببیند ورودی دیگری می‌گیرد.
• چند پایگاه داده: هر پایگاه داده ورودی‌های خود، ژورنال خود و آمار خود را دارد.
• بدون نشت داده: کش به‌صورت محلی روی سرور قرار دارد (فایل یا RAM). هیچ داده‌ای به اشخاص ثالث منتقل نمی‌شود.

موتورهای جست‌وجو و ایندکس‌کننده‌های هوش مصنوعی: هیچ چیز مسدود نمی‌شود

برخی بهره‌برداران به بار خزنده‌ها با مسدودسازی پاسخ می‌دهند. این کار از سرور محافظت می‌کند اما به قیمت دیده‌شدن تمام می‌شود. ماژول راه مخالف را برمی‌گزیند:

• محتوای یکسان برای همه: موتورهای جست‌وجو، ایندکس‌کننده‌های هوش مصنوعی و بازدیدکنندگان همان صفحه را دریافت می‌کنند. «نسخه‌ی خزنده»ی جداگانه‌ای وجود ندارد و تشخیصی بر اساس شناسه‌ی مرورگر انجام نمی‌شود.
• پاسخ‌های سریع‌تر به ایندکس شدن کمک می‌کنند: صفحه‌ای که در ۲۰ میلی‌ثانیه به‌جای ۵۰۰ پاسخ می‌دهد، بودجه‌ی خزش را کمتر بار می‌کند و خزنده‌ها در همان زمان می‌توانند صفحات بیشتری را دریافت کنند.
• محتوای به‌روز: چون تغییرات صفحات را بی‌درنگ از اعتبار می‌اندازند، خزنده‌ها هرگز نسخه‌ی کهنه نمی‌بینند – مهم است اگر محتوا را برای جست‌وجو و پاسخ‌های هوش مصنوعی نگهداری می‌کنید.
• داده‌های ساخت‌یافته حفظ می‌شوند: JSON-LD، فراداده‌ها و ارجاع‌های hreflang بخشی از صفحه‌ی کش‌شده‌اند؛ نقشه‌های سایت و فایل‌ها از سوی کش دست‌نخورده می‌مانند.

اگر می‌خواهید علاوه بر این بار را محدود کنید، آن تصمیمی جداست که آگاهانه می‌توانید بگیرید – ماژول آن را به شما تحمیل نمی‌کند.

کوچک‌سازی HTML و ارسال فشرده‌شده

کش نه‌فقط زمان محاسبه بلکه حجم داده را نیز صرفه‌جویی می‌کند. ماژول HTML را پیش از ذخیره کوچک می‌کند و در صورتی که مرورگر یا خزنده پیشنهادش دهد، فشرده ارسال می‌کند:

• کوچک‌سازی (پارامتر website_page_cache.minify): توضیحات HTML حذف می‌شوند، فاصله‌ها یکی می‌شوند. فاصله فقط در جایی کاملاً حذف می‌شود که مرورگر به‌هرحال آن را نادیده می‌گیرد، مثلاً بین عناصر بلوکی. فاصله‌ی بین عناصر درون‌خطی باقی می‌ماند، pre، textarea و اسکریپت‌ها بدون تغییر می‌مانند، داده‌های ساخت‌یافته (JSON-LD) به‌شکل فشرده بازنویسی می‌شوند. بسته به صفحه، صفحات ۱۰ تا ۳۰ درصد کوچک‌تر می‌شوند. در آزمون با هفت صفحه‌ی واقعی، متن، تعداد عناصر، جایگاه همه‌ی عناصر و تصویر صفحه با نسخه‌ی اصلی یکسان بودند. نخستین ارسال (MISS) دقیقاً مانند هر ارسال بعدی (HIT) کوچک‌سازی شده است.
• فشرده‌سازی (پارامتر website_page_cache.compress): صفحات کش با gzip ارسال می‌شوند (Content-Encoding: gzip، Vary: Accept-Encoding). بسته‌های بزرگ دارایی (CSS و JavaScript، تا چند مگابایت) را خود Odoo فشرده‌نشده ارسال می‌کند؛ ماژول آن‌ها را یک‌بار فشرده می‌کند، نسخه را روی دیسک می‌گذارد و پس از آن مستقیماً ارسال می‌کند. از ۲٫۱ مگابایت CSS به این ترتیب ۰٫۲۷ مگابایت و از ۴٫۸ مگابایت JavaScript ۱٫۱ مگابایت شد. نسخه‌های قدیمی را کار نگهداری پاک می‌کند.
• پس از راه‌اندازی مجدد رایانه: کش 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. در این میان ژورنال تغییرات، تریگرها و کار نگهداری (هر ۱۰ دقیقه) ایجاد می‌شوند.
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 اضافه لازم است؟

داشبورد آن را در سطری جداگانه می‌آورد. محاسبه: نیاز = صفحات × اندازه‌ی صفحه؛ همراه با ذخیره‌ی ایمنی تقسیم بر ۰٫۸. چون کش حداکثر می‌تواند از نیمی از حافظه‌ی در دسترس استفاده کند، دو برابر آن حافظه‌ی آزادِ موردنیاز است؛ تفاوت همان RAM اضافه است. اگر فقط بودجه‌ی RAM یا tmpfs بیش‌ازحد کوچک باشد، داشبورد تنظیم را همراه با مقدار هدف نام می‌برد.

آیا کش می‌تواند محتوای دیگران را به کسی نشان دهد؟

خیر. فقط برای فراخوانی‌های GET ناشناس بدون پارامتر جست‌وجو کش انجام می‌شود. کاربران واردشده، سبدهای خرید، فرم‌ها و جست‌وجوها هرگز از کش نمی‌آیند؛ زبان، لیست قیمت، موقعیت مالیاتی و رضایت کوکی جزو کلید هستند.

در شرایط اضطراری کش را چگونه خاموش کنم؟

در داشبورد کلید «فعال» را خاموش کنید یا پارامتر سیستمی website_page_cache.enabled را روی 0 بگذارید. این تغییر حداکثر پس از ۳۰ ثانیه در همه‌ی پردازه‌های کاری اعمال می‌شود. حذف نصب نیز تریگرها، ژورنال و صفحات کش‌شده را برمی‌دارد.

از کجا بفهمم صفحه از کش آمده است؟

از سرآیند پاسخ X-Page-Cache: HIT یعنی از کش، MISS یعنی تازه رندر و ذخیره شده است.

آیا ماژول HTML را کوچک‌تر و فشرده می‌کند؟

بله. صفحات کش‌شده به‌صورت محافظه‌کارانه کوچک می‌شوند (توضیحات و فاصله‌های زائد حذف می‌شوند، محتوا و نمایش یکسان می‌مانند) و در برخوردهای کش با gzip ارسال می‌شوند؛ بسته‌های دارایی یک‌بار فشرده می‌شوند و از دیسک ارسال می‌گردند. هر دو را می‌توان با پارامترهای website_page_cache.minify و website_page_cache.compress خاموش کرد.

پشتیبانی از سوی Biricon IT Services

آیا وب‌سایت Odoo شما هنگام بار خزنده‌ها کند عمل می‌کند، یا می‌خواهید فروشگاه و وبلاگ را سریع‌تر و پربیننده‌تر کنید؟ ما در تحلیل بار، راه‌اندازی کش صفحه، تعیین اندازه‌ی حافظه‌ی اصلی و پردازه‌های کاری و بهینه‌سازی چندزبانه برای موتورهای جست‌وجو وب‌سایت Odoo شما همراهتان هستیم. کد منبع ماژول را در GitHub می‌یابید.

همین حالا تماس بگیرید

به‌روزرسانی: ۱۰ نوامبر ۲۰۲۶. مقادیر اندازه‌گیری از یک سامانه‌ی آزمایشی با داده‌های نمونه به‌دست آمده‌اند و تعهدی برای نصب‌های دیگر نیستند.