504 انتهاء مهلة البوابة

أنت تعرض مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. info

المشكلة

يتلقّى تطبيق العميل رمز حالة HTTP‏ 504 مع الرسالة Gateway Timeout كردّ على طلبات البيانات من واجهة برمجة التطبيقات.

يشير رمز حالة HTTP - الخطأ 504 Gateway Timeout إلى أنّ العميل لم يتلقّ استجابة في الوقت المناسب من Edge Gateway أو خادم الخلفية أثناء تنفيذ واجهة برمجة التطبيقات.

رسائل الخطأ

يتلقّى تطبيق العميل رمز الاستجابة التالي:

HTTP/1.1 504 Gateway Timeout

في بعض الحالات، قد تظهر رسالة الخطأ التالية أيضًا:

{
   "fault": {
      "faultstring": "Gateway Timeout",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
       }
    }
}

ما هي أسباب انتهاء مهلة البوابة؟

سيكون المسار المعتاد لطلب واجهة برمجة التطبيقات عبر منصة Edge هو العميل -> جهاز التوجيه -> معالِج الرسائل -> خادم الخلفية كما هو موضّح في الشكل أدناه:

يتم إعداد تطبيق العميل وأجهزة التوجيه ومعالجات الرسائل ضمن منصة Edge باستخدام قيم مهلة مناسبة. تتوقّع منصة Edge إرسال ردّ خلال فترة زمنية معيّنة لكل طلب واجهة برمجة تطبيقات استنادًا إلى قيم مهلة الانتظار. إذا لم يصلك ردّ خلال الفترة الزمنية المحدّدة، سيتم عرض 504 Gateway Timeout Error.

يقدّم الجدول التالي مزيدًا من التفاصيل حول الحالات التي قد تحدث فيها مهلات في Edge:

حدوث انتهاء للمهلة التفاصيل
تظهر المهلة في معالج الرسائل
  • لا يستجيب خادم الخلفية لمعالج الرسائل خلال مهلة محددة على معالج الرسائل.
  • تنتهي مهلة معالج الرسائل وترسل حالة الرد كـ 504 Gateway Timeout إلى جهاز التوجيه.
انتهت مهلة جهاز التوجيه
  • لا يستجيب معالج الرسائل لجهاز التوجيه خلال فترة المهلة المحددة على جهاز التوجيه.
  • تنتهي مهلة جهاز التوجيه ويرسل حالة الاستجابة "504 Gateway Timeout" إلى تطبيق العميل.
انتهت مهلة تطبيق العميل
  • لا يستجيب جهاز التوجيه لتطبيق العميل خلال مهلة الانتظار المحدّدة في جهاز التوجيه.
  • تنتهي مهلة تطبيق العميل وينهي حالة الاستجابة كـ 504 Gateway Timeout للمستخدم النهائي.

الأسباب المحتملة

في Edge، تشمل الأسباب الشائعة للخطأ 504 Gateway Timeout ما يلي:

السبب التفاصيل الخطوات المقدَّمة
بطء خادم الخلفية خادم الخلفية الذي يعالج طلب واجهة برمجة التطبيقات بطيء جدًا بسبب الحمولة العالية أو الأداء الضعيف. مستخدمو السحابة الإلكترونية العامة والخاصة
بطء معالجة طلبات واجهة برمجة التطبيقات من خلال Edge يستغرق Edge وقتًا طويلاً لمعالجة طلب واجهة برمجة التطبيقات بسبب ارتفاع عدد عمليات التحميل أو الأداء المنخفض.

خادم خلفي بطيء

إذا كان خادم الخلفية بطيئًا جدًا أو يستغرق وقتًا طويلاً لمعالجة طلب البيانات من واجهة برمجة التطبيقات، سيظهر لك خطأ 504 Gateway Timeout. كما هو موضّح في القسم أعلاه، يمكن أن تنتهي المهلة ضمن أحد السيناريوهات التالية:

  1. تنتهي مهلة "معالج الرسائل" قبل أن يستجيب خادم الخلفية.
  2. تنتهي مهلة جهاز التوجيه قبل استجابة معالج الرسائل/خادم الخلفية.
  3. تنتهي مهلة تطبيق العميل قبل استجابة جهاز التوجيه/معالج الرسائل/خادم الخلفية.

توضّح الأقسام التالية كيفية تشخيص المشكلة وحلّها في كل سيناريو من هذه السيناريوهات.

السيناريو الأول انتهاء مهلة معالج الرسائل قبل استجابة خادم الخلفية

التشخيص

يمكنك استخدام الإجراءات التالية لتشخيص ما إذا كان الخطأ 504 Gateway Timeout قد حدث بسبب بطء خادم الخلفية.

الإجراء 1: استخدام ميزة "التتبّع"

إذا كانت المشكلة لا تزال نشطة (ما زال يتم تسجيل أخطاء 504)، اتّبِع الخطوات التالية:

  1. تتبُّع واجهة برمجة التطبيقات المتأثّرة في واجهة مستخدم Edge وعليك الانتظار إلى أن يظهر الخطأ أو إذا كان لديك طلب بيانات من واجهة برمجة التطبيقات، وحينئذٍ يمكنك إجراء بعض طلبات البيانات من واجهة برمجة التطبيقات وإعادة إظهار الخطأ 504 Gateway Timeout.
  2. بعد حدوث الخطأ، راجِع الطلب المحدّد الذي يعرض رمز الاستجابة على النحو التالي: 504.
  3. تحقّق من الوقت المستغرَق في كل مرحلة وسجِّل المرحلة التي يتم فيها قضاء معظم الوقت.
  4. إذا لاحظت الخطأ في أطول وقت مضى مباشرةً بعد إحدى المراحل التالية، يعني ذلك أنّ خادم الخلفية بطيء أو يستغرق وقتًا طويلاً لمعالجة الطلب:
    • تم إرسال الطلب إلى الخادم الهدف.
    • سياسة ServiceCallout

في ما يلي نموذج لتتبُّع يُظهر أنّ خادم الخلفية لم يستجِب حتى بعد 55 ثانية، ما أدّى إلى حدوث خطأ 504 Gateway Timeout:

في عملية التتبّع أعلاه، تنتهي مهلة "معالج الرسائل" بعد 55002 ملي ثانية لأنّ خادم الخلفية لا يستجيب.

الإجراء 2: استخدام سجلات Message Processor

  1. راجِع سجلّ "معالج الرسائل" (/opt/apigee/var/log/edge-message-processor/logs/system.log).

  2. إذا ظهرت لك أخطاء Gateway Timeout وonTimeoutRead لطلب وكيل واجهة برمجة التطبيقات المحدّد في الوقت المحدّد، يعني ذلك أنّه قد انتهت مهلة "معالج الرسائل".

    نموذج لسجلّ "معالج الرسائل" يعرض خطأ "انتهاء مهلة البوابة"

    2015-09-29 20:16:54,340 org:myorg env:staging api:profiles rev:13 NIOThread@1
ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
AbstractResponseListener.onError(HTTPResponse@4d898cf1, Gateway
Timeout)
2015-09-29 20:16:57,361 org:myorg env:staging api:profileNewsletters rev:8
NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onTimeout() :
SSLClientChannel[C:XX.XX.XX.XX:443 Remote
host:192.168.38.54:38302]@120171 useCount=2 bytesRead=0
bytesWritten=824 age=55458ms lastIO=55000ms .onTimeoutRead

    في سجلّ "معالج الرسائل" أعلاه، لاحظت أن خادم الخلفية المُشار إليه بعنوان IP XX.XX.XX.XX لم يستجب حتى بعد 55 ثانية (lastIO=55000ms). نتيجةً لذلك، انتهت مهلة "معالج الرسائل" وأرسل خطأ 504 Gateway Timeout.

    راجِع هذا الرابط: كيف يتم التحكّم في مهلة الانتظار في Message Processor؟

    • كيفية التحكّم في المهلة في Message Processor عادةً ما يتم ضبط معالجات الرسائل باستخدام قيمة مهلة تلقائية تبلغ 55 ثانية) من خلال السمة HTTPTransport.io.timeout.millis. تنطبق قيمة المهلة هذه على جميع وكلاء واجهة برمجة التطبيقات التابعين لمؤسسة يقدّم لها معالج الرسائل هذا الخدمة.
      • إذا لم يستجِب خادم الخلفية في غضون 55 ثانية، سيتم انتهاء مهلة Message Processor وإرسال الخطأ 504 Gateway Timeout إلى العميل.
    • يمكن إلغاء قيمة المهلة المحدّدة في "معالج الرسائل" من خلال السمة io.timeout.millis المحددة داخل الخادم الوكيل لواجهة برمجة التطبيقات. تنطبق قيمة المهلة هذه على خادم وكيل واجهة برمجة تطبيقات محدد تم فيه تحديد السمة المذكورة أعلاه. على سبيل المثال، إذا تم ضبط io.timeout.millis على 10 ثوانٍ في "خادم وكيل واجهة برمجة التطبيقات"، سيتم استخدام قيمة المهلة التي تبلغ 10 ثوانٍ لهذا "خادم وكيل واجهة برمجة التطبيقات" المحدّد.
      • إذا لم يستجِب خادم الخلفية في غضون 10 ثوانٍ لوكيل واجهة برمجة التطبيقات المعني، تنتهي مهلة "معالج الرسائل" ويُرسِل الخطأ 504 Gateway Timeout إلى العميل.

الدقة

  1. تحقَّق من سبب استغراق خادم الخلفية أكثر من 55 ثانية لمعرفة ما إذا كان يمكن إصلاحه أو تحسينه للاستجابة بشكل أسرع.
  2. إذا لم يكن من الممكن إصلاح/تحسين خادم الخلفية أو إذا كان من المعروف أنّه يستغرق وقتًا أطول من المهلة التي تم ضبطها، عليك زيادة قيمة المهلة في "الراوتر" و"معالج الرسائل" إلى قيمة مناسبة.

السيناريو #2 - ينتهي مهلة جهاز التوجيه قبل أن يستجيب "معالج الرسائل"/خادم الخلفية

قد تظهر لك أخطاء 504 Gateway Timeout في حال انتهاء مهلة جهاز التوجيه قبل استجابة معالج الرسائل/خادم الخلفية. يمكن أن يحدث هذا في إحدى الحالات التالية:

  • قيمة المهلة التي تم تحديدها في جهاز التوجيه أقصر من قيمة المهلة المحددة في "معالج الرسائل". على سبيل المثال، لنفترض أنّ مهلة جهاز التوجيه هي 50 ثانية، بينما مهلة معالج الرسائل هي 55 ثانية.
    انتهاء مهلة جهاز التوجيه انتهاء مهلة "معالج الرسائل"
    ٥۰ ثانية ٥٥ ثانية
  • يتم إلغاء قيمة المهلة في Message Processor باستخدام قيمة مهلة أعلى باستخدام السمة io.timeout.millis التي تم ضبطها ضمن إعدادات نقطة النهاية المستهدَفة في "خادم وكيل واجهة برمجة التطبيقات":

    على سبيل المثال، في حال ضبط قيم المهلة التالية:

    انتهاء مهلة جهاز التوجيه انتهت المهلة في معالج الرسائل انتهاء المهلة في "خادم وكيل واجهة برمجة التطبيقات"
    57 ثانية ٥٥ ثانية 120 ثانية

    ولكن تم ضبط io.timeout.millis على 120 ثانية في خادم وكيل واجهة برمجة التطبيقات:

    <HTTPTargetConnection>
     <Properties>
          <Property name="io.timeout.millis">120000</Property>
      </Properties>
      <URL>http://www.apigee.com</URL>
</HTTPTargetConnection>

    بعد ذلك، لن تنتهي مهلة "معالج الرسائل" بعد 55 ثانية على الرغم من أنّ قيمة المهلة (55 ثانية) أقل من قيمة المهلة في جهاز التوجيه (57 ثانية). ويرجع ذلك إلى أنّه يتم إلغاء قيمة المهلة البالغة 55 ثانية في معالج الرسائل بقيمة 120 ثانية التي يتم ضبطها في الخادم الوكيل لواجهة برمجة التطبيقات. وبالتالي، ستكون قيمة المهلة لمعالج الرسائل لهذا الوكيل المحدّد لواجهة برمجة التطبيقات هي 120 ثانية.

    بما أنّ قيمة مهلة جهاز التوجيه (57 ثانية) أقل مقارنةً بـ 120 ثانية التي تم ضبطها داخل الخادم الوكيل لواجهة برمجة التطبيقات، ستنتهي مهلة جهاز التوجيه في حال عدم استجابة خادم الخلفية بعد 57 ثانية.

التشخيص

  1. راجِع سجلّ الوصول إلى NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log).

  2. إذا انتهت مهلة جهاز التوجيه قبل "معالج الرسائل"، ستظهر لك الحالة 504 في سجلات الوصول إلى NGINX لطلب واجهة برمجة التطبيقات المحدّد، وسيتم ضبط message id من "معالج الرسائل" على -. ويعود سبب ذلك إلى أنّ "الموجّه" لم يتلقّ أي استجابة من "معالج الرسائل" خلال فترة المهلة المحدّدة في "الموجّه".

    نموذج لإدخال سجلّ NGINX يعرض الخطأ 504 بسبب انتهاء مهلة جهاز التوجيه

  3. في المثال أعلاه، لاحِظ حالة 504 على NGINX، معرّف الرسالة من Message Processor هو - وإجمالي الوقت المنقضي هو 57.001 ثانية. ويرجع ذلك إلى انتهاء مهلة جهاز التوجيه بعد 57.001 ثانية ولم نتلقَّ أي استجابة من معالج الرسائل.
  4. في هذه الحالة، ستظهر لك Broken Pipe استثناء في سجلّات معالج الرسائل (/opt/apigee/var/log/edge-message-processor/logs/system.log). 
    2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>

يتم عرض هذا الخطأ لأنّه بعد انتهاء مهلة جهاز التوجيه، يغلق الاتصال مع Message Processor. عندما يُكمل "معالج الرسائل" عملية المعالجة، يحاول كتابة ردّ على جهاز التوجيه. بما أنّ الاتصال بجهاز التوجيه قد تم إغلاقه، يظهر لك الرمز Broken Pipe exception على "معالج الرسائل".

من المتوقّع أن يظهر هذا الاستثناء في الحالات الموضّحة أعلاه. وبالتالي، فإنّ السبب الفعلي لخطأ 504 Gateway Timeout لا يزال هو أنّ خادم الخلفية يستغرق وقتًا أطول للاستجابة وعليك معالجة هذه المشكلة.

الدقة

  1. إذا كان خادم خلفية مخصّصًا:
    1. تحقّق من سبب استغراق خادم الخلفية وقتًا طويلاً للاستجابة، ومعرفة ما إذا كان يمكن إصلاحه/تحسينه للاستجابة بشكل أسرع.
    2. إذا لم يكن من الممكن إصلاح/تحسين خادم الخلفية أو إذا كان من المعروف أنّه يستغرق خادم الخلفية وقتًا طويلاً، يمكنك زيادة قيمة المهلة في جهاز التوجيه ومعالج الرسائل.

      الفكرة: يمكنك ضبط قيمة المهلة على المكوّنات المختلفة بالترتيب التالي: .

      المهلة في العميل > المهلة في جهاز التوجيه > المهلة في معالج الرسائل > المهلة في وكيل واجهة برمجة التطبيقات
  2. إذا كان خادمًا لخلفية NodeJS، اتّبِع الخطوات التالية:
    1. تحقّق مما إذا كان رمز NodeJS يُجري مكالمات إلى أيّ خوادم خلفية أخرى وما إذا كان يستغرق وقتًا طويلاً لعرض استجابة. تحقّق من سبب استغراق خوادم الخلفية وقتًا أطول وحلّ المشكلة على النحو المناسب.
    2. تحقَّق مما إذا كان استخدام "معالجات الرسائل" كبير جدًا في وحدة المعالجة المركزية (CPU) أو الذاكرة:
      1. إذا كان أيّ من معالجات الرسائل يواجه استخدامًا مرتفعًا لوحدة المعالجة المركزية، يمكنك إنشاء ثلاثة ملفات تفريغ لبيانات الخيط كل 30 ثانية باستخدام الأمر التالي: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. إذا كان أيّ من معالجات الرسائل يستهلك ذاكرة بكثرة، يمكنك إنشاء ملف تفريغ أثر heap باستخدام الأمر التالي: 
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. أعِد تشغيل "معالج الرسائل" باستخدام الأمر أدناه. من المفترض أن يؤدي ذلك إلى خفض أداء وحدة المعالجة المركزية (CPU) والذاكرة: 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. عليك مراقبة طلبات البيانات من واجهة برمجة التطبيقات للتأكّد مما إذا كانت المشكلة لا تزال قائمة.
      5. يُرجى التواصل مع فريق دعم Apigee Edge وتقديم سجلّات عمليات تفريغ مؤشرات الترابط وتفريغ الذاكرة ومعالج الرسائل (/opt/apigee/var/log/edge-message-processor/logs/system.log)للمساعدة في التحقيق في سبب ارتفاع استخدام وحدة المعالجة المركزية/الذاكرة.

راجِع المقالة التالية: كيفية التحكّم في مهلة خوادم الخلفية في NodeJS على Message Processor

  • يعمل خادم الخلفية NodeJS ضمن عملية JVM من معالج الرسائل. يتم التحكّم في قيمة مهلة خوادم الخلفية في NodeJS من خلال السمة http.request.timeout.seconds في ملف nodejs.properties. يتم ضبط هذا السمة على 0 تلقائيًا، أي أنّ المهلة تكون غير مفعّلة تلقائيًا لجميع وكلاء واجهة برمجة التطبيقات الذين ينتمون إلى مؤسسة يقدّم لها "معالج الرسائل" هذا الخدمة. وبالتالي، حتى إذا استغرق خادم الخلفية NodeJS وقتًا طويلاً، لن تنتهي مهلة "معالج الرسائل".
  • ومع ذلك، إذا استغرق خادم الواجهة الخلفية لـ NodeJS وقتًا طويلاً وإذا استغرق طلب واجهة برمجة التطبيقات مدة تزيد عن 57 ثانية، سينتهي وقت الاستراحة في "الموجّه" وسيرسل خطأ 504 Gateway Timeout إلى العميل.

السيناريو 3 - انتهاء مهلة تطبيق العميل قبل استجابة جهاز التوجيه/معالج الرسائل/خادم الخلفية

قد تظهر لك أخطاء 504 Gateway Timeout إذا انتهت مهلة تطبيق العميل قبل أن يستجيب خادم الخلفية. يمكن أن يحدث هذا الموقف في الحالات التالية:

  1. تكون قيمة المهلة التي تم ضبطها في تطبيق العميل أقل من قيمة المهلة التي تم ضبطها في جهاز التوجيه ومعالج الرسائل:

    على سبيل المثال، في حال ضبط قيم المهلة التالية:

    مهلة العميل انتهاء مهلة جهاز التوجيه انتهاء مهلة "معالج الرسائل"
    ٥۰ ثانية 57 ثانية ٥٥ ثانية

    في هذه الحالة، يكون الوقت الإجمالي المتاح للحصول على استجابة لطلب البيانات من واجهة برمجة التطبيقات من خلال Edge أقل من 50 ثانية. ويشمل ذلك الوقت المستغرق لتقديم طلب من واجهة برمجة التطبيقات، والطلب الذي تتم معالجته من خلال Edge (جهاز التوجيه ومعالج الرسائل)، والطلب الذي يتم إرساله إلى خادم الخلفية (إن وُجد)، والمعالجة الخلفية للطلب وإرسال الرد، ومعالجة Edge للاستجابة وإعادة إرسالها في النهاية إلى العميل.

    إذا لم يستجِب جهاز التوجيه للجهاز العميل في غضون 50 ثانية، سيتم انتهاء مهلة الجهاز العميل وإغلاق الاتصال بجهاز التوجيه. سيتلقّى العميل رمز الاستجابة التالي: 504.

    سيؤدي ذلك إلى ضبط NGINX لرمز الحالة 499 الذي يشير إلى أنّ العميل أغلق الاتصال.

التشخيص

  1. إذا انتهت مهلة تطبيق العميل قبل أن يتلقّى استجابة من جهاز التوجيه، سيتم إغلاق الاتصال بجهاز التوجيه. في هذه الحالة، سيظهر لك رمز الحالة 499 في سجلّات الوصول إلى NGINX لطلب واجهة برمجة التطبيقات المحدّد.

    نموذج إدخال سجلّ NGINX يعرض رمز الحالة 499

  2. في المثال أعلاه، يُرجى العلم أنّ حالة 499 على NGINX وإجمالي الوقت المنقضي هو 50.001 ثانية. يشير ذلك إلى أنّ العميل انتهت مهلته بعد 50.001 ثانية.
  3. في هذه الحالة، ستظهر لك Broken Pipe استثناءات في سجلّات المعالج (/opt/apigee/var/log/edge-message-processor/logs/system.log).
    2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
java.io.IOException: Broken pipe
        at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
        at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
         … <snipped>
  4. بعد انتهاء مهلة المُوجِّه، يُغلق الاتصال بمعالج الرسائل. عندما يُكمل معالج الرسائل عملية المعالجة، يحاول كتابة الردّ إلى "الجهاز التوجيه". بما أنّ الاتصال بجهاز التوجيه قد تم إغلاقه، ستظهر لك القيمة Broken Pipe exception في "معالج الرسائل".
  5. من المتوقّع حدوث هذا الاستثناء في الحالات الموضّحة أعلاه. وبالتالي، لا يزال السبب الفعلي لخطأ 504 Gateway Timeout هو أنّ خادم الخلفية يستغرق وقتًا طويلاً للاستجابة، ويجب حلّ هذه المشكلة.

الدقة

  1. إذا كان خادم الخلفية مخصّصًا، اتّبِع الخطوات التالية:
    1. تحقّق من خادم الخلفية لتحديد سبب استغراقه أكثر من 57 ثانية لمعرفة ما إذا كان يمكن إصلاحه أو تحسينه للاستجابة بشكل أسرع.
    2. إذا لم يكن من الممكن إصلاح/تحسين خادم الخلفية أو إذا كنت تعلم أنّ خادم الخلفية سيستغرق وقتًا طويلاً، يمكنك عندئذٍ زيادة قيمة المهلة على جهاز التوجيه ومعالج الرسائل.

      الفكرة: يمكنك ضبط قيمة المهلة على المكوّنات المختلفة بالترتيب التالي: .

      المهلة في العميل > المهلة في جهاز التوجيه > المهلة في معالج الرسائل > المهلة في وكيل واجهة برمجة التطبيقات
  2. إذا كانت خلفية NodeJS، اتّبِع الخطوات التالية:
    1. تحقَّق مما إذا كان رمز NodeJS يُجري طلبات إلى أيّ خوادم خلفية أخرى وما إذا كان ذلك يستغرق وقتًا طويلاً للردّ. تحقّق من سبب استغراق خوادم الخلفية هذه وقتًا أطول.
    2. تحقَّق مما إذا كان استخدام "معالجات الرسائل" أعلى من وحدة المعالجة المركزية (CPU) أو استخدام الذاكرة:
      1. إذا كان "معالج الرسائل" يواجه استخدامًا مرتفعًا لوحدة المعالجة المركزية، يمكنك إنشاء ثلاثة ملفات تفريغ للخيوط كل 30 ثانية باستخدام الأمر التالي: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. إذا كان أحد معالجي الرسائل يستهلك ذاكرة بشكل كبير، يمكنك إنشاء مخطّط تجميع للذاكرة باستخدام الأمر التالي: 
        sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
      3. أعِد تشغيل معالج الرسائل باستخدام الأمر أدناه. من المفترض أن يؤدي ذلك إلى خفض استخدام وحدة المعالجة المركزية والذاكرة: 
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. عليك مراقبة طلبات البيانات من واجهة برمجة التطبيقات للتأكّد مما إذا كانت المشكلة لا تزال قائمة.
      5. يُرجى التواصل مع فريق دعم Apigee Edge وتقديم سجلّات عمليات تفريغ مؤشرات الترابط وتفريغ الذاكرة ومعالج الرسائل (/opt/apigee/var/log/edge-message-processor/logs/system.log)لمساعدة الفريق في التحقيق في سبب ارتفاع استخدام وحدة المعالجة المركزية/الذاكرة.

زيادة قيمة المهلة في جهاز التوجيه ومعالج الرسائل

اختَر قيم المهلة التي سيتم ضبطها على جهاز التوجيه ومعالج الرسائل بعناية استنادًا إلى متطلباتك. لا تضبط قيمًا كبيرة للمهلة بشكل عشوائي. إذا كنت بحاجة إلى المساعدة، يُرجى التواصل مع دعم Apigee Edge.

جهاز التوجيه

chown apigee:apigee /opt/apigee/customer/application/router.properties
  1. أنشئ ملف /opt/apigee/customer/application/router.properties على جهاز التوجيه، إذا لم يكن متوفّرًا.
  2. أضِف السطر التالي إلى هذا الملف: 
    conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS

    على سبيل المثال، إذا أردت ضبط قيمة المهلة على 120 ثانية، اضبطها على النحو التالي:

    conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
  3. تأكَّد من أنّ هذا الملف مملوك لشركة apigee:
  4. يُرجى إعادة تشغيل جهاز التوجيه: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  5. إذا كان لديك أكثر من جهاز توجيه واحد، كرِّر الخطوات أعلاه على جميع أجهزة التوجيه.

معالج الرسائل

  1. أنشئ ملف /opt/apigee/customer/application/message-processor.properties على جهاز Message Processor، إذا لم يكن متوفّرًا.
  2. أضِف السطر التالي إلى هذا الملف: 
    conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS

    على سبيل المثال، إذا أردت ضبط قيمة المهلة على 120 ثانية، اضبطها على النحو التالي:

    conf_http_HTTPTransport.io.timeout.millis=120000
  3. يُرجى التأكُّد من أنّ هذا الملف يملكه واجهة برمجة التطبيقات: 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. إعادة تشغيل "معالج الرسائل": 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. إذا كان لديك أكثر من معالج رسائل واحد، كرِّر الخطوات أعلاه على جميع معالجي الرسائل.

الفكرة: اضبط قيمة المهلة على المكوّنات المختلفة بالترتيب التالي:

المهلة في العميل > المهلة في جهاز التوجيه > المهلة في معالِج الرسائل > المهلة في وكيل واجهة برمجة التطبيقات

معالجة طلبات البيانات البطيئة من واجهة برمجة التطبيقات بواسطة Edge

إذا كان متصفّح Edge بطيئًا جدًا و/أو يستغرق وقتًا طويلاً لمعالجة طلب واجهة برمجة التطبيقات، ستظهر لك رسالة خطأ 504 Gateway Timeout.

التشخيص

  1. يمكنك تتبُّع واجهة برمجة التطبيقات المتأثرة في واجهة مستخدم Edge.
  2. يمكنك إما الانتظار إلى أن يحدث الخطأ أو إذا كان لديك طلب بيانات من واجهة برمجة التطبيقات، يمكنك إجراء بعض طلبات البيانات من واجهة برمجة التطبيقات وإعادة إنتاج الخطأ 504 Gateway Timeout.
  3. تجدر الإشارة إلى أنه في هذه الحالة، قد ترى ردًا ناجحًا في تقرير التتبُّع.
    1. ينتهي وقت انتظار جهاز التوجيه/العميل لأنّ "معالج الرسائل" لا يستجيب في مهلة محددة على جهاز التوجيه/العميل (أيهما أقصر). ومع ذلك، يواصل "معالج الرسائل" معالجة الطلب وقد يُكمِل العملية بنجاح.
    2. بالإضافة إلى ذلك، لا يتم تشغيل قيمة HTTPTransport.io.timeout.millis المحددة في "معالج الرسائل" إلا إذا كان "معالج الرسائل" يتواصل مع خادم خلفية HTTP/HTTPS. بعبارة أخرى، لن يتم تشغيل مهلة الانتظار هذه عندما تستغرق أي سياسة (باستثناء السياسة ServiceCallout) ضمن API Proxy وقتًا طويلاً.
  4. بعد حدوث الخطأ، راجِع الطلب المحدّد الذي يستغرق أطول وقتًا.
  5. تحقّق من الوقت المستغرَق في كل مرحلة وسجِّل المرحلة التي تم فيها قضاء معظم الوقت.
  6. إذا لاحظت أطول مدة في أيّ من السياسات باستثناء سياسة callout في الخدمة، يعني ذلك أنّ Edge يستغرق وقتًا طويلاً لمعالجة الطلب.
  7. في ما يلي مثال على تتبع واجهة المستخدم الذي يعرض وقتًا مُستغرَقًا مرتفعًا جدًا في سياسة JavaScript:

  8. في المثال أعلاه، لاحظت أنّ سياسة JavaScript تستغرق مدّة طويلة بشكل غير طبيعي، تبلغ نحو 245 ثانية.

الدقة

  1. تحقَّق مما إذا كانت السياسة التي استغرقت وقتًا طويلاً للردّ وهل هناك أي رمز مخصّص قد يستغرق وقتًا طويلاً لمعالجته. في حال توفّر أي من هذه الرموز البرمجية، تحقَّق مما إذا كان بإمكانك إصلاح أو تحسين الرمز المحدَّد.
  2. إذا لم يكن هناك رمز مخصّص قد يتسبب في زيادة وقت المعالجة، تحقّق مما إذا كانت معالجات الرسائل تواجه استخدامًا مرتفعًا لوحدة المعالجة المركزية أو الذاكرة:
    1. إذا تم استخدام وحدة المعالجة المركزية (CPU) بشكل مرتفع في أي من معالجي الرسائل، أنشِئ ثلاث عمليات نسخ لسلاسل المحادثات كل 30 ثانية باستخدام الأمر التالي: 
      JAVA_HOME/bin/jstack -l PID > FILENAME
    2. إذا كان أيّ من معالجي الرسائل يستخدِم ذاكرة بكثافة، يمكنك إنشاء مخطّط تجميع للذاكرة باستخدام الأمر التالي: 
      sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
    3. أعِد تشغيل معالج الرسائل باستخدام الأمر أدناه. ومن المفترض أن يؤدي هذا إلى تعطيل وحدة المعالجة المركزية (CPU) والذاكرة. 
      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
    4. راقِب طلبات البيانات من واجهة برمجة التطبيقات وتأكَّد مما إذا كانت المشكلة لا تزال قائمة.
    5. يمكنك التواصل مع Apigee Edge Support وتقديم عمليات تفريغ سلاسل المحادثات ولقطات لأجزاء من الذاكرة وسجلات معالجة الرسائل (/opt/apigee/var/log/edge-message-processor/logs/system.log)لمساعدتهم في التحقيق في سبب ارتفاع معدّل استخدام وحدة المعالجة المركزية (CPU) أو الذاكرة.

تشخيص المشاكل باستخدام ميزة "مراقبة واجهة برمجة التطبيقات"

تتيح لك ميزة مراقبة واجهة برمجة التطبيقات رصد المشاكل بسرعة لتشخيص الأخطاء ومشاكل الأداء ووقت الاستجابة ومصدرها، مثل تطبيقات المطوّرين أو الخوادم الوكيلة لواجهات برمجة التطبيقات أو استهدافات الخلفية أو منصة واجهة برمجة التطبيقات.

الاطّلاع على سيناريو نموذجي يوضّح كيفية تحديد مشاكل 5xx وحلّها في واجهات برمجة التطبيقات باستخدام "مراقبة واجهة برمجة التطبيقات" على سبيل المثال، قد تحتاج إلى إعداد تنبيه لتلقّي إشعار عندما يتجاوز عدد رموز الحالة 504 حدًا معيّنًا.