اتمام مهلت دروازه ۵۰۴

درحال مشاهده اسناد Apigee Edge هستید.
به اسناد Apigee X بروید. اطلاعات

نشانه

برنامه مشتری رمز وضعیت HTTP 504 را با پیام Gateway Timeout به‌عنوان پاسخ برای تماس‌های API دریافت می‌کند.

کد وضعیت HTTP - خطای 504 Gateway Timeout نشان می‌دهد که مشتری درطول اجرای میانای برنامه‌سازی کاربردی پاسخی به‌موقع از «دروازه Edge» یا سرور پشتیبان دریافت نکرده است

پیام‌های خطا

برنامه کارخواه کد پاسخ زیر را دریافت می‌کند:

HTTP/1.1 504 Gateway Timeout

در برخی موارد، ممکن است پیام خطای زیر نیز مشاهده شود:

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

چه چیزی باعث اتمام زمان درگاه می‌شود؟

مسیر معمول برای درخواست API ازطریق پلاتفرم Edge به‌صورت کارخواه -> مسیریاب -> پردازشگر پیام -> سرور زیرینه است، همان‌طور که در شکل زیر نشان داده شده است:

برنامه مشتری، مسیریاب‌ها، و «پردازشگرهای پیام» در پلاتفرم Edge با مقادیر مهلت زمانی مناسب راه‌اندازی می‌شوند. پلاتفرم Edge انتظار دارد که برای هر درخواست API براساس مقادیر مهلت زمانی، پاسخ در مدت زمان معینی ارسال شود. اگر در مدت زمان مشخص‌شده پاسخ را دریافت نکردید، 504 Gateway Timeout Error برگردانده می‌شود.

جدول زیر جزئیات بیشتری درباره زمان‌هایی که ممکن است در Edge مهلت زمانی رخ دهد ارائه می‌دهد:

علل احتمالی

در Edge، دلایل معمول خطای 504 Gateway Timeout عبارت‌اند از:

سرور زیرینه کُند است

اگر سرور زیرینه بسیار کند باشد یا زمان زیادی برای پردازش درخواست «میانای برنامه‌سازی کاربردی» نیاز داشته باشد، خطای 504 Gateway Timeout دریافت خواهید کرد. همان‌طور که در بخش بالا توضیح داده شد، مهلت زمانی می‌تواند در یکی از سناریوهای زیر رخ دهد:

1. «پردازشگر پیام» قبل‌از اینکه سرور زیرینه پاسخ دهد، زمانش به‌پایان می‌رسد.
2. پیش‌از اینکه «پردازشگر پیام»/ سرور زیرینه پاسخ دهد، زمان روتر به‌پایان می‌رسد.
3. برنامه کارخواه قبل‌از اینکه «روتر»/ «پردازشگر پیام»/ سرور زیرینه پاسخ دهد، زمانش به‌پایان می‌رسد.

بخش‌های زیر نحوه تشخیص و حل مشکل در هریک از این سناریوها را توضیح می‌دهد.

سناریو شماره ۱ «پردازنده پیام» قبل‌از اینکه سرور زیرینه پاسخ دهد، زمانش به‌پایان می‌رسد

تشخیص

می‌توانید از روش‌های زیر برای تشخیص اینکه خطای 504 Gateway Timeout به‌دلیل کندی سرور زیرینه رخ داده است یا نه استفاده کنید.

رویه ۱: استفاده از «ردیابی»

اگر مشکل همچنان فعال است (خطاهای 504 همچنان رخ می‌دهد)، مراحل زیر را دنبال کنید:

1. میانای برنامه‌سازی کاربردی تحت‌تأثیر را در واسط کاربر Edge ردیابی کنید. یا منتظر بمانید تا خطا رخ دهد یا اگر فراخوانی میانای برنامه‌سازی کاربردی را دارید، چند فراخوانی میانای برنامه‌سازی کاربردی انجام دهید و خطای 504 Gateway Timeout را بازتولید کنید.
2. پس‌از بروز خطا، درخواست خاصی را که کد پاسخ را به‌صورت 504 نشان می‌دهد بررسی کنید.
3. زمان سپری‌شده در هر مرحله را بررسی کنید و مرحله‌ای را که بیشترین زمان در آن صرف شده است یادداشت کنید.
4. اگر خطای مربوط به طولانی‌ترین زمان سپری‌شده را بلافاصله پس‌از یکی از مراحل زیر مشاهده کردید، این خطا نشان می‌دهد که سرور زیرینه کند است یا پردازش درخواست زمان زیادی می‌برد:
   • درخواست به سرور هدف ارسال شد
   • خط‌مشی ServiceCallout

در زیر نمونه‌ای از «ردیابی» نشان داده شده است که سرور زیرینه حتی پس‌از ۵۵ ثانیه پاسخ نداده است و درنتیجه خطای 504 Gateway Timeout رخ داده است:

در ردیابی بالا، «پردازنده پیام» پس‌از ۵۵۰۰۲ میلی‌ثانیه به‌دلیل پاسخ ندادن سرور زیرینه زمان‌بندی را تمام می‌کند.

رویه شماره ۲: استفاده از گزارش‌های «پردازشگر پیام»

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 حتی پس‌از ۵۵ ثانیه (lastIO=55000ms) پاسخی نداده است. درنتیجه، «پردازشگر پیام» زمان‌بندی را تمام کرد و خطای 504 Gateway Timeout را ارسال کرد.

   این را بررسی کنید: مهلت زمانی در «پردازشگر پیام» چگونه کنترل می‌شود؟ مهلت زمانی در «پردازشگر پیام» چگونه کنترل می‌شود. «پردازنده‌های پیام» معمولاً با مقدار مهلت زمانی پیش‌فرض ۵۵ ثانیه ازطریق دارایی HTTPTransport.io.timeout.millis تنظیم می‌شوند. این مقدار درنگ برای همه «پراکسی‌های API» که متعلق به سازمانی هستند که این «پردازشگر پیام» به آن سرویس می‌دهد قابل‌اعمال است. اگر سرور زیرینه ظرف ۵۵ ثانیه پاسخ ندهد، «پردازشگر پیام» منقضی می‌شود و خطای 504 Gateway Timeout را به مشتری ارسال می‌کند. مقدار مهلت زمانی مشخص‌شده در «پردازشگر پیام» می‌تواند با ملک io.timeout.millis مشخص‌شده در «پراکسی API» ملغی شود. این مقدار مهلت زمانی برای «پراکسی» API خاصی که خصوصیت ذکرشده در بالا در آن مشخص شده است اعمال می‌شود. برای مثال، اگر io.timeout.millis در «پراکسی API» روی ۱۰ ثانیه تنظیم شده باشد، مقدار مهلت زمانی ۱۰ ثانیه برای این «پراکسی API» خاص استفاده خواهد شد. اگر سرور زیرینه ظرف ۱۰ ثانیه برای «پراکسی میانای برنامه‌سازی کاربردی» خاصی پاسخ ندهد، «پردازشگر پیام» زمان‌بندی را تمام می‌کند و 504 Gateway Timeout خطایی به مشتری ارسال می‌کند.

وضوح

1. بررسی کنید چرا سرور نهایی بیش‌از ۵۵ ثانیه طول می‌کشد و ببینید آیا می‌توان آن را اصلاح/بهینه‌سازی کرد تا سریع‌تر پاسخ دهد.
2. اگر امکان رفع/بهینه‌سازی سرور زیرینه وجود ندارد یا مشخص است که سرور زیرینه زمان بیشتری نسبت به زمان اتمام پیکربندی‌شده نیاز دارد، مقدار زمان اتمام را در «مسیریاب» و «پردازشگر پیام» به مقدار مناسبی افزایش دهید.

سناریو #۲ - پیش‌از اینکه «پردازشگر پیام»/ سرور زیرینه پاسخ دهد، زمان روتر به‌پایان می‌رسد

اگر پیش‌از اینکه سرور پردازشگر پیام/زیرینه پاسخ دهد، زمان روتر به‌پایان برسد، ممکن است 504 Gateway Timeout خطا دریافت کنید. این اتفاق می‌تواند تحت یکی از شرایط زیر رخ دهد:

• مقدار درنگ تنظیم‌شده در «مسیریاب» کوتاه‌تر از مقدار درنگ تنظیم‌شده در «پردازشگر پیام» است. برای مثال، فرض کنید زمان اتمام در «رهیاب» ۵۰ ثانیه و در «پردازشگر پیام» ۵۵ ثانیه باشد.

  مهلت در رهیاب	درنگ در پردازنده پیام
  ۵۰ ثانیه	۵۵ ثانیه

• مقدار زمان انتظار در «پردازشگر پیام» با مقدار زمان انتظار بالاتری بااستفاده از دارایی io.timeout.millis که در پیکربندی نقطه پایانی هدف «پراکسی API» تنظیم شده است ملغی می‌شود:

  برای مثال، اگر مقادیر مهلت زمانی زیر تنظیم شده باشد:

  مهلت در رهیاب	درنگ در پردازنده پیام	مهلت زمانی در پراکسی API تمام شد
  ‫۵۷ ثانیه	۵۵ ثانیه	‫۱۲۰ ثانیه

  اما io.timeout.millis در «پراکسی میانای برنامه‌سازی کاربردی» روی ۱۲۰ ثانیه تنظیم شده است:

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

  در این صورت، «پردازنده پیام» پس‌از ۵۵ ثانیه زمان‌بندی نخواهد شد، حتی اگر مقدار زمان‌بندی آن (۵۵ ثانیه) کمتر از مقدار زمان‌بندی در مسیریاب (۵۷ ثانیه) باشد. به‌دلیل اینکه مقدار زمان انتظار ۵۵ ثانیه‌ای در «پردازشگر پیام» با مقدار ۱۲۰ ثانیه‌ای که در «پراکسی API» تنظیم شده است ملغی می‌شود. بنابراین مقدار زمان انتظار «پردازشگر پیام» برای این «پراکسی API» خاص ۱۲۰ ثانیه خواهد بود.

  ازآنجایی‌که مقدار مهلت زمانی «رهیاب» (۵۷ ثانیه) در مقایسه با ۱۲۰ ثانیه تنظیم‌شده در «پراکسی API» کمتر است، اگر سرور زیرینه پس‌از ۵۷ ثانیه پاسخ ندهد، مهلت زمانی رهیاب به‌پایان می‌رسد.

تشخیص

1. گزارش دسترسی NGINX را بررسی کنید (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)

2. اگر زمان روتر قبل‌از «پردازشگر پیام» به‌پایان برسد، وضعیت 504 را در گزارش‌های دسترسی NGINX برای درخواست API خاص خواهید دید و message id از «پردازشگر پیام» به‌عنوان - تنظیم خواهد شد. این امر به این دلیل است که «مسیریاب» در دوره زمان اتمام تنظیم‌شده در مسیریاب، پاسخی از «پردازشگر پیام» دریافت نکرده است.

   نمونه ورودی گزارش NGINX که خطای ۵۰۴ را به‌دلیل اتمام مهلت زمانی «مسیریاب» نشان می‌دهد

   

3. در مثال بالا، به وضعیت 504 در NGINX، شناسه پیام از «پردازنده پیام» -، و زمان سپری‌شده کل ۵۷٫۰۰۱ ثانیه توجه کنید. دلیل این است که زمان روتر پس‌از ۵۷٫۰۰۱ ثانیه به‌پایان رسید و هیچ پاسخی از «پردازشگر پیام» دریافت نکردیم.
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>

این خطا نمایش داده می‌شود زیرا وقتی زمان رهیاب به‌پایان می‌رسد، اتصال با «پردازشگر پیام» را می‌بندد. وقتی «پردازنده پیام» پردازش خود را تکمیل می‌کند، سعی می‌کند پاسخ را در مسیریاب بنویسد. ازآنجایی‌که اتصال به رهیاب قبلاً بسته شده است، Broken Pipe exception را در «پردازنده پیام» دریافت می‌کنید.

انتظار می‌رود این استثنا تحت شرایط توضیح داده‌شده در بالا دیده شود. بنابراین دلیل واقعی خطای 504 Gateway Timeout همچنان این است که سرور زیرینه زمان بیشتری برای پاسخ دادن صرف می‌کند و باید به این مشکل رسیدگی کنید.

وضوح

1. اگر سرور نهایی سفارشی باشد،
   1. بررسی کنید چرا سرور زیرینه برای پاسخ دادن زمان زیادی صرف می‌کند و ببینید آیا می‌توان آن را اصلاح/بهینه‌سازی کرد تا سریع‌تر پاسخ دهد.
   2. اگر امکان رفع/بهینه‌سازی سرور زیرینه وجود ندارد یا این واقعیت شناخته‌شده است که سرور زیرینه زمان زیادی طول می‌کشد، مقدار مهلت زمانی را در «مسیریاب» و «پردازشگر پیام» افزایش دهید.

      ایده: مقدار مهلت زمانی را در عناصر مختلف به ترتیب زیر تنظیم کنید: ترتیب: مهلت در «کارخواه» > مهلت در «مسیریاب» > مهلت در «پردازنده پیام» > مهلت در «پراکسی میانای برنامه‌سازی کاربردی»

2. اگر سرور پشتیبان NodeJS است، در این‌صورت:
   1. بررسی کنید آیا کد NodeJS با سرورهای زمینه‌ای دیگر تماس می‌گیرد و آیا زمان زیادی طول می‌کشد تا پاسخ را برگرداند. بررسی کنید چرا سرورهای پشتیبان زمان بیشتری می‌برند و مشکل را به‌طور مناسب برطرف کنید.
   2. بررسی کنید که آیا «پردازنده‌های پیام» از واحد پردازش مرکزی یا حافظه زیاد استفاده می‌کنند:
      1. اگر هریک از «پردازشگرهای پیام» با استفاده بالای CPU مواجه است، هر ۳۰ ثانیه سه داده‌دُمپ رشته بااستفاده از فرمان زیر تولید کنید:

         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. فراخوان‌های API را پایش کنید تا مطمئن شوید مشکل هنوز وجود دارد یا نه.
      5. با پشتیبانی Apigee Edge تماس بگیرید و داده‌های پشته، داده‌های انباشته، و گزارش‌های «پردازشگر پیام» را ارائه دهید (/opt/apigee/var/log/edge-message-processor/logs/system.log)برای کمک به بررسی علت استفاده بالای CPU/حافظه.

سناریو شماره ۳ - برنامه مشتری قبل‌از اینکه سرور پشتیبان/پردازنده پیام/مسیریاب پاسخ دهد، زمانش به‌پایان می‌رسد

اگر برنامه کارخواه قبل‌از پاسخ سرور پشتیبان منقضی شود، ممکن است 504 Gateway Timeout خطا دریافت کنید. این وضعیت ممکن است در شرایط زیر اتفاق بیفتد:

1. مقدار مهلت زمانی تنظیم‌شده در برنامه مشتری کمتر از مقدار مهلت زمانی تنظیم‌شده در روتر و «پردازشگر پیام» است:

   برای مثال، اگر مقادیر مهلت زمانی زیر تنظیم شده باشد:

   مهلت کارخواه تمام شد	مهلت در رهیاب	درنگ در پردازنده پیام
   ۵۰ ثانیه	‫۵۷ ثانیه	۵۵ ثانیه

   در این مورد، کل زمان دردسترس برای دریافت پاسخ درخواست API ازطریق Edge ‫۵۰ ثانیه یا کمتر است. این شامل زمان صرف‌شده برای ایجاد درخواست API، پردازش درخواست توسط Edge (مسیریاب، پردازشگر پیام)، ارسال درخواست به سرور زیرینه (درصورت وجود)، پردازش درخواست توسط زیرینه و ارسال پاسخ، پردازش پاسخ توسط Edge، و درنهایت ارسال پاسخ به کارخواه می‌شود.

   اگر رهیاب ظرف ۵۰ ثانیه به مشتری پاسخ ندهد، مشتری اتصال با رهیاب را می‌بندد و زمان اتصال به‌پایان می‌رسد. کارخواه کد پاسخ 504 را دریافت خواهد کرد.

   این کار باعث می‌شود NGINX کد وضعیت 499 را تنظیم کند که نشان می‌دهد کارخواه اتصال را بسته است.

تشخیص

1. اگر برنامه مشتری قبل‌از دریافت پاسخ از روتر زمان‌بندی شود، اتصال با روتر را می‌بندد. در این وضعیت، کد وضعیت ۴۹۹ را در گزارش‌های دسترسی NGINX برای درخواست API خاص خواهید دید.

   نمونه ورودی گزارش NGINX که کد وضعیت ۴۹۹ را نشان می‌دهد
   
   

2. در مثال بالا، توجه داشته باشید که وضعیت 499 در NGINX و کل زمان سپری‌شده ۵۰٫۰۰۱ ثانیه است. این نشان می‌دهد که زمان کارخواه پس‌از ۵۰٫۰۰۱ ثانیه به‌پایان رسیده است.
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. سرور نهایی را بررسی کنید تا دلیل اینکه بیش‌از ۵۷ ثانیه طول می‌کشد را پیدا کنید و ببینید آیا می‌توان آن را اصلاح/بهینه‌سازی کرد تا سریع‌تر پاسخ دهد.
   2. اگر امکان رفع/بهینه‌سازی سرور زیرینه وجود ندارد یا می‌دانید که سرور زیرینه زمان زیادی طول می‌کشد، مقدار مهلت زمانی را در «مسیریاب» و «پردازشگر پیام» افزایش دهید.
      
      

      ایده: مقدار مهلت زمانی را در عناصر مختلف به ترتیب زیر تنظیم کنید: ترتیب: مهلت در «کارخواه» > مهلت در «مسیریاب» > مهلت در «پردازنده پیام» > مهلت در «پراکسی میانای برنامه‌سازی کاربردی»

2. اگر پس‌زمینه‌ای از نوع NodeJS باشد، آنگاه:
   1. بررسی کنید آیا کد NodeJS با سرورهای پشتیبان دیگری تماس می‌گیرد یا نه و آیا برگشتن آن زمان زیادی طول می‌کشد یا نه. بررسی کنید چرا این سرورهای نهایی زمان بیشتری می‌برند.
   2. بررسی کنید که آیا «پردازنده‌های پیام» از واحد پردازش مرکزی یا حافظه زیاد استفاده می‌کنند:
      1. اگر «پردازنده پیام» با استفاده بالای CPU مواجه است، بااستفاده از فرمان زیر، هر ۳۰ ثانیه سه داده‌دُمپ رشته تولید کنید:

         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. فراخوان‌های API را پایش کنید تا مطمئن شوید مشکل هنوز وجود دارد یا نه.
      5. با پشتیبانی Apigee Edge تماس بگیرید و داده‌های تخلیه رشته، داده‌های تخلیه پشته، و گزارش‌های «پردازشگر پیام» را ارائه دهید (/opt/apigee/var/log/edge-message-processor/logs/system.log)تا به آن‌ها کمک کنید علت استفاده بالای CPU/حافظه را بررسی کنند.

مقدار زمان انتظار را در «مسیریاب» و «پردازشگر پیام» افزایش دهید

مقادیر مهلت زمانی را که باید در «مسیریاب» و «پردازشگر پیام» تنظیم شود با دقت و براساس الزاماتتان انتخاب کنید. مقادیر زمان اتمام بسیار بزرگ به‌صورت خودسرانه تنظیم نکنید. درصورت نیاز به راهنمایی، با پشتیبانی 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

   برای مثال، اگر می‌خواهید مقدار مهلت زمانی را روی ۱۲۰ ثانیه تنظیم کنید، آن را به‌صورت زیر تنظیم کنید: به‌صورت زیر تنظیم کنید:

   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 ازقبل وجود ندارد، آن را در دستگاه «پردازشگر پیام» ایجاد کنید.
2. خط زیر را به این فایل اضافه کنید:

   conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS

   برای مثال، اگر می‌خواهید مقدار مهلت زمانی را روی ۱۲۰ ثانیه تنظیم کنید، آن را به‌صورت زیر تنظیم کنید: به‌صورت زیر تنظیم کنید:

   conf_http_HTTPTransport.io.timeout.millis=120000

3. مطمئن شوید که این فایل متعلق به apigee است:

   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 بسیار کند باشد و/یا پردازش درخواست API زمان زیادی طول بکشد، خطای 504 Gateway Timeout دریافت خواهید کرد.

تشخیص

1. میانای برنامه‌سازی کاربردی تحت‌تأثیر را در واسط کاربر Edge ردیابی کنید.
2. یا منتظر بمانید تا خطا رخ دهد یا اگر فراخوانی API دارید، چند فراخوانی API انجام دهید و خطای 504 Gateway Timeout را بازتولید کنید.
3. توجه داشته باشید که در این مورد، ممکن است پاسخ موفقیت‌آمیزی در «ردیابی» ببینید.
   1. زمان «کارخواه/مسیریاب» به‌پایان می‌رسد زیرا «پردازنده پیام» در دوره اتمام زمان مشخص‌شده در «کارخواه/مسیریاب» (هرکدام که دوره اتمام زمان کوتاه‌تری داشته باشد) پاسخ نمی‌دهد. بااین‌حال، «پردازشگر پیام» به پردازش درخواست ادامه می‌دهد و ممکن است آن را باموفقیت تکمیل کند.
   2. علاوه‌براین، مجموعه مقدار HTTPTransport.io.timeout.millis تنظیم‌شده در «پردازشگر پیام» فقط درصورتی راه‌اندازی می‌شود که «پردازشگر پیام» با سرور پشتیبان HTTP/HTTPS ارتباط برقرار کند. به‌عبارت دیگر، این زمان انتظار وقتی راه‌اندازی نمی‌شود که هر خط‌مشی (به‌جز خط‌مشی ServiceCallout) در «پراکسی API» زمان زیادی طول بکشد.
4. پس‌از بروز خطا، درخواست خاصی را که طولانی‌ترین زمان سپری‌شده را دارد بررسی کنید.
5. زمان سپری‌شده در هر مرحله را بررسی کنید و مرحله‌ای را که بیشترین زمان در آن صرف شده است یادداشت کنید.
6. اگر طولانی‌ترین زمان سپری‌شده را در هریک از خط‌مشی‌ها به‌جز خط‌مشی «نوشته راهنمای سرویس» مشاهده کردید، این نشان می‌دهد که Edge برای پردازش درخواست زمان زیادی صرف می‌کند.
7. در اینجا نمونه‌ای از ردیابی واسط کاربر نشان داده شده است که زمان سپری‌شده بسیار زیاد در «خط‌مشی جاوا اسکریپت» را نشان می‌دهد:

   

8. در مثال بالا، متوجه می‌شوید که خط‌مشی جاوا اسکریپت زمان غیرطبیعی طولانی‌ای حدود ۲۴۵ ثانیه را می‌گیرد.

وضوح

1. بررسی کنید که آیا خط‌مشی‌ای وجود دارد که زمان زیادی طول می‌کشد تا پاسخ دهد و آیا کد سفارشی‌ای وجود دارد که ممکن است زمان زیادی برای پردازش نیاز داشته باشد. اگر چنین کدی وجود دارد، ببینید می‌توانید کد شناسایی‌شده را اصلاح/بهینه‌سازی کنید.
2. اگر کد سفارشی‌ای وجود ندارد که باعث زمان پردازش بالا شود، بررسی کنید که آیا «پردازشگرهای پیام» از واحد پردازش مرکزی یا حافظه بالا استفاده می‌کنند یا نه:
   1. اگر هریک از «پردازنده‌های پیام» با استفاده بالای CPU مواجه است، هر ۳۰ ثانیه سه داده‌دُمپ رشته بااستفاده از فرمان زیر تولید کنید:

      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. فراخوان‌های API را پایش کنید و تأیید کنید که مشکل هنوز وجود دارد یا نه.
   5. با پشتیبانی Apigee Edge تماس بگیرید و داده‌ریزی‌های رشته، داده‌ریزی پشته، و گزارش‌های «پردازشگر پیام» را ارائه دهید (/opt/apigee/var/log/edge-message-processor/logs/system.log)تا به آن‌ها کمک کنید علت استفاده بالای CPU/حافظه را بررسی کنند.

عیب‌یابی مشکلات بااستفاده از «پایش میانای برنامه‌سازی کاربردی»

پایش میانای برنامه‌سازی کاربردی به شما امکان می‌دهد مناطق مشکل‌دار را به‌سرعت جدا کنید تا مشکلات خطا، عملکرد، و تأخیر و منبع آن‌ها را تشخیص دهید، مثل برنامه‌های توسعه‌دهنده، کارگزاران میانای برنامه‌سازی کاربردی، هدف‌های زیرینه، یا پلاتفرم میانای برنامه‌سازی کاربردی.

گام‌به‌گام ازطریق یک سناریو نمونه که نشان می‌دهد چگونه بااستفاده از «پایش API» مشکلات ۵xx را در APIهای خود عیب‌یابی کنید. برای مثال، ممکن است بخواهید هشداری راه‌اندازی کنید تا وقتی تعداد کدهای وضعیت ۵۰۴ از آستانه خاصی فراتر رفت به شما اطلاع داده شود.