في الحقيقة نحن لا نسمح هذه الكلمة “الأداء Performance” الا عندما تكون هناك مشاكل، ويخبرك المستخدم بأن التطبيق بطئ وهناك مشكلة في أدائه Performance Issue.
ومن المعلوم ان حل مشاكل الأداء من المهام الصعبة في البرمجة، خصوصاً في الأنظمة الكبيرة التي تخدم الكثير من المستخدمين Large Scale Systems أو حتى الأنظمة الحساسه Missions Critical Systems، حيث تمكن الصعوبة في أن المشكلة قد تكون في عدة أجزاء مختلفة، مثلاً في كيفية كتابتك للخوارزميات Algorithms Structure أو في طريقة تعاملك مع الذاكرة Memory Allocations أو في التعامل مع القرص والملفات Disk I/O أو حتى في التعامل مع الشبكة Network I/O. فتحديد مكمن المشكلة أمر ليس في السهوله وحتى الخبراء قد يخطئوا ويشخصوا المشكلة بطريقة خطأ.
لذلك فالPerformance Tuning هو علم تجريبي أو حتى فن Art أكثر من مكونه علم نظري بحت Experimental Science ولكي تقوم به بشكل صحيح يجب عمل التجربة ومشاهده النتائج حتى تصل للمشكلة أو ال Root Cause وبعد ذلك تبني النتيجة وتقوم بحل المشكلة. فكلما تعمل في هذا المجال أكثر كلما تكتسب خبرة أفضل (حتى أن الشركات الكبيرة لديها وظائف كثيرة مختصه بهذا المجال Performance Engineer).
قبل محاولة حل المشكلة، هناك نقطة مهمه خصوصاً في البرامج أو المواقع التي يحصل بها Load عالي، وهو أنه يجب أن تتحدث مع صاحب المشروع وتعرف ما هي المتطلبات المتعلقة بالPerformance وحتى اذا كانت هناك خطط لتوسعه المشروع Scalability فيجب عليك معرفتها. حيث سوف يصعب عليك بعد أن تنتهي من المشروع ان تلتفت لتلك المتلطبات وقد يجعلك في موقف حرج للغايه (حدثت معي في أحد المشاريع حيث كنا نتوقع ان يعمل المشروع على dataset بأعلى تقدير 1GB ولكن بعد فترة تغيرت المتطلبات وأصبح الدعم يجب أن على الأقل 1TB).
لذلك ال Performance وال Scalability يجب أن تحدد في وثيقة متطلبات المشروع بشكل جيد، حتى تستطيع اختبارهم بعد كل Iteration في التطوير وتتأكد هل انت مراعي ال Goals المطلوبة.
اذا لم تستطيع ذلك، فيمكنك السؤال عن هذه الأسئلة:
1) ما هو ال Throughput المتوقع (عدد الأمور التي تنجز، مثلاً عدد الTransaction التي تتم في الموقع ، مثلاً 200 كل ثانية).
2) ما هو التأخير Latency المتوقع بين أي حدث Stimulus والاستجابه لهذه الحدث؟
3) كم عدد المستخدمين يستطيعوا العمل في آن واحد في هذا التطبيق Concurrent Users أو حتى المهام العادية Concurrent Tasks ؟
4) ما هو الThroughput وال Latency المتوقع عندما تكون الخدمه تعمل بأقصى امكانياتها Maximum Users or Tasks ؟
5) ما هو أقل وأسوء تأخير مقبول Maximum worst case latency؟
مثل هذه الأسئلة تسهل لك عمل التجارب Benchmark وعمل اختبارات Performance Test وتتأكد انك في الطريق الصحيح اثناء التطوير.
بشكل عام هناك طريقتين للنظر في مشاكل الأداء، نظرة تبدأ من الأعلى من طبقة التطبيق Top Down ، ونظرة تبدأ من أسفل حيث العتاد Bottom Down، والغالب أن طريقة التحليل Top Down هي الأكثر انتشاراً بين المطورين بينما ال Bottom Down فهي مختصه لفئة معينة من مختصى قياس الأداء حيث ينحصر عملهم على تشغيل المشروع على منصات مختلفة Different Platforms بعماريات مختلفة Different Architecture بأنظمة تشغيل مختلفة Different Operating System (على سبيل المثال أنظمة المترجمات Compilers وال VM وغيرها). حيث الهدف منها تشغيل التطبيق بنفس الاداء على تلك الانظمة فسوف تحتاج لعمل قياسات تبدأ من العتاد مثلاً عدد مرات عدم وجود المعلومات في الكيش CPU Cache Miss (فال Cache Miss يعني ان المعالج سوف يضيع بعضاً من ال Cycles في انتظار البيانات التي سيتم جلبها من الذاكرة فكلما تقل كلما يقل ال waiting time للمعالج) وغيرها من المعاملات التي يتم فحصها.
في طريقة ال Top Down سوف تبدأ من التطبيق أو الكود لديك، وفي الغالب يكون العميل أخبرك بأن هناك مشكلة في الأداء Performance Issue عندما يعمل النظام تحت الضغط Under Load، أو مثلاً تقوم بتغيير اعدادت في النظام أو البيئة التي يعمل عليها برنامجك فتؤثر سلباً على الأداء Performance Degradation أو (كما حصل معي) هو أن يغيير العميل أو مديرك في العمل متطلباته في ال Performance & Scalability وعليك أن تفى بتلك المتطلبات.
لكي تبدأ العمل، فهناك 3 خطوات عليك القيام بها بشكل متسلسل:
1) مراقبة التطبيق وجمع المعلومات Performance Monitoring: هذه أول خطوه تقوم بها بعد ابلاغك عن المشكلة بدون اي تفاصيل عنها أو أي مؤشر عن المسبب لها، وسوف تقوم بجمع كل المعلومات حول هذا التطبيق (مثل نسبة استهلاكه للمعالج، والذاكرة، وكرت الشبكة، والقرص) وهذه الخطوات في العادة تتم والبرنامج يعمل أي في Production Environments أو اذا استطعت تشغيله في بيئتك البرمجية Development Environments.
2) تشغيل التطبيق في بيئة للفحص Performance Profiling: وهنا ستقوم بجمع بعض المعلومات ايضاً عن التطبيق ولكنها اكثر شموليه من ال Monitoring وايضاً سوف يستوجب عليك القيام بها في بيئتك البرمجية فقط لأن تشغيل ال Profiler سوف يؤثر على التطبيق في أدائه واستجابته Effect Responsiveness and Throughput.
3) القيام بالتعديلات لتصحيح المشكلة Performance Tuning: سواء كان ذلك في تغيير الكود أو اعدادات النظام حتى تقوم بتصحيح الخلل سواء كان بطئ في الاستجابه Responsiveness أو بطئ في تنفيذ العمل Throughput.
مثال بسيط لمراقبة اداء التطبيق Performance Monitoring وهو مراقبة استهلاك المعالج CPU Utilizations، فحتى تحصل على اداء عالي يجب الاستفاده من كل CPU Cycle بشكل صحيح سواء كانت في التطبيقات العادية أو في التطبيقات متعدده المهام Multi-threading Applications والتي تعمل على جهاز في أكثر من معالج Multi-core او Multi-processes فهذا هو المنتشر حالياً.
اداء، برامج، ويندوز
لمعرفة استهلاك المعالج، في ويندوز أسهل طريقة هو ال Task Manager حيث ستوضح النسبة المستهلكه من كل المعالجات في اليمين، وفي اليسار ترى معدل الاستهلاك في كل كور فيه. الصورة الموجودة بها لونين ، اللون الأخضر يبين مدى استهلاك المعالج في اكواد التطبيقات User Utilization في العمليات مع مدى استهلاك تنفيذ أكواد النظام System Utilization (أو تسمى Kernel Utilization) ، أما اللون الأحمر يبين استهلاك ال Kernel ، والمسافه التي بينهم تبين مدى استهلاك ال User في المعالج. (لأظهار ذلك لديك من قائمة View أختر Show Kernel Time).
لكي تحصل على اداء عالي، فعليك بتقليل ال Kernel Utilization وجعله صفر% حتى يتم الاستفاده من وقت المعالج في تنفيد أكوادك في التطبيق.
مثلاً اذا كنت تبرمج بجافا وكنت تستخدم Stream للقرائه والكتابه فعليك استخدام Buffered*Stream حيث أن ال Stream العادي يقوم بعمل استدعاء لدوال النظام بشمل مستمر اثناء العملية وهكذا يزيد ال Kernel Utilization بينما في الBuffered سوف يحفظ في مخزن بحجم معين ويتم كتابتها مرة واحدة ، هكذا قللنا ال Kernel Utilization بسهوله. ويمكن ايضاً الاستفاده من Java NIO في بعض العمليات لأن ادائها عالي.
في ويندوز هناك ادوات اخرى مثلاً Performance Monitoring أو اداة الكونسول typepref والتي تقيس كثير من الأمور وليس ال CPU Utilization فقط. أيضاً انظمة Linux و يونكس لها ادوات مشابه للقياس.
نصل لنهايه البوست، هناك بعضاً من الأمور الأخرى المهمه مثلاً Memory Utilization وال Network Utilization والتي تحتاج للنظر فيها عندما تراقب تطبيقك، والمرة القادمة ان شاء الله سنتناول الحديث عن Performance في الجافا وبالأخص حول الصندق السحري JVM ، والذي وصل لدرجة عالية من المرونة تمكنك تطبيق اي Performance Requirement تريدها.
لهذا السبب ظهرت العديد من اللغات تعمل فوق منصه الجافا JVM تسمى Polyglot Languages مثل جايثون , Groovy والرائعه Scala وغيرهم، وهذا السبب هو الذي جعل تويتر تنقل اكوادها من روبي الى جافا في 2011
http://www.infoq.com/
الى لقاء قريب
