قُصاصات

 1import time
 2
 3
 4start_time = time.time()
 5longProcess()
 6end_time = time.time()
 7
 8
 9if end_time - start_time < 5:
10    doSomething()

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

تنقسم قواعد البيانات من حيث طريقة تخزين البيانات على مستوى الجداول إلى نوعين:

1. Row-oriented Database
2. Column-oriented Database

هذا التقسيم متعلق بآلية التخزين في الـ Storage System.

التخزين في الـ Row-Oriented Databases

يتم تخزين القيم الخاصة بنفس الـ Entity على صف واحد بحيث تكون كلها متتالية، وهذا هو الافتراضي في قواعد البيانات المعروفة كـ PostgreSQL و SQLite.

من الإعدادات المفيدة في MariaDB / MySQL، هي إعدادات الـ Slow Query Log،

وهي من الطرق التي تستخدم (بدون أدوات مراقبة خارجية) لمعرفة الـ Queries البطيئة في قاعدة البيانات،

يمكنك تحديد عدد الثواني التي إذا تجاوزها وقت تشغيل الـ Query يعتبر بطيئا.

توجد العديد من الإعدادات الأخرى كتحديد مسار الملف الخاص بالـ Log، أو بعض الشروط الإضافية التي يجب أن ينطبق حتى يتم تسجيل الـ Query على أنه بطيء

بروتوكول HTTP يستخدم Request-Response model، مما يعني أن السيرفر لا يستطيع إرسال بيانات إلى الـ Client ما لم يقم الـ Client أولا بإرسال Request.

لكن يمكن استخدام SSE (Server Sent Events) لإرسال البيانات من السيرفر للـ Client، لا يزال الـ Client بحاجة إلى إرسال Request أولا، لكن يتم استخدام Keep-Alive لإبقاء الاتصال مفتوحا، والسيرفر سيرسل البيانات دون انهاء الـ Response، في الصورة السابقة تجد أنه قد تم إرسال أكثر من رسالة من السيرفر إلى الـ Client في أوقات مختلفة، كلها تعتبر Response واحدة لكن تم تقسيما وإرسالها بالتدريج،

اقوم اليوم ببعض التجارب المتعلقة ببروتوكول HTTP لفهمه بشكل أعمق،

حاولت إرسال الـ Request باستخدام netcat عبر TCP مباشرة دون استخدام HTTP Client.

الصورة المرفقة توضح الفرق بين نسخة HTTP 1.0 و HTTP 1.1.

في النسخة 1.0 ستضطر لإرسال كل HTTP Request باتصال TCP جديد، بينما في النسخة 1.1، يمكن إرسال أكثر من HTTP Request على نفس الاتصال مما يزيد من سرعة العملية (ستختصر الوقت والموارد اللازمة لفتح اتصال جديد).