Optimizing بالعربي
مقالات عملية مرتبة حسب المجال والمستوى، اختر المجال المناسب واقرأ من مستوى مبتدئ إلى محترف.
Table Partitioning في PostgreSQL للمتوسط: من 4.2 ثانية لـ 12ms على جدول 80 مليون صف
لو جدول الطلبات في PostgreSQL وصل 80 مليون صف وأي SELECT آخر 30 يوم بياخد 4.2 ثانية، الـ DB مش ضعيفة — هي بتفحص الجدول كله. Declarative Partitioning في PostgreSQL 16 بيقسّم الجدول لـ partitions شهرية بحيث الـ query يضرب 2.6 مليون صف بدل 80 مليون، ويرجع في 12 مللي ثانية. مقال للمتوسط بمثال أرشيف الفواتير للمبتدئ، تعريف علمي من توثيق PostgreSQL 16، كود SQL قابل للنسخ، أرقام مقاسة من إنتاج e-commerce، 4 trade-offs، ومتى Partitioning بيكون كارثة بدل ما يحسّن.
Read Replicas في PostgreSQL للمتوسط: وزّع 80% من القراءات بدون تعديل سطر كود
لو سيرفر PostgreSQL الإنتاج بيرفع CPU لـ 92% الساعة 8 الصبح ومعظم الطلبات SELECT بسيطة، الـ DB مش ضعيفة — هي بتخدم القراءة والكتابة من نفس الـ instance. Read Replica واحد بيستقبل 80% من القراءات بدون لمس كود التطبيق، وبيخفّض P95 latency من 480ms لـ 38ms. مقال للمتوسط بمثال المكتبة العامة للمبتدئ، شرح علمي للـ Streaming Replication من توثيق PostgreSQL 16، إعداد primary + standby قابل للنسخ، توجيه القراءات بـ pgpool-II، أرقام مقاسة من API بـ 12K طلب/دقيقة، 4 trade-offs حقيقية، ومتى Read Replica بتكون مضيعة وقت.
Service Worker Caching للمتوسط: خلّي موقعك يفتح في 0.4 ثانية للزائر العائد
لو الزائر اللي بيرجع لموقعك بيستنّى 2.8 ثانية كأنه أول زيارة، Service Worker بـ 40 سطر JavaScript بينزّل الزمن لـ 0.4 ثانية ويخلّي الموقع يفتح حتى من غير إنترنت. مقال للمتوسط بمثال أمين المخزن للمبتدئ، تعريف علمي من Service Worker API spec، 3 استراتيجيات caching بكود شغّال على Workbox 7، أرقام مقاسة من e-commerce عربي بـ 84,000 زائر شهريًا (P75 من 2.8s لـ 0.4s، bounce rate -38%، فاتورة CDN -54%)، 4 trade-offs خفية، ومتى Service Worker بيكون كارثة بدل ما يفيد.
PgBouncer للمتوسط: شغّل 5,000 اتصال متزامن على Postgres بـ 512MB ذاكرة
لو Postgres بيرفض اتصالات جديدة عند 100 مستخدم ويرمي "too many clients already"، السيرفر مش ضعيف — Postgres بيشغّل process منفصل لكل اتصال. PgBouncer بـ 12 سطر config بيخلّيك تشغّل 5,000 client متزامن بنفس السيرفر. مقال للمتوسط بمثال شبابيك البنك للمبتدئ، شرح علمي للـ pooling modes الثلاثة، ملف pgbouncer.ini شغّال، أرقام مقاسة من API FastAPI (الـ throughput من 2,400 لـ 14,800 طلب/دقيقة)، 4 trade-offs حقيقية، ومتى لا تستخدمه أصلاً.
PgBouncer للمتوسط: من 800 اتصال على PostgreSQL لـ 25 بدون تعديل سطر كود
لو السيرفر بيرمي FATAL: too many connections وانت لسه عند 800 user، PostgreSQL مش بطيء. PgBouncer في 12 سطر إعداد بيختصر 800 اتصال لـ 25، بدون تعديل تطبيقك. مثال شباك البنك للمبتدئ، شرح transaction pooling، أرقام إنتاج (RAM 5.6GB → 280MB، توفير 410$ شهريًا)، 4 trade-offs، ومتى لا تستخدمه.
Redis Pipelining للمتوسط: 1000 عملية من 240ms لـ 8ms بسطر واحد
لو سكربتك بيعمل 1000 SET على Redis في 240 مللي ثانية، Redis مش بطيء — انت بتدفع تذكرة شبكة لكل عملية. Pipelining في redis-py بـ 3 سطور بينزّل الزمن لـ 8 مللي ثانية على نفس Redis. مقال للمتوسط بمثال طلبات الديليفري للمبتدئ، تعريف علمي من توثيق Redis، كود Python شغّال على redis-py 5.0 و Redis 7.4، أرقام مقاسة على AWS r6g.large، 4 trade-offs خفية، ومتى Pipelining بيكسرلك المنطق بدل ما يحسّنه.
Cache Stampede للمتوسط: لما الـ cache يخلص فاتورة DB بتقفز 14x — والحل في 8 سطور
لو الـ Redis cache بتاعك بيخلص فجأة ولقيت 4,200 طلب يضربوا PostgreSQL في ثانيتين، الـ DB مش غلطانة. الظاهرة اسمها Cache Stampede، وحلها مش زيادة الذاكرة ولا scaling. مقال للمتوسط بمثال شباك التذاكر للمبتدئ، تعريف علمي من ورقة Vattani 2015، 3 حلول بكود Python شغّال على redis-py 5.0 و PostgreSQL 16، أرقام مقاسة من إنتاج e-commerce بـ 4,200 طلب/ثانية (P99 من 6,200ms لـ 18ms)، 4 trade-offs، ومتى الحلول دي تكون مبالغة هندسية.
Event Loop في Node.js للمتوسط: ليه السيرفر بيتجمد و CPU لسه 30%
لو السيرفر بيرد 4 ثواني على endpoint بسيط و CPU بيقول 30%، Node.js مش بطيء — فيه عملية واحدة بتقفل event loop. مقال للمتوسط بمثال المخبز للمبتدئ، تعريف علمي من توثيق Node.js الرسمي و libuv، كود قياس delay بـ perf_hooks وحل بـ Worker Threads على Node.js 22، أرقام مقاسة على endpoint توقيع PDF (P95 من 4,180ms لـ 92ms)، 4 trade-offs، ومتى Worker Threads بتزود تعقيد بدون فايدة.
N+1 Query للمتوسط: ليه dashboard بسيط بيعمل 1,200 استعلام في كل request
لو dashboard المنتجات بيرد في 6 ثواني وفاتورة DB قفزت 3x من غير ما traffic يزيد، الاحتمال الأكبر إن الـ ORM بيعمل 1,247 استعلام على كل request بدل واحد. مقال للمتوسط بمثال البيتزا للمبتدئ، تعريف علمي من توثيق Django و Hibernate، كود Prisma 5.18 شغّال على PostgreSQL 16 يقيس الفرق بين 4,200ms و 38ms، طريقة كشف المشكلة بـ pg_stat_statements، 3 trade-offs خفية في eager loading، ومتى include بيكلّف أكتر ما بيوفّر.