مقدمة

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

الإقتراحات

الواجهة الأمامية

• عمل validation للبيانات في ال frontend -قدر الإمكان- قبل ارسالها لتقليل (ولو بشكل صغير) عدد الطلبيات المرسلة للخلفية.

بخصوص الخلفية

• إذا تم استخدام ال REST API، فيجب مراجعة كل ال API من ناحية حجم البيانات المرسلة وكيفية ارسالها.
• لغة البرمجة المستخدمة لها تأثير بدورها، أحد اللغات التي لها سمعة جيدة خاصة في موضوع concurrency والأداء الجيد هي لغة Go، مثلا: يمكن استخدام إطار العمل Fiber.
• طريقة كتابة الكود بأي لغة برمجة كذلك له تأثير على الأداء، لذلك المستحسن أن يكون هناك مبرمجين ذوي خبرة يساهمون في بناءه أو على الأقل في عمل ال code review للكود قبل دمجه.
• استخدام قاعدة بيانات معروفة بأدائها الجيد كال Postgres أو Oracle، وإذا كان التوجه لل NoSQL فيمكن استخدام MongoDB مثلا.
• إذا كان هناك استخدام لقاعدة بيانات علائقية فيجب التأكد من وضع indexes بشكل صحيح على الجداول.
• تصميم جداول قاعدة البيانات يمكن أن يأثر على الأداء إذا كان هناك Joins كثيرة وكذلك ال data type المستخدمة، خاصة IDs الجداول.
• استخدام ORM للتعامل مع قاعدة البيانات يمكن يؤثر على الأداء، بدلها ممكن التفكير في استخدام Query Builder يكون Type-safe.
• استخدام ال caching قدر الإمكان (في مكانه المناسب) وعمل له expiration duration.
• تقليل ال network calls، مثلا: محاولة تقليل عدد ال queries التي ترسل إلى قاعدة البيانات.
• إذا كان ال Backend الرئيسي يعتمد على third-party API أو فيه processing يأخذ وقت وأعتقد أنه لدينا هذه الحالة (نظرا لأنه من رقم التعريف الوطني يتم جلب معلومات حول الشخص) فالأصح هو أن يتم تنفيذ التواصل ك async أو تنفيذها داخل worker أي (background task) أو حتى الإعتماد على مكتبة تعمل ال batch processing لمعالجة البيانات وإعادة محاولة الفاشلة منها وإبلاغ المستخدم فور الإنتهاء.
• يمكن حتى التفكير في تعقيد التصميم -قليلا- باستخدام تقنية ال messaging queue ك Rabbit، Kafka أو غيرها لتقليل الضغط على السيرفر بحيث أنه يتم تخزين ال requests فال queue، نرجع رسالة للمستخدم مثلا بأننا سنعالج طلبه وسيتلقى اشعار فور الإنتهاء، وال server يولي يعالج الطلبات بعقلو وابلاغ المستخدم فور الإنتهاء.

بخصوص البنية التحتية:

• يجب مراجعة ما تم استخدامه في الحل الأول بشكل كامل.
• اختيار ال cloud provider بعناية (إذا كان متاح هذا الخيار).
• عمل horizontal scaling ويمكن كذلك vertical scaling (بشكل حكيم) لل instances، مثلا لو تم استخدام k8s يمكن عمل replicas لل pod ويولي يخدم ال load balancer وكذلك نشوف إمكانية عمل أكثر من availability zones وحتى أكثر من region (لست متأكدا من توفر هذا الأمر في الحلول المحلية). وأهم شيء:
• عمل execution plan لكل ال queries التي تذهب لقاعدة البيانات وتحسينها إن امكن.
• عمل إختبار لأداء النظام (performance tests) قبل إطلاقه، من أهمها: إختبارات ال stress وال load، ومراقبة استهلاك ال resources و سلوك النظام.

خاتمة

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

لماذا غيرنا اللغة وإطار العمل؟: لأنه تم التعديل على البنية التحتية بإضافة موارد كبيرة لكن بدون نتيجة فعالة، إعادة بناءه بال Go مع مراعات الأداء في كل سطر كود تكتبه وعمل اختبار أداء جعلت النظام حاليا مستقر في ال production.