Optimizing بالعربي
مقالات عملية مرتبة حسب المجال والمستوى، اختر المجال المناسب واقرأ من مستوى مبتدئ إلى محترف.
ليه SELECT COUNT(*) بطيء على الملايين، وإزاي تعدّه في مللي ثانية
لو صفحة تعرض إجمالي الصفوف بتعلّق ثواني، المشكلة مش في السيرفر. المقال للمحترف يشرح ليه COUNT(*) بيعمل فحص تسلسلي كامل، وينزّل الزمن من ~9.4 ثانية لـ ~3 مللي ثانية بتقدير reltuples وعدّاد مُصان بـ trigger، مع SQL شغّال، أرقام مقاسة، trade-offs، ومتى لا تستخدمه، مع مصادر رسمية.
ترتيب أعمدة الـ Composite Index: ليه الفهرس موجود والاستعلام لسه بطيء
فهرس على عمودين موجود فعلًا، ومع ذلك الاستعلام بياخد 420ms ويعمل Seq Scan. السبب مش السيرفر، السبب ترتيب الأعمدة جوه الفهرس. مقال للمحترف يشرح قاعدة الـ leftmost prefix وقاعدة Equality-Sort-Range بمثال دليل التليفونات، مع SQL وEXPLAIN ANALYZE شغّال على PostgreSQL 16، أرقام مقاسة (420ms ← 2.8ms)، trade-offs، ومتى الترتيب مش هيفرق، ومصادر رسمية.
Keyset Pagination للمحترف: ليه OFFSET 100000 بياخد 850ms والـ Seek بياخد 2ms
لو صفحة 5000 في الـ API بتاعتك بطيئة رغم وجود index، المشكلة في OFFSET نفسه مش في السيرفر. الـ Keyset/Seek Method بيخلّي أي صفحة تتحمّل في زمن ثابت. مقال للمحترف بمثال دليل التليفونات للمبتدئ، شرح علمي لسلوك OFFSET، كود SQL وEXPLAIN ANALYZE على PostgreSQL 16، أرقام مقاسة (850ms ← 2ms)، التعامل مع الترتيب المركّب، 4 trade-offs، ومتى Keyset مش الحل، مع مصادر رسمية.
PgBouncer للمحترف: استوعب 500 عامل تطبيق على 20 اتصال PostgreSQL فقط
لو خدمتك بترمي "too many connections" تحت الحمل رغم إن CPU وRAM فاضيين، المشكلة في إدارة الاتصالات مش في حجم السيرفر. PgBouncer في وضع transaction بيخلّي 500 عامل تطبيق يشتغلوا على 20 اتصال حقيقي، بكونفيج قابل للنسخ، أرقام مقاسة، شرح session مقابل transaction، trade-offs، ومتى متستخدمهوش.
Bloom Filters للمحترف: امنع 99% من DB Queries بـ 1.2MB
لو خدمتك بتعمل 18 ألف lookup query في الثانية و87% منهم بيرجّع فاضي، Bloom Filter بـ 1.2MB في الذاكرة بيرفض 99% منهم في 200 نانوثانية قبل ما يلمسوا PostgreSQL. مقال للمحترف بمثال البوّاب للمبتدئ، تعريف من ورقة Bloom 1970 في CACM، الرياضيات الفعلية (m, k, n)، كود Python شغّال على pybloom-live 4.0، أرقام مقاسة على workload فيه 60M lookup/يوم (الفاتورة من 1,840$ لـ 410$، توفير 78%)، 4 trade-offs خفية، ومتى Bloom Filter يبقى اختيار غلط.
Tree Shaking للمحترف: شيل 340KB من Bundle بدون ما تلمس الكود
لو bundle الإنتاج بتاعك 892KB رغم إن المستخدم بيستعمل 3 شاشات بس، المشكلة مش في المكتبات — هي في إن Webpack مش قادر يثبت إن باقي الكود "آمن للحذف". المقال للمحترف بيشرح ESM static analysis، sideEffects flag، و Pure Annotations بأمثلة لـ Webpack 5 و Rollup و esbuild، مع أرقام مقاسة من إنتاج Next.js 14 وقياس قبل/بعد لمتجر فعلي.
103 Early Hints للمحترف: ابعت preload للمتصفح قبل الـ HTML بـ 320ms
لو موقعك العربي بياخد 2.4 ثانية قبل LCP رغم HTTP/2 و preload جوّا الـ head، انت بتفقد round-trip كامل لمّا المتصفح يستنّى الـ HTML الأول قبل ما يبدأ يحمّل CSS و fonts. 103 Early Hints بيرسل preload hints قبل ما الـ origin يجاوب بـ 200 OK، وبيخفّض LCP من 2.4 ثانية لـ 0.9 ثانية على workload e-commerce حقيقي. مقال للمحترف بمثال موظف الاستقبال للمبتدئ، شرح علمي من RFC 8297، إعداد NGINX 1.25 + Node.js شغّال، أرقام مقاسة من 38K زيارة/يوم، 4 trade-offs خفية، ومتى Early Hints بيكون مضيعة وقت.
Materialized Views في PostgreSQL للمحترف: من تقرير 8 ثوانٍ لـ 40ms بدون لمس كود التطبيق
لو dashboard المبيعات في PostgreSQL بياخد 8 ثوانٍ كل مرة، الـ DB مش بطيئة — الـ aggregation بيتعاد على 240 مليون صف في كل request. Materialized View بـ 14 سطر SQL بيخزّن النتيجة كجدول فيزيكال ويرجع في 40ms. مقال للمحترف مع مثال محل البقالة للمبتدئ، شرح علمي من توثيق PostgreSQL 16، كود قابل للنسخ، أرقام إنتاج من e-commerce بـ 62 مليون طلب، CONCURRENTLY refresh، 4 trade-offs خفية، ومتى MV بتكون كارثة.
PostgreSQL Index Types للمحترف: BRIN vs GIN vs GiST vs B-Tree — اختار صح أو اتفرج على الفاتورة
دليل احترافي لاختيار نوع index المناسب في PostgreSQL 16. مقارنة عملية بأرقام مقاسة بين B-Tree و BRIN و GIN و GiST على جدول 240 مليون صف، مع 4 trade-offs خفية، فخاخ Bloat و Index-only scan، ومتى الـ index بيكون كارثة بدل ما يحسّن.