تحسين أداء أودو 20: كيف تشخّص بطء الواجهات والتقارير والشيفرة المخصصة

عندما يبدو أودو بطيئًا، فإن الخطأ المكلف هو البدء بتغيير البنية التحتية قبل إثبات المواضع التي يُستهلك فيها الوقت فعلًا.

قد ينتج بطء قائمة المبيعات عن دالة حساب مخصصة. وقد يكون SQL هو المهيمن على زمن تقرير ما. وقد لا يصبح البحث مكلفًا إلا عند تفعيل قاعدة سجلات أو عامل تصفية بعينه. وقد تستنزف المهام المجدولة العمّال بينما تبقى الطلبات العادية سليمة. وقد تكشف الترقية شيفرة كانت غير فعّالة أصلًا، لكنها لم تظهر إلا عندما تغيّر حجم البيانات أو سلوك إطار العمل.

لذلك تبدأ عملية تحسين أداء أودو 20 المفيدة بإجراء بطيء واحد يمكن تكراره، فتقيسه، وتحدد ما إذا كان الاختناق في SQL أو Python أو QWeb أو في اعتمادية خارجية أو في سعة الخادم، ثم تعالج سببًا واحدًا في كل مرة.

يتضمن أودو 20 أداة تحليل مدمجة (Profiler) مخصصة لهذا العمل تحديدًا. وتصف وثائق الأداء الرسمية تحليل استعلامات SQL المنفّذة ومسارات الاستدعاء، مع إمكانية عرض النتائج عبر Speedscope. وتوصي الوثائق نفسها بتجميع العمليات على مجموعات السجلات، وخفض التعقيد الخوارزمي، والاستفادة الفعّالة من الجلب المسبق، وإضافة الفهارس بانتقائية لا بصورة تلقائية. راجع وثائق الأداء الرسمية لأودو 20.

يحوّل هذا الدليل تلك الأدوات إلى سير عمل عملي في بيئة الإنتاج.

أولًا، حدّد الإجراء البطيء بدقة

عبارة "أودو بطيء" ليست تشخيصًا.

ابدأ بعملية واحدة يمكن تكرارها:

• فتح قائمة أوامر البيع مع عامل تصفية معروف؛
• تأكيد عرض سعر؛
• تحميل تقرير محاسبي كبير؛
• اعتماد عملية نقل مخزون؛
• فتح لوحة معلومات مخصصة؛
• استيراد عينة ثابتة من السجلات؛
• تشغيل إجراء مجدول واحد؛
• استدعاء نقطة نهاية واحدة في واجهة البرمجة بالحمولة نفسها.

ثم سجّل السياق المحيط بها:

لا تقِس الأداء مرة واحدة فقط. فوثائق الأداء في أودو نفسها تحذّر من أن حالة ذاكرة التخزين المؤقت، والعمليات الأخرى، والعبء الإضافي للتحليل، والاستدعاءات المعطِّلة قد تغيّر القياسات. والهدف ليس الحصول على لقطة شاشة مثيرة، بل إنشاء خط أساس يصمد عند إعادة التشغيل.

وإذا ظهر البطء بعد ترقية، فقارن إجراء الأعمال نفسه على قاعدتي بيانات بيئة الاختبار المرحلية قبل الترقية وبعدها حيثما أمكن. فذلك يمنحك تراجعًا محددًا تحقق فيه بدلًا من انطباع غامض بأن "الإصدار الجديد أبطأ". وللاختبار الخاص بالترقية، راجع دليل الترقية إلى أودو 20 من Octivex.

استخدم أداة التحليل في أودو 20 قبل التخمين

يمكن تفعيل أداة التحليل المدمجة في أودو 20 من أدوات المطوّر لطلبات الويب، أو من Python لقسم محدد من الشيفرة أو لاختبار بعينه. وتسرد وثائق الإصدار 20.0 الرسمية ثلاث أدوات تجميع:

• أداة تجميع SQL لاستعلامات قاعدة البيانات المنفّذة ومسارات استدعائها؛
• أداة التجميع الدورية لعينات مسارات الاستدعاء في Python؛
• أداة تجميع QWeb لتنفيذ توجيهات القوالب واستعلاماتها.

يفعّل الإعداد الافتراضي للتحليل تسجيل SQL والمسارات الدورية. ويمكن فحص النتائج في Speedscope، بما في ذلك العروض المدمجة والعروض المركّزة على SQL. ويشير أودو أيضًا إلى أن التحليل نفسه يضيف عبئًا، لذا استخدمه لتحديد موضع المشكلة، ثم أعد قياس المسار المحسَّن دون اعتبار توقيتات أداة التحليل مقياسًا نهائيًا لأداء الإنتاج.

ما الذي تبحث عنه في عرض SQL

يفيد عرض كثافة SQL خصوصًا عندما يطلق إجراء واحد من المستخدم عددًا كبيرًا من الاستعلامات الصغيرة.

ومن الأنماط التي تستحق التحقيق:

• تكرار الاستعلام نفسه في بنيته مرة لكل سجل؛
• قراءات متكررة لعلاقة كان ينبغي جلبها مسبقًا؛
• عمليات بحث داخل دوال الحساب؛
• تقييم متكرر لنطاقات الأمان عبر مجموعة سجلات كبيرة؛
• تقرير ينفّذ عدة عمليات تجميع متشابهة كلٌّ على حدة؛
• ارتفاع حاد في زمن الاستعلام لا يحدث إلا عند إضافة عامل تصفية أو تجميع محدد.

قد تنتج مئة استعلام سريع كلٌّ على حدة طلبًا بطيئًا في المحصلة. فعدد الاستعلامات جزء من زمن الاستجابة.

ما الذي تبحث عنه في مسارات Python

إذا لم يكن SQL يستهلك معظم زمن الطلب، فافحص العمل الذي تنفّذه Python:

• الحلقات المتداخلة على مجموعات سجلات كبيرة؛
• التحويل والتصفية المتكرران على البيانات نفسها؛
• الحقول المحسوبة المكلفة؛
• تسلسل حمولات ضخمة الحجم؛
• استدعاءات HTTP خارجية داخل طلب متزامن من المستخدم؛
• عمليات تجاوز مخصصة تكرر عملًا أنجزته الدالة الأصلية بالفعل.

ليست أداة التحليل موجودة لتقول لك "اشترِ خادمًا أكبر". بل ينبغي أن تضيّق نطاق التحقيق حتى يفسّر مسار محدد في الشيفرة سبب التأخير.

ما زالت استعلامات N+1 من أسهل الطرق لإبطاء أودو

يوصي دليل الأداء الرسمي في أودو صراحةً بالعمليات المجمّعة، ويحذّر من تشغيل الدوال التي تنتج استعلامات SQL داخل حلقة تمر على السجلات.

ويبدو النمط الخاطئ المعتاد من حيث المفهوم كما يلي:

for order in orders:
    order.line_count = self.env['sale.order.line'].search_count([
        ('order_id', '=', order.id),
    ])

قد يُصدر ذلك استعلام عدّ واحدًا لكل أمر.

والنمط الأفضل هو التجميع على مستوى مجموعة السجلات كاملة، ثم ربط النتيجة بكل سجل. وفي أودو، تكون _read_group مناسبة في الغالب لهذه الفئة من المشكلات.

ويسري المبدأ نفسه على ما يتجاوز العدّ:

• أنشئ السجلات على دفعات عندما يدعم إطار العمل ذلك؛
• استعرض مجموعات السجلات معًا ليعمل الجلب المسبق؛
• تجنّب استدعاء دوال البحث مرارًا مع تغيّر المعرّف وحده؛
• جهّز قواميس أو مجموعات للبحث بدلًا من الحلقات المتداخلة على قوائم Python كبيرة.

ليس الهدف "كتابة أسطر أقل من الشيفرة"، بل جعل حجم العمل ينمو بصورة متوقعة مع نمو البيانات.

تحقّق من الجلب المسبق قبل استبدال شيفرة ORM بـ SQL مباشر

عندما يرى المطوّرون عددًا كبيرًا من الاستعلامات، يغريهم تجاوز ORM.

وقد يكون SQL المباشر مناسبًا أحيانًا. لكن المشكلة الحقيقية غالبًا أن الشيفرة تُبطل سلوك مجموعات السجلات والجلب المسبق في أودو.

فعلى سبيل المثال، قد يؤدي استعراض سجل واحد في كل مرة ثم قراءة حقل منه فورًا إلى وصول متكرر إلى قاعدة البيانات. أما استعراض المجموعة كاملة أولًا فيمنح أودو فرصة جلب حقول مجموعة السجلات معًا.

وقبل استبدال منطق ORM، اسأل:

1. هل تعمل الدالة على مجموعة سجلات أم على سجل واحد في كل مرة؟
2. هل يُقرأ الحقل المرتبط نفسه مرارًا؟
3. هل قسّمت الشيفرة مجموعة سجلات إلى استدعاءات browse() فردية دون داعٍ؟
4. هل يمكن الحصول على النتيجة بعملية تجميع واحدة؟
5. هل يزيل حقل مخزَّن عملية حساب مكلفة متكررة دون أن يفرض تكلفة إعادة حساب غير مقبولة؟

قد يزيل SQL المباشر عبء إطار العمل، لكنه قد يتجاوز أيضًا سلوك ORM، وتوقعات الوصول، واعتماديات الحقول المحسوبة، وقابلية الصيانة. استخدمه لأن القياس يُثبت الحاجة إليه، لا لأنه يبدو أسرع.

لا تفيد الفهارس إلا عندما تطابق الاستعلام الفعلي

توصي وثائق الأداء في أودو 20 بفهارس قاعدة البيانات للحقول التي يكثر البحث فيها، مع التحذير من فهرسة كل حقل، لأن الفهارس تستهلك مساحة تخزين وتضيف تكلفة إلى عمليات INSERT وUPDATE وDELETE.

وهذه المفاضلة هي سبب عدم جعل "أضف فهرسًا" الاستجابة الأولى لكل بحث بطيء.

تبدأ مراجعة الفهارس المفيدة ببنية الاستعلام الفعلية:

• ما الأعمدة التي تظهر في عامل التصفية؟
• هل يوجد ترتيب أو تجميع يغيّر خطة التنفيذ؟
• ما مدى انتقائية القيم؟
• هل الجدول كبير بما يكفي ليفضّل المخطِّط استخدام فهرس؟
• هل يتكرر الاستعلام المسبب للمشكلة بما يكفي لتبرير عبء الكتابة؟

إذا كنت تتحكم في PostgreSQL مباشرةً، فإن وثائق EXPLAIN في PostgreSQL تشرح كيفية فحص خطة الاستعلام التي تختارها قاعدة البيانات. ويُنفّذ EXPLAIN ANALYZE الاستعلام فعليًا، لذا استخدمه بحذر، ولا سيما مع العبارات التي قد تكتب بيانات. وتوثّق PostgreSQL أيضًا أن أدوات قياس التوقيت قد تضيف عبئًا، وأن الخطط المستخلصة من بيانات صغيرة الحجم لا ينبغي تعميمها دون تمحيص على جداول بحجم الإنتاج.

وللمراقبة على مدى أطول في بنية تحتية تتحكم فيها، يمكن لـ pg_stat_statements تجميع إحصاءات التخطيط والتنفيذ لعبارات SQL الموحّدة. ويعتمد الوصول والإعداد على بيئة الاستضافة؛ فلا تفترض أن منصة أودو مُدارة تتيح ضوابط قاعدة البيانات نفسها التي يتيحها خادم مستضاف ذاتيًا.

قد تكون قواعد السجلات والنطاقات المضاعِف الخفي

قد يكون الاستعلام سريعًا لمسؤول النظام وبطيئًا لمستخدم مقيّد الصلاحيات.

وهذه إشارة إلى ضرورة فحص نطاقات الأمان والأعمال، لا مبرر لاختبار كل شيء بصلاحيات المستخدم الخارق.

فقواعد تعدد الشركات، وقيود المستودعات، ونطاقات مندوبي المبيعات، وقواعد السجلات المخصصة قد تضيف شروطًا إلى عمليات البحث. ويصبح الفرق كبيرًا على الجداول الضخمة عندما يكون الاستعلام الناتج صعب التنفيذ بكفاءة على PostgreSQL.

لذلك ينبغي أن يشمل اختبار الأداء الدور الفعلي الذي أبلغ عن المشكلة.

قارن بين:

• مسؤول النظام مقابل المستخدم المقيّد؛
• شركة نشطة واحدة مقابل عدة شركات نشطة؛
• عدم وجود عامل تصفية مقابل عامل التصفية المحفوظ الفعلي؛
• مستودع واحد مقابل جميع المستودعات المسموح بها؛
• الواجهة القياسية مقابل واجهة موروثة مخصصة.

فإذا اختفى البطء عند استخدام حساب مسؤول النظام، فالسؤال التالي ليس "كيف نمنح الجميع صلاحيات أكثر؟"، بل "أي شرط وصول غيّر حجم العمل؟".

وبذلك يبقى ضبط الأداء متسقًا مع الأمان بدلًا من إضعاف الصلاحيات لتسريع الشاشات.

التقارير تحتاج إلى تشخيص منفصل عن الواجهات العادية

قد يكون التقرير بطيئًا لسبب مختلف عن سبب بطء الشاشة التي تطلقه.

ففي تقرير محاسبي أو تقرير مخزون أو تقرير إداري بطيء، قِس المراحل كلًّا على حدة حيثما أمكن:

1. بناء النطاق؛
2. تجميع البيانات؛
3. منطق العملات/الشركات؛
4. عرض القالب؛
5. إنشاء ملف PDF أو تسلسل الملف؛
6. التسليم إلى المتصفح.

إذا أظهرت أداة التحليل أن SQL يهيمن على الطلب، فحسّن مسار البيانات. وإذا هيمن عرض QWeb، فركّز على القالب والتوجيهات المتكررة. وإذا كان الجزء المكلف أداة عرض خارجية أو خدمة بعيدة، فقد لا يجدي تغيير شيفرة ORM شيئًا.

ولهذا الفصل أهميته، لأن عبارة "يستغرق التقرير 20 ثانية" لا تخبرك هل تعود تلك الثواني إلى قاعدة البيانات أم Python أم القالب أم مرحلة العرض.

قد تجعل المهام المجدولة أودو التفاعلي يبدو بطيئًا

يتنافس العمل المجدول مع طلبات المستخدمين على الموارد.

فالمزامنة الكبيرة، أو إعادة الحساب الجماعية، أو مهمة إنشاء المستندات، أو مهمة مجدولة سيئة التجميع، قد تُحدث فترات يعاني فيها المستخدمون من بطء الاستجابة رغم أن شاشة الأعمال نفسها لم تتغير.

وعندما لا يظهر البطء إلا في أوقات معينة، فاربطه بما يلي:

• الإجراءات المجدولة؛
• عمليات الاستيراد/التصدير الخاصة بالتكاملات؛
• فترات النسخ الاحتياطي؛
• مهام البريد الجماعي أو الإشعارات؛
• إعادة حساب المخزون؛
• إنشاء التقارير؛
• المعاملات الطويلة التي تحتجز الأقفال.

لا تكتفِ بنقل كل المهام المجدولة إلى منتصف الليل. فبعض التكاملات تحتاج إلى معالجة في الوقت المناسب، ونقل كل العمل الثقيل إلى الفترة الهادئة نفسها قد يُحدث ذروة أكبر في استهلاك الموارد. قِس المدة والتزامن، ثم قرّر أي المهام يمكن تقسيمها أو تجميعها أو إعادة جدولتها أو نقلها إلى طابور.

البنية التحتية مهمة، لكن قِسها بعد مسار التطبيق

يمكن بالتأكيد أن تنتج مشكلة أداء حقيقية عن نقص في وحدة المعالجة المركزية أو الذاكرة أو الإدخال/الإخراج أو سعة العمّال. والخطأ هو افتراض أن البنية التحتية هي السبب قبل فحص الطلب.

وبالنسبة إلى عمليات النشر الإنتاجية المستضافة ذاتيًا، تميّز وثائق النشر الرسمية لأودو 20 بين الخادم الافتراضي متعدد الخيوط والخادم متعدد العمليات المخصص للإنتاج. كما تنشر قاعدة تقريبية لعدد العمّال بحسب عدد أنوية المعالج، مع الإشارة إلى أن عمّال المهام المجدولة يستهلكون من المعالج، وأن تقدير الذاكرة يعتمد على مزيج الطلبات. راجع وثائق النشر الرسمية لأودو 20.

تعامل مع هذه الأرقام بوصفها إرشادات أولية، لا معادلة عامة لتحديد الحجم.

وتطرح مراجعة البنية التحتية الرشيدة الأسئلة التالية:

• هل يبلغ العمّال حد التشبع خلال فترة البطء؟
• هل يتسبب ضغط الذاكرة في إعادة تشغيل العمّال؟
• هل الإدخال/الإخراج على القرص هو المورد المقيِّد؟
• هل تنتظر قاعدة البيانات أقفالًا أو التخزين؟
• هل تستهلك المهام المجدولة الطويلة السعة المتاحة؟
• هل تؤدي زيادة السعة إلى تحسين الإجراء البطيء المقاس، أم تُخفي الشيفرة غير الفعّالة مؤقتًا فحسب؟

إذا ضاعفت العتاد وبقي التقرير بالبطء نفسه، فالأرجح أن التقرير لم يكن يحتاج إلى عتاد أكبر.

ينبغي أن تكون تغييرات الاستضافة نتيجة للأدلة

تتيح Odoo Online وOdoo.sh والبيئات المستضافة ذاتيًا مستويات مختلفة من التحكم في التشخيص والبنية التحتية.

ومن القيود المهمة بوجه خاص ما يوثّقه أودو نفسه: لا يمكن لقواعد بيانات Odoo Online استخدام أداة التحليل المدمجة. وهذا يغيّر مسار التشخيص في نشر SaaS. أما في Odoo.sh أو البيئات المستضافة ذاتيًا، فخيارات الشيفرة المخصصة والتحليل أوسع، بينما تعتمد الأدوات المباشرة على مستوى PostgreSQL على ما يتيحه نموذج الاستضافة.

لا تستنتج أن Odoo.sh بطيء لأن نقاشًا في أحد المنتديات يقول ذلك، ولا تستنتج أن الاستضافة الذاتية ستحل كل مشكلة أداء. فنقاشات المجتمع تتضمن بانتظام التجربتين معًا: شكاوى من البنية التحتية، وحالات حُلّت فيها المشكلة بالعمل على الاستعلامات والفهارس دون تغيير الاستضافة.

تعامل مع تلك النقاشات بوصفها مؤشرات على مشكلة، لا دليلًا تقنيًا.

مشكلات الأداء بعد الترقية إلى أودو 20

قد تكشف الترقية ثلاث فئات مختلفة من المشكلات:

1. تغيّر مسار التطبيق القياسي

قد تنفّذ واجهة أو تقرير أو سير عمل قياسي الآن شيفرة مختلفة من إطار العمل أو استعلامات SQL مختلفة.

2. الشيفرة المخصصة متوافقة لكنها غير فعّالة

قد تُثبَّت الوحدة بنجاح ومع ذلك يكون أداؤها سيئًا في الإصدار الجديد، لأنها تعتمد على افتراضات قديمة حول سلوك ORM أو تحميل الواجهات أو التفاصيل الداخلية للدوال.

3. البيانات بحجم الإنتاج تكشف المشكلة

قد تبدو قاعدة البيانات التجريبية المُرقّاة سريعة، بينما تضم قاعدة البيانات الفعلية سنوات من القيود المحاسبية وحركات المخزون والرسائل والمرفقات.

ولهذا ينتمي الأداء إلى اختبارات قبول الترقية لا إلى التنظيف بعد الانتقال إلى الإنتاج. ويوصي دليل ضمان الجودة في أودو من Octivex ببيئة اختبار مرحلية مماثلة للإنتاج وأحجام معاملات واقعية لهذا السبب تحديدًا.

وفي سير العمل الحرج، احتفظ بقياس قبل الترقية وبعدها بدور المستخدم نفسه ومجموعة البيانات نفسها والسيناريو نفسه. فالترقية الناجحة ينبغي أن تحافظ على صحة الأعمال وكذلك على زمن استجابة مقبول.

قائمة تحقق عملية لأداء أودو 20

اتبع هذا التسلسل قبل اعتماد أي إصلاح للأداء:

إعادة الإنتاج

• حدّد إجراءً بطيئًا واحدًا ودور المستخدم بدقة.
• سجّل الشركة النشطة وعوامل التصفية وحجم بيانات تمثيليًا.
• شغّله عدة مرات وحدّد خط أساس.
• تحقّق مما إذا كان وقت اليوم أو المهام المجدولة يؤثران فيه.

التحليل

• التقط مسارات SQL والمسارات الدورية حيثما يسمح نموذج الاستضافة بذلك.
• حدّد ما إذا كان SQL أو Python أو QWeb أو الاستدعاءات الخارجية هو المهيمن.
• ابحث عن بنى استعلامات متكررة وسلوك N+1.
• أعد إنتاج المشكلة بصلاحيات واقعية، لا بصلاحيات مسؤول النظام وحدها.

الإصلاح

• جمّع عمليات ORM.
• حافظ على الجلب المسبق لمجموعات السجلات حيثما أمكن.
• قلّل تعقيد الحلقات المتداخلة الذي يمكن تجنبه.
• راجع الحقول المحسوبة وعمليات البحث المتكررة.
• لا تُضف الفهارس إلا عندما يبررها الاستعلام الفعلي.
• راجع المهام المجدولة الثقيلة وتزامن التكاملات.
• لا تغيّر البنية التحتية إلا عندما تدعم بيانات السعة ذلك.

التحقق

• أعد تشغيل سيناريو خط الأساس نفسه تمامًا.
• قِس دون عبء أداة التحليل للمقارنة النهائية.
• تأكد من النتيجة بدور الإنتاج المقيّد.
• شغّل اختبارات التراجع للتحقق من صحة الأعمال.
• افحص مسارات العمل كثيفة الكتابة إذا تغيّرت الفهارس أو الحقول المحسوبة المخزّنة.
• وثّق ما تغيّر وسببه.

أسرع إصلاح هو الذي يزيل الاختناق المُقاس

ينجح ضبط أداء أودو على أفضل وجه عندما يكون عملًا روتينيًا قائمًا على الأدلة.

ابدأ بإجراء المستخدم. قِسه. حلّله. افصل زمن قاعدة البيانات عن زمن Python والعرض. أصلح العمل المتكرر قبل شراء مزيد من السعة. لا تُضف الفهارس إلا للاستعلامات التي تحتاج إليها. اختبر بالصلاحيات وحجم البيانات الموجودين في الإنتاج. ثم قِس مجددًا.

يتجنب هذا النهج إخفاقين شائعين: إنفاق المال على البنية التحتية لتشغيل شيفرة غير فعّالة، وإعادة كتابة منطق التطبيق بينما القيد الفعلي هو السعة.

إذا كانت قاعدة بيانات أودو لديك تعاني من بطء الواجهات، أو تقارير طويلة التنفيذ، أو تراجعات بعد الترقية، أو وحدات مخصصة يتدهور أداؤها مع نمو البيانات، فإن خدمات أودو من Octivex Tech تشمل ضبط الأداء والتدقيق التقني وتخطيط الترقية، استنادًا إلى سلوك الإنتاج المقاس لا إلى التخمين.