الإجابة المختصرة
إن ضعف الأداء في Salesforce هو عرض تراكمي: صفحة سجل (Record Page) تحتوي على 14 مكونًا، ثلاث عمليات أتمتة تعمل على نفس عملية الحفظ (Save)، استعلام (query) يمسح مليون سجل، وتكامل يسحب البيانات في ساعة الذروة. الطريقة الوحيدة للتحسين دون إهدار الميزانية هي القياس الطبقي، وتحديد الطبقة الأكثر هيمنة، ومعالجتها — ثم القياس مرة أخرى.
الطبقات الخمس وما يُقاس في كل واحدة
| الطبقة | العرض النموذجي | أداة القياس | العلاج الشائع |
|---|---|---|---|
| المتصفح والشبكة | بطء لدى بعض المستخدمين فقط | Lightning Usage App لكل مستخدم | زمن الاستجابة (Latency) التنظيمي، إصدار المتصفح، VPN |
| الشاشة والمكونات | ارتفاع EPT في صفحة السجل الرئيسية | EPT per Page, Debug Mode | تقليل المكونات، التحميل التدريجي، علامات التبويب (Tabs) |
| الأتمتة | بطء عملية الحفظ، انتهاء المهلة (Timeout) في التحديثات الجماعية | Debug Logs, Flow Interviews | دمج التدفقات (Flows)، الانتقال إلى التنفيذ غير المتزامن (asynchronous) |
| البيانات والاستعلامات | تقارير تتعطل، عرض القائمة (List View) متوقف | Query Plan, Apex Jobs | التصفية الانتقائية، الفهرسة (Index)، الأرشفة |
| التكامل | ذروات تحميل منتظمة في أوقات محددة | Event Monitoring, API Usage | Bulk API، نوافذ التشغيل، تقييد النطاق الترددي (Throttling) |
العمل مع أحجام البيانات الكبيرة
يتغير مسار العمل عند تجاوز مليون سجل في العنصر (Object). يؤدي انحراف البيانات (Data Skew) — على سبيل المثال، 200 ألف حساب (Accounts) مرتبطة بنفس المالك (Owner) أو الأصل (Parent) — إلى عمليات قفل الصفوف ويُباطئ أي تحديث جماعي. الحل يكمن في توزيع الملكية، لا في إضافة المزيد من الأجهزة، التي ليست تحت سيطرتكم على أي حال. في الوقت نفسه، يُنصح بالنظر في الأرشفة: السجلات المُغلقة منذ خمس سنوات والتي لا يقرأها أحد تزيد من تكلفة أي استعلام يقوم بعملية مسح.
الشاشات: كلما قل العدد كانت أسرع
تتراكم المكونات في متوسط صفحة السجل (Record Page) داخل المؤسسات القديمة بمعدل اثنين أو ثلاثة سنويًا، لأن كل طرف ذي مصلحة يطلب "عنصر واجهة مستخدم إضافي". يُجري كل مكون Lightning استدعاءاته الخاصة. ينتج عن عمليتين أقصى فائدة: نقل المكونات الثانوية إلى علامات تبويب (Tabs) منفصلة تُحمّل فقط عند النقر، وتطبيق رؤية المكونات (Component Visibility) بناءً على نوع السجل (Record Type) أو الدور، بحيث يرى المستخدم فقط ما هو وثيق الصلة به. يؤدي الجمع بين العمليتين إلى خفض مؤشر EPT بنسبة عشرات بالمئة دون تغيير في الكود.
ترتيب الإجراءات الناجح
ابدأ بأسبوع قياسي دون تغييرات، لتحديد خط أساس موثوق لخمس شاشات رئيسية وثلاث عمليات رئيسية. بعد ذلك، عالج الشاشات — فهذا هو الحل الأسرع والأقل تكلفة. في المرحلة الثالثة، ادمج عمليات الأتمتة حسب العنصر (Object)، وفي المرحلة الرابعة فقط، تعامل مع الاستعلامات ونموذج البيانات. تُعالج عمليات التكامل بالتوازي، إذا أظهر القياس أنها هي السبب.
المنطق وراء هذا الترتيب اقتصادي: الطبقات الأولى رخيصة وقابلة للعكس، بينما الطبقات الأخيرة باهظة الثمن وتتطلب اختبار الانحدار (regression testing). تظهر معلومات إضافية حول هذا الموضوع في Salesforce Health Check وفي علامات ترقية النظام.
المخاطر الشائعة والإجراءات الوقائية
الخطر الأكبر هو التحسين بدون خط أساس (Baseline): يتم إجراء عشرة تغييرات، والمستخدمون ما زالوا يشتكون، ولا توجد طريقة لمعرفة ما الذي ساعد. القياس قبل وبعد كل تغيير مهم هو شرط أساسي، وليس رفاهية.
الخطر الثاني هو التعامل مع العرض الأكثر صخبًا. الشاشة التي يشتكي منها الجميع أكثر لا تكون بالضرورة هي الأبطأ — أحيانًا تكون ببساطة هي الشاشة التي تُفتح أكبر عدد من المرات في اليوم. الخطر الثالث هو تغيير الأتمتة دون تغطية اختبارية: دمج التدفقات (Flows) هو الإجراء الذي يتمتع بأعلى احتمالية لتعطيل منطق العمل بصمت.
كيفية قياس النجاح
تكفي أربعة مقاييس: متوسط EPT في الشاشات الخمس الرئيسية، وقت الحفظ (Save) في عملية الأعمال الرئيسية، عدد حالات فشل انتهاء المهلة (Timeout) وحدود الحاكم (Governor Limit) شهريًا، ونسبة الاستعلامات التي تستغرق أكثر من خمس ثوانٍ. المقياس الخامس — تكميلي وغير تقني — هو عدد شكاوى الأداء في مكتب الخدمة (Service Desk)، والذي من المتوقع أن ينخفض مع التحسين الفعلي.