本頁面由 Cloud Translation API 翻譯而成。

504 閘道逾時

查看 Apigee Edge 說明文件。
前往 Apigee X說明文件。資訊

問題

用戶端應用程式收到訊息 504 的 HTTP 狀態碼 Gateway Timeout 做為 API 呼叫的回應。

HTTP 狀態碼 - 504 Gateway Timeout 錯誤表示用戶端在執行 API

錯誤訊息

用戶端應用程式會取得下列回應代碼：

HTTP/1.1 504 Gateway Timeout

在某些情況下，系統可能也會觀察到以下錯誤訊息：

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

哪些因素會導致閘道逾時？

透過 Edge 平台提出 API 要求的一般路徑為 Client ->路由器 ->訊息處理器 ->後端伺服器，如下圖所示：

Edge 平台中的用戶端應用程式、路由器和訊息處理器均已設定合適的逾時值。Edge 平台預期回應會在特定期間內傳送逾時時間值。如果您沒有在指定的時間，然後傳回 504 Gateway Timeout Error。

下表詳細列出 Edge 中可能逾時的時間：

逾時發生	詳細資料
訊息處理器發生逾時	後端伺服器未在指定的逾時時間內回應訊息處理者保留期結束訊息處理器逾時，並以 `504 Gateway Timeout` 的形式將回應狀態傳送至路由器。
路由器發生逾時	訊息處理器未在指定的逾時時間內回應路由器路由器的延遲時間路由器逾時，並以 `504 Gateway Timeout` 的形式將回應狀態傳送至用戶端應用程式。
用戶端應用程式發生逾時	路由器未在指定的逾時時間內回應用戶端應用程式等候時間用戶端應用程式逾時，並結束對使用者的回應狀態 `504 Gateway Timeout`。

可能原因

在 Edge 中，導致 504 Gateway Timeout 錯誤的常見原因為：

原因	詳細資料	步數
後端伺服器速度緩慢	由於負載過高或過低，處理 API 要求的後端伺服器速度太慢成效不佳	公開與私有雲使用者
Edge 的 API 要求處理速度緩慢	由於負載過高或過低，Edge 需要很長的時間才能處理 API 要求才需進行

慢速後端伺服器

如果後端伺服器速度太慢，或是處理 API 要求需要很長的時間，請您會收到 504 Gateway Timeout 錯誤。如上節所述，逾時可能是出現下列情況：

訊息處理器在後端伺服器回應前逾時。
在訊息處理器/後端伺服器回應前，路由器逾時。
用戶端應用程式在路由器/訊息處理器/後端伺服器回應前逾時。

以下各節將說明如何診斷及解決上述問題情境

情境 1 訊息處理器在後端伺服器回應前逾時

診斷

您可以使用下列程序診斷是否發生 504 Gateway Timeout 錯誤原因是後端伺服器速度緩慢

使用追蹤記錄程序 1

如果問題仍未解決 (仍有 504 項錯誤)，請按照下列說明操作步驟：

在 Edge UI 中追蹤受影響的 API。您可以等待錯誤發生，或者您擁有 API 呼叫，然後發出一些 API 呼叫，並重現 504 Gateway Timeout 錯誤。
發生錯誤後，請檢查特定要求，該要求會顯示如下所示的回應代碼： 504。
檢查每個階段的經過時間，並記下時間最長的階段支出。
如果您在其中一個就會知道後端伺服器運作速度緩慢，或是需要很長的時間處理要求：
- 已將要求傳送至目標伺服器
- 服務呼叫政策

下列範例提供追蹤記錄範例，顯示後端伺服器沒有回應導致 504 Gateway Timeout 錯誤：

在上述追蹤記錄中，「訊息處理器」會在 55002 毫秒後逾時，因為後端伺服器沒有回應。

程序 2 使用訊息處理器記錄

查看訊息處理器記錄 (/opt/apigee/var/log/edge-message-processor/logs/system.log)。

如果找到特定 API Proxy 要求的 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 錯誤。

檢查：訊息處理器如何控制逾時？

這是如何控制訊息處理器的逾時設定。訊息處理器使用屬性，將預設逾時值設為 55 秒) HTTPTransport.io.timeout.millis。逾時值為適用於屬於此服務的機構訊息處理器。
- 如果後端伺服器未在 55 秒內回應，則「訊息」處理器逾時並將 504 Gateway Timeout 錯誤傳送至用戶端。
訊息處理器中指定的逾時值可以是屬性 io.timeout.millis 已覆寫 會在 API Proxy 內指定這個逾時值適用於特定 API 指定了上述屬性的 Proxy。舉例來說，在 API Proxy 中，io.timeout.millis 設為 10 秒，之後這個特定 API Proxy 將使用 10 秒的逾時值。
- 如果在 10 秒內沒有回應 API Proxy 之後，訊息處理器會逾時並傳送 504 Gateway Timeout 錯誤。

解析度

確認後端伺服器處理時間超過 55 秒的原因，看看能否解決問題固定/最佳化，以加快回應速度
如果無法修正/最佳化後端伺服器，或是已知後端伺服器花費的時間超過所設定的逾時時間，然後將路由器和訊息處理器上的逾時值調高到合適的值。

情境 #2 - 在訊息處理器/後端伺服器回應前，路由器逾時

如果路由器在訊息顯示前逾時，可能會收到 504 Gateway Timeout 錯誤處理器/後端伺服器會回應。發生這種情況的可能原因如下：

路由器設定的逾時值短於在「訊息」中設定的逾時值處理器。假設路由器的逾時時間是 50 秒，而「訊息」應用程式處理器為 55 秒。

路由器發生逾時訊息處理器逾時

50 秒 55 秒

路由器發生逾時	訊息處理器逾時
50 秒	55 秒

訊息處理器的逾時值會覆寫使用目標端點設定中設定的 io.timeout.millis 屬性 API Proxy：

舉例來說，假設已設定下列逾時值：

路由器發生逾時	訊息處理器逾時	API Proxy 發生逾時
57 秒	55 秒	120 秒

但在 API Proxy 中，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 秒，在 API Proxy 中設定的 120 秒。所以訊息處理器的逾時值為 120 秒

相較於路由器的 120 秒設定，路由器的逾時值較低 (57 秒) 而如果後端伺服器未在 57 後回應，路由器就會逾時秒內請求驗證碼。

診斷

查看 NGINX 存取記錄 (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)。
如果路由器在訊息處理器之前逾時，您會看到 504 的狀態特定 API 要求的 NGINX 存取記錄，以及 message id 訊息處理器將設為 -。這是因為路由器沒有收到任何回應訊息處理器，在路由器上設定的逾時期限內。

因路由器逾時而顯示 504 的 NGINX 記錄項目樣本
在上述範例中，請注意 NGINX 上的 504 狀態，訊息 ID 處理器為 -，總時長為 57.001 秒這是因為路由器已逾時超過 57.001 秒，且我們沒有收到訊息處理器的任何回應。

在這種情況下，訊息中會顯示 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 錯誤還是導致後端伺服器的回應時間較長必須解決這個問題

解析度

如果是自訂後端伺服器

查看後端伺服器回應時間過長的原因，看看是否能解決問題固定/最佳化，以加快回應速度

如果無法修正/最佳化後端伺服器，或是已知因此，請提高路由器和訊息處理器。

提案：為下列各元件設定逾時值順序：

用戶端逾時 >路由器逾時 >訊息逾時處理器 >API Proxy 發生逾時

如為 NodeJS 後端伺服器，則：
1. 檢查 NodeJS 程式碼是否向任何其他後端伺服器發出呼叫，以及是否在回應時間。瞭解為何後端伺服器花費的時間較長，視情況修正問題。
2. 檢查訊息處理器的 CPU 或記憶體用量是否偏高：
  1. 如有任何訊息處理器的 CPU 使用率過高，就會產生三個執行緒使用下列指令每隔 30 秒執行一次傾印：
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. 如有任何訊息處理器的記憶體用量偏高，堆積 dump，請使用下列指令：
```
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. 監控 API 呼叫，確認問題是否仍未解決。
  5. 與 Apigee Edge 支援團隊聯絡，並提供執行緒傾印、記憶體快照資料及訊息處理器記錄 (/opt/apigee/var/log/edge-message-processor/logs/system.log)可協助並找出 CPU/記憶體用量偏高的原因。

勾選：如何控制訊息中的 NodeJS 後端伺服器逾時處理器

NodeJS 後端伺服器會在訊息處理器的 JVM 程序中執行。 NodeJS 後端伺服器的逾時值是由屬性控制 nodejs.properties 檔案中的 http.request.timeout.seconds。這個屬性預設為 0，也就是說，系統根據預設，會停用所有屬於此訊息處理者之機構的 API Proxy。因此即使 NodeJS 後端伺服器耗時很長，因此訊息處理器不會逾時。
但如果 NodeJS 後端伺服器耗時較長，以及 API 花費的時間要求 >57 秒後，路由器將逾時並傳送 504 Gateway Timeout 錯誤。

情境 #3：用戶端應用程式在路由器/訊息處理器/後端伺服器之前逾時回覆

如果用戶端應用程式在504 Gateway Timeout 回應。發生這種情況的可能原因如下：

用戶端應用程式設定的逾時值小於路由器和訊息處理器：

舉例來說，假設已設定下列逾時值：

用戶端逾時	路由器發生逾時	訊息處理器逾時
50 秒	57 秒	55 秒

在這個案例中，透過 Edge 取得 API 要求回應的總時間長度小於或等於 50 秒。包括發出 API 要求所需的時間由 Edge (Router、Message Processor) 處理，要求將要求傳送至後端伺服器後端處理要求並傳送回應時，Edge 會處理回應，最後傳回用戶端。

如果路由器未在 50 秒內回應用戶端，用戶端會逾時，並關閉與路由器的連線。用戶端會收到 504。

如此一來，NGINX 就會設定 499 狀態碼，指出用戶端已關閉以獲得最佳效能和最安全的連線

診斷

如果用戶端應用程式在收到路由器的回應前逾時，關閉與路由器的連線。在此情況下，您會看到狀態碼為 499 的特定 API 要求的 NGINX 存取記錄。
顯示狀態碼 499 的 NGINX 記錄項目範例
在上述範例中，請注意 NGINX 上的 499 狀態和經過的總時間： 50.001 秒。這表示用戶端在 50.001 秒之後逾時。

在這種情況下，訊息中會顯示 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>

在路由器逾時後，系統會關閉與訊息處理器的連線。當訊息處理器完成處理後，會嘗試將回應寫入路由器。由於連至路由器的連線已經關閉，因此訊息處理器會顯示 Broken Pipe exception。
這種例外狀況屬於預期情況。所以 504 Gateway Timeout 錯誤表示後端伺服器的回應時間較長，您必須解決該問題

解析度

如果是自訂後端伺服器，請按照下列步驟操作：

檢查後端伺服器，找出作業時間超過 57 秒的原因，並看看並加以修正/最佳化，以更快回應

如果無法修正/最佳化後端伺服器，或您知道因此需要較長的時間，路由器和訊息處理器

提案：為下列各元件設定逾時值順序：

用戶端逾時 >路由器逾時 >訊息逾時處理器 >API Proxy 發生逾時

如為 NodeJS 後端：
1. 檢查 NodeJS 程式碼是否會呼叫任何其他後端伺服器，所以會很久才回訪找出後端伺服器耗時較長的原因。
2. 檢查訊息處理器的 CPU 或記憶體用量是否偏高：
  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. 監控 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

請在下列位置建立 /opt/apigee/customer/application/router.properties 檔案：路由器機器 (如果尚未存在)。

在這個檔案中新增下列程式碼：

conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS

舉例來說，假設您想將逾時值設為 120 秒，請將其設為如下：

conf_load_balancing_load.balancing.driver.proxy.read.timeout=120

確保這個檔案的擁有者為 Apigee：

重新啟動路由器：

/opt/apigee/apigee-service/bin/apigee-service edge-router restart

如果你有多個路由器，請在所有路由器上重複上述步驟。

訊息處理器

在以下位置建立 /opt/apigee/customer/application/message-processor.properties 個檔案：訊息處理器機器 (如果不存在)。
在這個檔案中新增下列程式碼：
```
conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS
```
舉例來說，假設您想將逾時值設為 120 秒，請將其設為如下：
```
conf_http_HTTPTransport.io.timeout.millis=120000
```

確保這個檔案的擁有者為 Apigee：

chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

重新啟動訊息處理器：

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

如果您有多部訊息處理器，請針對所有「訊息」重複上述步驟。處理器：

建議：請按照下列步驟，依下列順序設定不同元件的逾時值：

用戶端逾時 >路由器逾時 >訊息處理器逾時 >API Proxy 發生逾時

Edge API 要求的處理速度緩慢

如果 Edge 的速度非常慢，且/或處理 API 要求的時間過長，您就會收到 504 Gateway Timeout 個錯誤。

診斷

在 Edge UI 中追蹤受影響的 API。
請等待錯誤發生，或者如果您有 API 呼叫，請進行一些 API 呼叫然後重現 504 Gateway Timeout 錯誤。
請注意，在這種情況下，追蹤記錄中可能會顯示成功的回應。
1. 由於訊息處理器未在指定的逾時期限 (以最短的時限為準)。但「訊息處理者」會繼續處理該要求，並
2. 此外，HTTPTransport.io.timeout.millis 只有在「訊息處理器」與 HTTP/HTTPS 通訊時，「訊息處理器」才會觸發後端伺服器換句話說，在任何政策生效的情況下，經由 API Proxy 導入，則需要較長的時間。
發生錯誤後，請找出最長的特定要求經過時間：
檢查每個階段的經過時間，並記下時間最長的階段支出。
如果您在「服務」以外的任何政策中發現最長時間呼叫政策，然後表示 Edge 需要很長的時間才能處理請求。
以下是 UI 追蹤記錄範例，顯示非常長時間的 JavaScript 政策時間：
在上述範例中，您會發現 JavaScript 政策所需的時間過長約 245 秒

解析度

檢查政策是否需要較長的回應時間，以及是否有任何自訂程式碼可能需要很長的處理時間如果有的話，看看是否能夠修正/最佳化已識別的程式碼。
如果沒有導致處理時間較長的自訂程式碼，請檢查訊息處理器的 CPU 或記憶體用量偏高：
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. 監控 API 呼叫，確認問題是否仍然存在。
5. 與 Apigee Edge 支援團隊聯絡，並提供執行緒傾印、記憶體快照資料及訊息處理器記錄 (/opt/apigee/var/log/edge-message-processor/logs/system.log)可協助對方並找出 CPU/記憶體用量偏高的原因。

使用 API Monitoring 診斷問題

API Monitoring 可讓您快速找出問題領域，診斷錯誤、效能和延遲問題及其來源。例如開發人員應用程式、API Proxy、後端目標或 API 平台

逐步完成範例情境，示範如何使用 API Monitoring 排解 5xx 問題。比方說，您可以設定快訊，在 504 個狀態碼數量超過特定門檻時收到通知。

504 閘道逾時

問題

錯誤訊息

哪些因素會導致閘道逾時？

可能原因

慢速 後端伺服器

情境 1 訊息處理器在後端伺服器回應前逾時

診斷

使用追蹤記錄程序 1

程序 2 使用訊息處理器記錄

檢查：訊息處理器如何控制逾時？

解析度

情境 #2 - 在訊息處理器/後端伺服器回應前，路由器逾時

診斷

解析度

提案：為下列各元件設定逾時值 順序：

勾選：如何控制訊息中的 NodeJS 後端伺服器逾時 處理器

情境 #3：用戶端應用程式在路由器/訊息處理器/後端伺服器之前逾時 回覆

診斷

解析度

提案：為下列各元件設定逾時值 順序：

將逾時值調高 路由器和訊息處理器

路由器

訊息處理器

建議：請按照下列步驟，依下列順序設定不同元件的逾時值：

Edge API 要求的處理速度緩慢

診斷

解析度

使用 API Monitoring 診斷問題

慢速後端伺服器

提案：為下列各元件設定逾時值順序：

勾選：如何控制訊息中的 NodeJS 後端伺服器逾時處理器

情境 #3：用戶端應用程式在路由器/訊息處理器/後端伺服器之前逾時回覆

提案：為下列各元件設定逾時值順序：

將逾時值調高路由器和訊息處理器