كيف حسّنّا سرعة الأداء الملموسة بتثبيت دوال Vercel على منطقة طوكيو — التخلص من الرحلة عبر المحيط الهادئ

ملخص هذا المقال

• سبب بطء لوحة التحكم هو أن "دوال Vercel كانت في الولايات المتحدة وقاعدة البيانات في طوكيو"، مما يعني رحلة ذهاب وإياب عبر المحيط الهادئ في كل مرة
• يمكن التحقق من المنطقة التي تم تنفيذ الدالة فيها من خلال ترويسة الاستجابة x-vercel-id
• بتثبيت المنطقة على طوكيو عبر regions في vercel.json وتوازي الاستعلامات، انخفض الوقت في قياساتنا الداخلية من عدة ثوانٍ إلى نحو 0.2 ثانية

«الانتقال بين شاشات لوحة التحكم يستغرق عدة ثوانٍ» — هذا سجل للتحقيق في هذا البطء الملموس، وتحديد السبب، ثم إصلاحه. لم نعتمد على التخمين، بل حللنا المشكلة بالقياس الفعلي.

الأعراض والتشخيص

كان الانتقال بين الشاشات يستغرق نحو 3 ثوانٍ. عند تحديد ما إذا كان البطء ناتجًا عن «بداية استجابة الخادم (TTFB)» أو عن «جلب المحتوى»، تبيّن أن بداية الاستجابة كانت سريعة، وأن جلب البيانات داخل الصفحة هو البطيء.

كل استعلام على حدة كان سريعًا بحد ذاته، بضع ميلي ثوانٍ فقط على مستوى قاعدة البيانات. ومع ذلك كان الأداء الإجمالي بطيئًا. هنا اشتبهنا في موقع التنفيذ (المنطقة الجغرافية).

السبب الأول: رحلة ذهاب وإياب عبر المحيط الهادئ

عند فحص ترويسة الاستجابة x-vercel-id، تبيّن أن الدالة كانت تُنفَّذ في منطقة شرق الولايات المتحدة (iad1). في المقابل، كانت قاعدة البيانات (Supabase) في طوكيو. بمعنى آخر، كانت كل عملية استعلام تتطلب رحلة ذهاب وإياب بين اليابان والولايات المتحدة.

هكذا تبدو الترويسة (توضيحيًا).

x-vercel-id: hnd1::iad1   ← 受け口は東京(hnd1)だが、実行は米国(iad1)

إذا تكرر الاستعلام عدة مرات، فإن كل مرة تعني رحلة أخرى عبر المحيط الهادئ، مما يراكم زمن الاستجابة (Latency).

السبب الثاني: انتظار الاستعلامات بشكل متسلسل

بالإضافة إلى ذلك، كانت الشاشة الرئيسية تجلب عدة عمليات تجميع بشكل متسلسل (واحدة تلو الأخرى). وهذا يعني أن تأخير الرحلة ذهابًا وإيابًا يتراكم بعدد مرات التكرار.

الإجراءات المتخذة

تثبيت المنطقة على طوكيو

أضفنا تحديد المنطقة في vercel.json لجعل الدالة تُنفَّذ في طوكيو (hnd1).

{ "regions": ["hnd1"] }

بهذا أصبحت قيمة x-vercel-id هي hnd1::hnd1، أي أن كلًا من الدالة وقاعدة البيانات باتا في طوكيو. وهذا أزال تأخير الرحلة ذهابًا وإيابًا.

توازي الاستعلامات

قمنا بجعل عمليات جلب التجميعات التي كانت تنتظر بالتسلسل تعمل بالتوازي باستخدام Promise.all، ودمجنا في الوقت نفسه عمليات الجلب المكررة في عملية واحدة.

النتيجة

في قياساتنا الداخلية، انخفض وقت عرض الشاشة الرئيسية من عدة ثوانٍ إلى نحو 0.2 ثانية. والنقطة المهمة هي أننا سرّعنا المعالجة نفسها دون الاعتماد على التخزين المؤقت (Cache). لذا تبقى البيانات المعروضة محدّثة دائمًا.

الدروس المستفادة

• عندما تكون «الاستعلامات سريعة لكن الشاشة بطيئة»، لا تشتبه فقط في سرعة قاعدة البيانات، بل أيضًا في المسافة الفعلية بين الدالة وقاعدة البيانات (المنطقة الجغرافية).
• تُعد x-vercel-id وسيلة بسيطة وقوية للتحقق من منطقة التنفيذ.
• في البيئات التي تكون فيها تكلفة الرحلة ذهابًا وإيابًا مرتفعة، يصبح الانتظار المتسلسل عاملاً حاسمًا في الإضرار بالأداء. وتأثير التوازي كبير جدًا.

الخلاصة

كان جوهر البطء الملموس هو الرحلة ذهابًا وإيابًا بين الولايات المتحدة وطوكيو. من خلال إجراءين هما تثبيت المنطقة الجغرافية وتوازي الاستعلامات، تمكّنّا من تحسين الأداء الملموس بشكل كبير دون اللجوء إلى التخزين المؤقت. إذا شعرت بأن SSR أو لوحة التحكم بطيئة، جرّب أولًا التحقق من العلاقة بين منطقة التنفيذ وموقع قاعدة البيانات.