التطبيق بطيء: هل المشكلة في الجوال أم الشبكة أم الخادم أم قاعدة البيانات؟
المستخدمون يشتكون من البطء، والمطور يلوم الخادم، ومزود الاستضافة يقترح الترقية. هذا الدليل لصاحب التطبيق ومدير التقنية: كيف تعرف إن كانت المشكلة في الجوال أو الشبكة أو الخادم أو قاعدة البيانات قبل أن تدفع لإصلاحها.
حين يقال لك إن التطبيق بطيء، فلا تدفع لخادم أقوى ولا لإعادة كتابة قبل أن تعرف أين يضيع الوقت. كل ضغطة زر يمر طلبها بأربع طبقات: الجوال الذي يرسم الشاشة، والشبكة التي تنقل الطلب والصور، والخادم الذي ينفذ المنطق، وقاعدة البيانات التي تجيب عن الاستعلام. ابدأ بنمط البطء: هل هو في كل الأجهزة أم في الاقتصادية فقط؟ في كل الأوقات أم في الذروة؟ في شاشة واحدة أم في كلها؟ ثم اطلب قياسًا لكل طبقة: زمن الشاشة على الجهاز، وعدد الطلبات وأحجامها، وزمن كل واجهة API، وأبطأ الاستعلامات. عندها يتضح المصدر، ويُصلح الأكبر أثرًا أولًا.
المستخدمون يشتكون من أن التطبيق بطيء، والمطور يقول إن المشكلة في الخادم، ومزود الاستضافة يقترح ترقية الخوادم، وفريقك يظن أن التطبيق يحتاج إعادة بناء. كل واحد منهم قد يكون محقًا، وقد يكون مخطئًا تمامًا، ولا أحد يعرف قبل القياس. هذه المقالة دليل تشخيص لصاحب التطبيق ومدير التقنية: كيف تسأل الأسئلة الصحيحة، وما الدليل الذي تطلبه عن كل طبقة، وما الإصلاحات المعتادة لكل منها، حتى تدفع لإصلاح السبب لا لتخمين.
أين يضيع الوقت؟ رحلة طلب واحد
ما يشعر به المستخدم زمن واحد: من لمس الزر إلى ظهور النتيجة. لكن هذا الزمن مجموع أزمنة في طبقات مختلفة، ولكل طبقة أدوات قياس ومسؤول مختلف:
- الجوالاستقبال اللمسة، وتجهيز الطلب، ثم رسم النتيجةمطور التطبيق
- الشبكةعدد الطلبات، وأحجام الاستجابات والصورالتطبيق والخادم معًا
- الخادمالتحقق، ومنطق العمل، واستدعاء الخدمات الخارجيةمطور Backend
- قاعدة البياناتتنفيذ الاستعلامات وقراءة الجداولمطور Backend أو مسؤول البيانات
- العودة والعرضالاستجابة تعود ويُعاد رسم الشاشةمطور التطبيق
لهذا تبدأ خدمة تحسين أداء التطبيق عندنا بالقياس قبل أي تعديل: التطبيق والشبكة والخادم وقاعدة البيانات، ثم معالجة الأكبر أثرًا، ثم إعادة القياس بالمقاييس نفسها.
نمط البطء يدلك على الطبقة قبل أي أداة
قبل أن يفتح أحد الكود، أجب أنت عن أسئلة بسيطة من شكاوى المستخدمين وملاحظة فريقك. نمط البطء وحده يستبعد نصف الاحتمالات:
| نمط البطء | الطبقة المرجحة | أول دليل تطلبه |
|---|---|---|
| على الأجهزة الاقتصادية والقديمة فقط | الجوال | قياس الشاشة على جهاز من الفئة الأدنى، ومعدلات التجمد في لوحتي المتجرين |
| على بيانات الجوال أكثر من الواي فاي | الشبكة | عدد الطلبات لكل شاشة وأحجام الاستجابات والصور |
| في شاشة أو بحث بعينه، والباقي سريع | الخادم أو قاعدة البيانات لتلك الواجهة | زمن تلك الواجهة والاستعلامات التي تنفذها |
| في أوقات الذروة (بداية الشهر، الحملات) | الخادم وقاعدة البيانات تحت الحمل | استهلاك الموارد وزمن الواجهات مقارنة بأوقات الهدوء |
| يزداد تدريجيًا شهرًا بعد شهر | قاعدة البيانات مع نمو الجداول | أبطأ الاستعلامات وأحجام الجداول الكبرى |
| بدأ فجأة بعد إصدار معين | تغيير في ذلك الإصدار | قائمة ما تغيّر فيه، ومقارنة المقاييس قبله وبعده |
| عند فتح التطبيق فقط | الجوال (الإقلاع) أو طلبات البداية | زمن الإقلاع وما يُحمَّل قبل ظهور أول شاشة |
| في لوحة التحكم والتقارير | قاعدة البيانات أو معالجة ثقيلة أثناء الطلب | زمن استعلامات التقارير، وهل تعمل على قاعدة البيانات التشغيلية |
النمط الأخير (بدأ بعد إصدار) يستحق وقفة: إن كان النشر عندك يدويًا بلا سجل واضح لما تغيّر في كل إصدار، فلن تعرف ما الذي أبطأ التطبيق. خط نشر آلي يسجل كل إصدار، ويراقب الأخطاء بعد النشر، ويعيد الإصدار السابق عند ارتفاعها، كما في صفحة DevOps والنشر المستمر، يجعل هذا السؤال يُجاب في دقائق.
الطبقة الأولى: التطبيق على الجهاز
- العَرَض
- فتح بطيء بشاشة بيضاء أو شعار، وقوائم تتقطع أثناء التمرير، وأزرار لا تستجيب فورًا، وحرارة الجهاز أو استنزاف البطارية. والعلامة الفارقة: البطء نفسه يحدث حتى حين تكون البيانات محفوظة ولا طلب على الشبكة.
- الدليل
- قياس على جهاز حقيقي من الفئة الأدنى التي يستخدمها عملاؤك، لا على جهاز المطور. وفي المتجرين بيانات جاهزة: تعرض أداة Xcode Organizer معدل تجمد التطبيق بعدد الثواني التي لا يستجيب فيها في كل ساعة استخدام، وتعرض لوحة Android vitals معدل عدم الاستجابة والانهيار والذاكرة، وتذكر Google أن هذه المؤشرات الأساسية تؤثر على ظهور التطبيق في Google Play.
- الإصلاحات المعتادة
- تأجيل ما لا يلزم عند الإقلاع، ونقل العمل الثقيل عن مسار رسم الواجهة، وقوائم تُرسم عناصرها عند ظهورها لا دفعة واحدة، وتحميل الصور بمقاس العرض لا بمقاس الكاميرا، وضبط العمل في الخلفية وتحديثات الموقع.
الطبقة الثانية: الشبكة وعدد الطلبات والصور
- العَرَض
- التطبيق مقبول على الواي فاي في المكتب، وبطيء عند العملاء على بيانات الجوال أو في الأماكن المزدحمة. الشاشة تظهر على مراحل، وكل جزء منها يصل وحده.
- الدليل
- تسجيل حركة الشبكة لشاشة واحدة: كم طلبًا ترسل، وهل تنتظر بعضها بالتتابع، وكم حجم كل استجابة، وما مقاسات الصور المحمّلة. الشاشة الرئيسية التي ترسل عشرين طلبًا متتاليًا قد تكون بطيئة وكل طلب فيها سريع.
- الإصلاحات المعتادة
- دمج طلبات الشاشة في واجهة واحدة مصممة لها، وتقسيم القوائم الطويلة إلى صفحات، وإرجاع الحقول المستخدمة فقط، وضغط الاستجابات، وتصغير الصور على الخادم وتقديمها عبر شبكة توزيع محتوى (CDN)، وتخزين مؤقت على الجهاز لما لا يتغير كثيرًا.
الطبقة الثالثة: الخادم وواجهات API
- العَرَض
- كل الأجهزة والشبكات تعاني بالقدر نفسه في واجهات معينة، أو في أوقات الذروة. أحيانًا تنتهي المهلة وتظهر رسالة خطأ بدل النتيجة.
- الدليل
- زمن الاستجابة لكل واجهة من سجلات الخادم أو أداة مراقبة الأداء، مقاسًا بالمئين لا بالمتوسط وحده. واستهلاك المعالج والذاكرة في الذروة. وقائمة ما تفعله الواجهة البطيئة داخل الطلب نفسه: هل ترسل بريدًا، أو تولّد ملفًا، أو تنتظر بوابة دفع أو مزود رسائل؟
- الإصلاحات المعتادة
- نقل المهام الثقيلة إلى معالجة في الخلفية بطوابير، وتخزين مؤقت لنتائج الحسابات المتكررة، ومهلات محددة لاستدعاء الخدمات الخارجية، ثم توسيع الموارد إن بقي الحمل أكبر من الطاقة بعد ذلك. مقالة متى يحتاج التطبيق Redis وطوابير المعالجة تفصّل متى تكون الطوابير هي الحل.
لماذا المئين لا المتوسط؟ مثال افتراضي للتوضيح واجهة طلبات متوسط زمنها 400 جزء من الثانية، ويبدو ذلك مقبولًا. لكن المئين 95 (الزمن الذي تقل عنه 95 من كل 100 استجابة) هو 4 ثوانٍ. أي أن طلبًا من كل عشرين تقريبًا ينتظر 4 ثوانٍ أو أكثر. فإن كان المستخدم يمر بعشر شاشات في الجلسة، وكل منها ترسل طلبين إلى هذه الواجهة، فالمعادلة 10 × 2 = 20 طلبًا، أي أن معظم الجلسات ستصادف انتظارًا طويلًا مرة على الأقل. المتوسط يخفي ما يعانيه المستخدمون فعلًا، ولهذا تُقاس أبطأ نسبة من الطلبات.
الطبقة الرابعة: قاعدة البيانات والاستعلامات
- العَرَض
- تطبيق كان سريعًا في أشهره الأولى، ويبطؤ مع نمو البيانات. بحث أو قائمة أو تقرير يزداد زمنه مع الوقت، وأحيانًا تتعطل عمليات تنتظر بعضها في الذروة.
- الدليل
- سجل الاستعلامات البطيئة، وأكثر الاستعلامات تكرارًا، وخطة تنفيذ الاستعلام الأبطأ (هل يقرأ الجدول كله بدل أن يستخدم فهرسًا؟)، وأحجام الجداول الكبرى، وحالات الانتظار والأقفال.
- الإصلاحات المعتادة
- فهارس مدروسة بعد قراءة خطة الاستعلام، وإزالة الاستعلامات داخل الحلقات بجلب مجمع، وتقصير المعاملات الطويلة، ونقل التقارير إلى نسخة قراءة، وأرشفة البيانات القديمة.
أشهر مثال على ما يُكتشف هنا هو الاستعلام داخل الحلقة. مثال افتراضي للتوضيح شاشة تعرض 50 طلبًا، والكود يجلب القائمة باستعلام، ثم يجلب بيانات عميل كل طلب باستعلام مستقل: 1 + 50 = 51 استعلامًا. إن كانت رحلة كل استعلام إلى قاعدة البيانات 20 جزءًا من الثانية، فالانتظار 51 × 20 = 1020 جزءًا من الثانية، أي نحو ثانية كاملة قبل أي منطق آخر. بجلب العملاء دفعة واحدة يصبح العدد استعلامين، والانتظار نحو 40 جزءًا من الثانية. وكلما كبرت القائمة كبر الفرق.
هذه الطبقة هي موضوع خدمة تحسين الـ Backend وقاعدة البيانات: قياس الاستعلامات والواجهات الأبطأ، ثم فهارس وإعادة كتابة وتخزين مؤقت ومهام في الخلفية، مع تقرير بالأرقام قبل وبعد، دون إعادة بناء النظام. وإن كان البطء يظهر مع نمو المستخدمين لا البيانات وحدها، فمقالة توسيع Backend مع زيادة المستخدمين تشرح ما يتغير عند تضاعف الحمل.
ترقية الخادم قبل التشخيص تخفي المشكلة أسابيع ثم تعود، وبفاتورة أعلى. استعلام بلا فهرس على جدول ينمو سيبطئ أي خادم في النهاية. زيادة الموارد قرار صحيح فقط حين يثبت القياس أن الحمل الحقيقي تجاوز الطاقة بعد إصلاح الأسباب.
ما الذي يحدد حجم إصلاح البطء وتكلفته؟
بعد التشخيص يأتي سؤال الميزانية. لا يوجد رقم ثابت لإصلاح البطء، لكن العوامل التي تكبّر العمل أو تصغّره تظهر من تقرير القياس نفسه:
| العامل | يكبّر العمل حين | يصغّره حين |
|---|---|---|
| عدد الطبقات المتأثرة | البطء موزع على التطبيق والخادم وقاعدة البيانات معًا | سبب واحد في طبقة واحدة، كفهرس ناقص أو واجهة ثقيلة |
| المراقبة الموجودة | لا سجلات ولا أدوات قياس، فيبدأ العمل بتركيبها | مراقبة قائمة تعطي الأرقام من اليوم الأول |
| مكان الإصلاح | يلزم تعديل التطبيق ونشر إصدار في المتجرين | الإصلاح كله في الخادم وقاعدة البيانات |
| تصميم البيانات | السبب في بنية الجداول نفسها، فيلزم ترحيل بيانات قائمة | البنية سليمة وينقصها فهارس أو إعادة كتابة استعلامات |
| بيئة الاختبار | لا توجد بيئة ببيانات قريبة من حجم الإنتاج لتجربة الإصلاح | بيئة اختبار ببيانات ممثلة، فيُقاس الأثر قبل النشر |
لهذا يكون التشخيص المحدد المدة استثمارًا صغيرًا نسبيًا مقابل ما يوفره: فهو يحوّل «التطبيق بطيء» إلى قائمة أسباب مرتبة، لكل منها جهد تقديري وأثر متوقع، فتختار ما تنفذه أولًا بحسب ميزانيتك.
أخطاء شائعة في التعامل مع تطبيق بطيء
- شراء خادم أقوى أولًا: أسرع قرار وأقلها دوامًا، لأنه لا يعالج السبب.
- الاختبار على جهاز المطور وشبكة المكتب: أحدث جهاز وأسرع اتصال لا يمثلان عملاءك.
- القياس بالمتوسط: المتوسط الجيد قد يخفي أن جزءًا من المستخدمين ينتظر ثواني طويلة.
- التحسين دون قياس قبله: لن تعرف إن كان التحسين نجح، ولا بكم، ولا إن كان كسر شيئًا آخر.
- إعادة الكتابة بتقنية «أسرع»: البطء في أغلب التطبيقات من استعلامات وطلبات وصور، لا من لغة البرمجة أو الإطار.
- إصلاح كل شيء دفعة واحدة: أصلح الأكبر أثرًا، وقِس، ثم انتقل إلى التالي.
- تجاهل الحمل المتوقع: تطبيق سريع اليوم قد ينهار في أول حملة. مقالة اختبار الحمل والأداء تشرح كيف تعرف حدوده قبلها.
ما تطلبه من المطور، وما تجهزه قبل التواصل
جهّز قبل أن تتواصل مع فريقك أو مع جهة خارجية:
- أين يظهر البطء: الشاشات، والأجهزة، ونوع الشبكة، والأوقات، مع أمثلة من شكاوى حقيقية.
- متى بدأ: فجأة بعد إصدار، أم تدريجيًا مع النمو.
- حجم البيانات والمستخدمين اليوم، والمتوقع خلال السنة، وأي حملة أو موسم قادم.
- الوصول إلى الكود والخوادم وقاعدة البيانات، وأدوات المراقبة إن وجدت، بصلاحيات قراءة.
- هدف واضح: ما الزمن الذي تعتبره مقبولًا للشاشات الأساسية.
واطلب من المطور قبل أن توافق على أي إصلاح مدفوع:
- تقرير قياس أولي لكل طبقة بالأرقام: زمن الشاشات، وعدد الطلبات، وزمن الواجهات بالمئين، وأبطأ الاستعلامات.
- تحديد مصدر البطء بالدليل، لا بالانطباع، وترتيب الأسباب بحسب أثرها.
- خطة تحسين تفصل ما يُصلح في التطبيق ويحتاج إلى إصدار في المتجر، عما يُصلح في الخادم ولا يحتاجه.
- تفسير مكتوب لأي توصية بترقية الخوادم: ما الذي أثبت أن الحمل تجاوز الطاقة؟
- إعادة القياس بالمقاييس نفسها بعد كل مرحلة، واختبارات تضمن أن التحسين لم يكسر شيئًا.
- مراقبة مستمرة للأداء مع تنبيهات، حتى لا يعود البطء دون أن يعرف أحد.
ولاحظ أن جزءًا كبيرًا من التحسين في الخادم وقاعدة البيانات لا يحتاج إلى تحديث التطبيق في المتجر، فيصل أثره إلى كل المستخدمين فور النشر.
الخلاصة: قِس كل طبقة، ثم أصلح الأكبر أثرًا
«التطبيق بطيء» وصف لما يشعر به المستخدم، لا تشخيص. نمط البطء يدلك على الطبقة المرجحة، والقياس في كل طبقة يحدد السبب: الجوال، أو الشبكة وعدد الطلبات، أو الخادم وما يفعله داخل الطلب، أو قاعدة البيانات واستعلاماتها. ادفع مقابل التشخيص أولًا، ثم مقابل إصلاح الأكبر أثرًا، واطلب الأرقام قبل وبعد في كل مرة. بهذا لا تدفع لخادم لا تحتاجه، ولا لإعادة بناء كان يكفي عنها فهرس واحد.
إن كان تطبيقك بطيئًا ولا تعرف السبب، أرسل أين يظهر البطء ومتى بدأ وما لديك من وصول عبر طلب عرض لتطبيقك الحالي، ونقترح قياسًا محدد المدة يحدد المصدر قبل أي تعديل.
أسئلة شائعة
نادرًا ما يكون هذا الحل الأول. أغلب البطء يأتي من استعلامات بلا فهارس أو طلبات كثيرة لكل شاشة أو صور كبيرة أو مهام ثقيلة داخل الطلب، والخادم الأقوى يؤجل ظهورها فقط. زيادة الموارد قرار صحيح حين يثبت القياس أن الحمل تجاوز الطاقة بعد إصلاح الأسباب.
إن كان البطء على الأجهزة الاقتصادية فقط، أو يحدث حتى والبيانات محفوظة دون طلب على الشبكة، فالمرجح أنه في التطبيق. وإن كان على كل الأجهزة في واجهات معينة أو أوقات الذروة، فالمرجح الخادم أو قاعدة البيانات. القياس لكل طبقة يحسم ذلك.
ليس دائمًا. ما يُصلح في الخادم وقاعدة البيانات، مثل الفهارس والتخزين المؤقت ونقل المهام إلى الخلفية، يصل أثره فور نشره دون تحديث من المستخدمين. أما ما في التطبيق نفسه، كالإقلاع ورسم القوائم وعدد الطلبات، فيحتاج إلى إصدار جديد.
غالبًا لأن البيانات نمت: جداول كبرت واستعلامات كُتبت لحجم صغير، أو تقارير تعمل على قاعدة البيانات التشغيلية. البطء التدريجي شهرًا بعد شهر علامة على قاعدة البيانات، والبطء المفاجئ بعد إصدار علامة على تغيير في ذلك الإصدار.
في Google Play نعم، إذ تذكر Google أن مؤشرات Android vitals الأساسية، ومنها معدل عدم الاستجابة، تؤثر على ظهور التطبيق. وحتى دون ذلك، فالمستخدم الذي ينتظر كثيرًا يترك التطبيق ويكتب تقييمًا منخفضًا غالبًا.
خدمات وصفحات مرتبطة
اقرأ أيضًا
اعرف مصدر بطء تطبيقك قبل أن تدفع لإصلاحه
أرسل أين يظهر البطء ومتى بدأ وما لديك من وصول، ونقترح قياسًا محدد المدة يحدد المصدر في كل طبقة قبل أي تعديل.