سؤال : لماذا تكون بعض التطبيقات بطيئة بعد تطويرها ؟

[أحمد العيسى]

السلام عليكم

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

بماذا !! 

لا  أعلم  رغم عدم وجود أخطاء  ،  ويحدث هذا على كل إصدارات الأكسس

وإذا كانت مستخدمه ومطوره سوف تلاحظ ذلك :
بعد أن كانت فتح الشاشات تتم لحظياً ، اصبحت تأتي بعد ثانبة  أو ثانية ونصف

هل هناك برامج تقوم بالكشف على هذا التطبيق  وتشخيص الخلل  ومن ثم العلاج ؟

تم تعديل منذ 7 ساعات بواسطه أحمد العيسى

[jjafferr]

وعليكم السلام اخوي احمد

 

رجاء قرأة هذا الرابط ، واستخدم الاداة اللي فيه ، فانا لا استغني عنه وبإستمرار خلال عمل اي برنامج ، وقبل ان اعطيه الزبون

 

[أحمد العيسى]

اشكرك أخى جعفر على ردك

كما ذكرت  لا يوجد أخطاء فى تطبيقاتى

أما  بخصوص Auto Compact فإنى أستخدمه دائماً  حتى يدوياً

المشكلة فى تناقص السرعة عن سابقتها

مع ذلك قمت بتجربة برامجك الرائعة  .. لكنها لم تعمل عندى إلا على  أكسس 2010 فما أعلى

كمثال : النسخة التى ذكرت أنها متوافقة مع mdb   ونسخة Decompile_4.accdb قد كان لها هذا الخطأ عندى سواء على 2003 أو 2007

لكن هذا الخطأ غير موجود بـ 2010

[M.Abd Allah]

وعليكم السلام ورحمه الله وبركاته 

استاذ احمد 

اضافه الي ما ذكره معلمنا الجليل @jjafferr

ممكن قاعده البيانات تتقل لاكتر من سبب 

- منها انه ممكن يكون في احداث فيها مشاكل او فارغه وخصوصا حدثي on current و on load للنماذج اتاكد منها كويس 

- منها انك ممكن تعمل Requery في جداول مرتبطه بالنموذج كتير

- منها النماذج الفرعيه متحاولش تكتر فيها او عالاقل خلي مصدر بيناتها فارغ واستدعيها عند الحاجه 

دول اللي علي بالي دلوقتي 

تم تعديل منذ 4 ساعات بواسطه M.Abd Allah
نسيت شئ

[Foksh]

مشاركة مع الزملاء ..

من أسباب البطئ عند كثرة السجلات أيضاً ، بنية الاستعلامات نفسها ..

أيضاً الاعتماد على حقل المرفقات لإرفاق الملفات داخل الجداول بدلاً من اعتماد مسارها ..

أيضاً وباعتقادي عدم استخدام الفهرسة في الجداول قد يكون له أثر رجعي في التعامل مع البيانات عند تراكم البيانات داخل الجداول .

وأخيراً ، ما خطر ببالي هو تقسيم قاعدة البيانات الى أمامية وخلفية ..

 

[jjafferr]

1 ساعه مضت, أحمد العيسى said:

لكنها لم تعمل عندى إلا على  أكسس 2010 فما أعلى

كمثال : النسخة التى ذكرت أنها متوافقة مع mdb   ونسخة Decompile_4.accdb قد كان لها هذا الخطأ عندى سواء على 2003 أو 2007

معك حق ، فالاكسس ما دون 2010 كان يعمل على النواة 32 بت فقط ، واالاكسس 2010 فما فوق يملك نسخة 32 بت واخرى 64 بت ، مما نضطر لعمل الامر ptrSafe حتى يعمل البرنامج على النواتين.

فاذا كان التنصيب على حاسبتك النسخة 2010 فما فوق ، فيمكنك استعمال برنامج الرابط كما هو ،

واذا كان التنصيب على حاسبتك النسخة اقل من 2010 ، فيجب عليك حذف جميع الاسطر التي بها الامر PtrSafe.

 

بالاضافة الى عمل المرفق في الرابط اعلاه في تحسين الاداء ، اليك بعض الروابط  للاسباب الاخرى:

.

.

.

.

.

 

[أحمد العيسى]

حصيلة متعددة من المواضيع

سأطالعها  .. شكراً لك

[منتصر الانسي]

3 ساعات مضت, أحمد العيسى said:

يكون التطبيق فى بداية تصميمه سريعاً  جداً  فى الفتح والتنقل بين شاشاته

هذا الشيئ طبيعي فالبيانات تكون قليلة والأكواد مازالت في أول إصدار لها (أي أنها مثالية وفقاً للدراسة التي تمت عند التصميم)

3 ساعات مضت, أحمد العيسى said:

بعد إضافة المزيد من التطوير والأكواد تجده أصبح مثقلاً ..

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

بالإضافة لما جاء ضمن رد الأخ @jjafferr فنصيحتي هنا أنه عند الوصول لهذه المرحلة فأن الأمر يتطلب منك مراجعة شاملة للبرنامج من حيث

- إعادة بناء قاعدة البيانات بطريقة علمية سليمة وذلك لعدة أسباب منها

      - أن من ضمن الحلول التي كنت تضعها من المؤكد أنك قد تضطر لإجراء بعض التعديلات على الجداول 

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

- عدم التعامل مع بيانات الجدول مباشرة بل مع بيانات مفلترة منه (ماذا اقصد ؟)

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

كذلك عمليات البحث كلما كانت عينة البحث اصغر كان البحث أسرع لذلك وعلى سبيل المثال عندما يكون لدينا كود يقوم باستخدام دوال تجميع المجال لإسترجاع بيانات من إستعلام يحتوي بيانات سنة مالية واحدة سيكون أداؤه اسرع من نفس الكود لو كان يبحث في الجدول ككل

- تطبيق مفهوم الأرشفة

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

طبعا هذا يعتمد على طريقة عمل كل شركة ورؤية المطور فإذا رأي المطور أن الاحتياج للبيانات التاريخية يقل للحد الادنى مع مرور الوقت فيمكنه اقتراح الفكرة لانشاء الية عمل تشبه آلية انشاء السنة المالية الجديدة حيث يتم فيها أرشفة البيانات التاريخية كل سنة بترحيل بيانات السنة السابقة  الى قاعدة بيانات جديدة والاحتفاظ ببيانات احصائية منها (كآرصدة اول الفترة) وتصفية الجداول من جميع البيانات لتبدأ من الصفر للسنة المالية الجديدة بهذا سيظل البرنامج دائما خفيفا وسريعا 

- اعادة دراسة وتقييم التعليمات البرمجية

من واقع تجربتي فإني أحياناُ كثيرة وأثناء مراجعتي لأكواد قديمة قمت بكتابنها في أكثر من تطبيق تكون ردة فعلي (بماذا كنت أفكر وقتها ؟؟؟) أو أضحك على بساطته وأعتقد أن الكثير منا مر بنفس التجربة وهذا شيئ طبيعي فمع مرور الوقت وتراكم الخبرة تجد أن ما كنت تعالجه بكود يحتوي عشرات الأسطر بإمكانك معالجته بكود لايتعدى العشرة أسطر

كذلك الحال في الحالات التي ذكرتها في بداية كلامي فأنك قد تضطر إلى إضافة أكواد لحل مشاكل طارئة أو تبسيط مهام وتقضل إضافة الأكواد بدون مساس للاكواد الحالية وهذا قد يؤدي (وعن غير قصد) إلى مضاعفة العمل أو التعارض مع تعليمات برمجية قائمة وتحميلها بأعباء إضافية لم تنتبه لها في حينه أو إنتبهت لها ولكنك تجاهلتها إما لضيق الوقت أو لأثرها الغير ملحوظ وقتها على الاداء 

ومن خلال عملية إعادة دراسة وتقييم التعليمات البرمجية يمكنك إعادة كتابة التعليمات البرمجية التي يمكن إختصارها وتحسينها وهذا سيكون له الأثر الكبير في الأداء

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

تنويه - كل الملاحظات والنصائح المذكورة أعلاه هي مجرد تسليط للضوء على أهم أسباب تباطؤ تطبيقات أكسس (المرتبطة بالكائنات التابعة لأكسس) وطرق معالجتها وأريد على التأكيد على أنها لا تشمل كل الأسباب أو كل الحلول إنما هي أهم الأسباب والحلول (من وجهة نظري) 

يوجد أيضاً أسباب أخرى تكون مرتبطة بالشبكة والتي يكون حلها بأحد حلين (برمجي Software أو عتاد Hardware)

- الحل البرمجي يقوم به المطور خصوصاً بتطبيق النصيحة الثانية المذكورة أعلاه (إستخدام البيانات المفلترة) فقد تكون المشكلة غير ملموسة عند العمل في الوضع العادي (قاعدة البيانات المحلية) ولكن يمكن أن تظهر عند العمل من خلال الشبكة لذلك سيكون من الأفضل تصفية البيانات التي يتم العمل معها إلى الحد الأدنى حتى لايتم تحميل الشبكة ببيانات إضافية لن يحتاجها المستخدم أثناء العمل.

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

الملاحظة التي يجب ذكرها أن الحل الثاني يعتمد إعتماداً كلياً على أداء التطبيق في الوضع العادي (قاعدة البيانات المحلية) فمن غير المعقول أن أبحث عن حل لمشكلة الشبكة والبرنامج أصلاً بطئ حتى بدون شبكة.

في الأخير أرجو أن أكون قد قدمت فكرة بسيطة عن أهم مشاكل تباطؤ تطبيقات الأكسس