Halaman ini diterjemahkan oleh Cloud Translation API.

Waktu Tunggu Gateway 504

Anda sedang melihat dokumentasi Apigee Edge.
Buka dokumentasi Apigee X. info

Gejala

Aplikasi klien menerima kode status HTTP 504 dengan pesan Gateway Timeout sebagai respons untuk panggilan API.

Kode status HTTP - Error 504 Gateway Timeout menunjukkan bahwa klien tidak menerima respons tepat waktu dari Edge Gateway atau server backend selama eksekusi API

Pesan error

Aplikasi klien mendapatkan kode respons berikut:

HTTP/1.1 504 Gateway Timeout

Dalam beberapa kasus, pesan error berikut juga mungkin muncul:

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

Apa yang menyebabkan waktu tunggu gateway habis?

Jalur umum untuk permintaan API melalui platform Edge adalah Client -> Router -> Message Processor -> Backend Server seperti yang ditampilkan dalam gambar di bawah ini:

Aplikasi klien, router, dan Prosesor Pesan dalam platform Edge disiapkan dengan nilai waktu tunggu yang sesuai. Platform Edge mengharapkan respons dikirim dalam jangka waktu tertentu untuk setiap permintaan API berdasarkan nilai waktu tunggu. Jika Anda tidak mendapatkan respons dalam jangka waktu yang ditentukan, 504 Gateway Timeout Error akan ditampilkan.

Tabel berikut memberikan detail selengkapnya tentang kapan waktu tunggu dapat terjadi di Edge:

Kejadian waktu tunggu habis	Detail
Waktu tunggu habis di Message Processor	Server backend tidak merespons Pemroses Pesan dalam jangka waktu waktu tunggu yang ditentukan di Pemroses Pesan. Message Processor kehabisan waktu tunggu dan mengirimkan status respons sebagai `504 Gateway Timeout` ke Router.
Waktu tunggu terjadi di Router	Message Processor tidak merespons router dalam periode waktu tunggu yang ditentukan di Router. Router kehabisan waktu tunggu dan mengirim status respons sebagai `504 Gateway Timeout` ke aplikasi klien.
Waktu tunggu habis di aplikasi klien	Router tidak merespons aplikasi klien dalam periode waktu tunggu yang ditentukan di router. Aplikasi Klien kehabisan waktu tunggu dan mengakhiri status respons sebagai `504 Gateway Timeout` kepada pengguna akhir.

Kemungkinan penyebab

Di Edge, penyebab umum error 504 Gateway Timeout adalah:

Penyebab	Detail	Langkah-langkah yang diberikan untuk
Server backend lambat	Server backend yang memproses permintaan API terlalu lambat karena beban yang tinggi atau performa yang buruk.	Pengguna Cloud Publik dan Pribadi
Pemrosesan permintaan API yang lambat oleh Edge	Edge memerlukan waktu lama untuk memproses permintaan API karena beban yang tinggi atau performa yang buruk.

Server backend yang lambat

Jika server backend sangat lambat atau memerlukan waktu lama untuk memproses permintaan API, Anda akan mendapatkan error 504 Gateway Timeout. Seperti yang dijelaskan di bagian di atas, waktu tunggu dapat terjadi dalam salah satu skenario berikut:

Waktu Pemroses Pesan habis sebelum server backend merespons.
Waktu router habis sebelum Pemroses Pesan/server backend merespons.
Aplikasi klien habis waktu tunggunya sebelum Router/Pemroses Pesan/server backend merespons.

Bagian berikut menjelaskan cara mendiagnosis dan menyelesaikan masalah dalam setiap skenario ini.

Skenario #1 Waktu tunggu Message Processor habis sebelum server backend merespons

Diagnosis

Anda dapat menggunakan prosedur berikut untuk mendiagnosis apakah terjadi error 504 Gateway Timeout karena server backend yang lambat.

Prosedur #1 Menggunakan Trace

Jika masalah masih aktif (504 error masih terjadi), ikuti langkah-langkah di bawah:

Lacak API yang terpengaruh di UI Edge. Tunggu hingga error terjadi atau jika Anda memiliki panggilan API, buat beberapa panggilan API dan ulangi error 504 Gateway Timeout.
Setelah error terjadi, periksa permintaan tertentu yang menampilkan kode respons sebagai 504.
Periksa waktu yang berlalu di setiap fase dan catat fase yang menghabiskan sebagian besar waktu.
Jika Anda mengamati error dengan waktu berlalu terpanjang segera setelah salah satu fase berikut, hal ini menunjukkan bahwa server backend lambat atau memerlukan waktu lama untuk memproses permintaan:
- Permintaan dikirim ke server target
- Kebijakan ServiceCallout

Berikut adalah contoh Trace yang menunjukkan bahwa server backend tidak merespons bahkan setelah 55 detik sehingga menyebabkan error 504 Gateway Timeout:

Pada rekaman aktivitas di atas, waktu tunggu Pemroses Pesan habis setelah 55.002 milidetik karena server backend tidak merespons.

Prosedur #2 Menggunakan log Pemroses Pesan

Periksa log Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)

Jika Anda menemukan error Gateway Timeout dan onTimeoutRead untuk permintaan proxy API tertentu pada waktu tertentu, hal ini menunjukkan bahwa Message Processor telah habis waktunya.

Contoh log Message Processor yang menampilkan Error Timeout Gateway

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

Dalam log Message Processor di atas, Anda melihat bahwa server backend yang dilambangkan dengan alamat IP XX.XX.XX.XX tidak merespons bahkan setelah 55 detik (lastIO=55000ms). Akibatnya, waktu Pemroses Pesan habis dan mengirim error 504 Gateway Timeout.

Lihat ini: Bagaimana waktu tunggu dikontrol di Message Processor?

Cara waktu tunggu dikontrol di Message Processor. Pemroses Pesan biasanya ditetapkan dengan nilai waktu tunggu default 55 detik) melalui properti HTTPTransport.io.timeout.millis. Nilai waktu tunggu ini berlaku untuk semua Proxy API yang dimiliki oleh organisasi yang ditayangkan oleh Message Processor ini.
- Jika server backend tidak merespons dalam waktu 55 detik, waktu tunggu Message Processor akan habis dan mengirimkan error 504 Gateway Timeout ke klien.
Nilai waktu tunggu yang ditentukan di Message Processor dapat diganti oleh properti io.timeout.millis yang ditentukan dalam API Proxy. Nilai waktu tunggu ini berlaku untuk Proxy API tertentu tempat properti yang disebutkan di atas ditentukan. Misalnya, jika io.timeout.millis ditetapkan ke 10 detik dalam API Proxy, maka nilai waktu tunggu 10 detik akan digunakan untuk API Proxy spesifik ini.
- Jika server backend tidak merespons dalam waktu 10 detik untuk Proxy API tertentu, Message Processor akan habis waktu tunggunya dan mengirimkan error 504 Gateway Timeout ke klien.

Resolusi

Periksa penyebab server backend memerlukan waktu lebih dari 55 detik dan lihat apakah server tersebut dapat diperbaiki/dioptimalkan untuk merespons lebih cepat.
Jika tidak dapat memperbaiki/mengoptimalkan server backend atau diketahui bahwa server backend memerlukan waktu lebih lama daripada waktu tunggu yang dikonfigurasi, Tingkatkan nilai waktu tunggu di Router dan Message Processor ke nilai yang sesuai.

Skenario #2 - Router habis waktu tunggunya sebelum Message Processor/server backend merespons

Anda mungkin mendapatkan error 504 Gateway Timeout jika router habis waktu tunggunya sebelum Message Processor/server backend merespons. Hal ini dapat terjadi dalam salah satu situasi berikut:

Nilai waktu tunggu yang ditetapkan di Router lebih singkat daripada nilai waktu tunggu yang ditetapkan pada Pemroses Pesan. Misalnya, waktu tunggu di Router adalah 50 detik, sedangkan Pemroses Pesan adalah 55 detik.

Waktu Tunggu di Router	Waktu tunggu habis di Message Processor
50 detik	55 detik

Nilai waktu tunggu pada Pemroses Pesan diganti dengan nilai waktu tunggu yang lebih tinggi menggunakan properti io.timeout.millis yang disetel dalam konfigurasi endpoint target Proxy API:

Misalnya, jika nilai waktu tunggu berikut ditetapkan:

Waktu tunggu habis di Router	Waktu Tunggu pada Pemroses Pesan	Waktu tunggu habis dalam Proxy API
57 detik	55 detik	120 detik

Namun, io.timeout.millis disetel ke 120 detik di Proxy API:

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

Kemudian, Message Processor tidak akan mengalami waktu tunggu habis setelah 55 detik meskipun nilai waktu tunggunya (55 detik) lebih kecil dari nilai waktu tunggu di router (57 detik). Hal ini karena nilai waktu tunggu 55 detik di Message Processor diganti dengan nilai 120 detik yang ditetapkan dalam API Proxy. Jadi, nilai waktu tunggu Pemroses Pesan untuk Proxy API spesifik ini adalah 120 detik.

Karena Router memiliki nilai waktu tunggu yang lebih rendah (57 detik) dibandingkan dengan 120 detik yang ditetapkan dalam Proxy API, router akan mengalami waktu tunggu habis jika server backend tidak merespons kembali setelah 57 detik.

Diagnosis

Periksa log akses NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
Jika router habis waktunya sebelum Message Processor, Anda akan melihat status 504 di log akses NGINX untuk permintaan API tertentu dan message id dari Message Processor akan ditetapkan sebagai -. Hal ini karena Router tidak mendapatkan respons apa pun dari Message Processor dalam periode waktu tunggu yang ditetapkan di router.

Contoh Entri Log NGINX yang menampilkan 504 karena waktu tunggu Router habis
Dalam contoh di atas, perhatikan status 504 pada NGINX, ID pesan dari Pemroses Pesan adalah -, dan total waktu yang berlalu adalah 57,001 detik. Ini karena waktu router habis setelah 57.001 detik dan kami tidak mendapatkan respons apa pun dari Pemroses Pesan.

Dalam hal ini, Anda akan melihat pengecualian Broken Pipe dalam log Message Processor (/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>

Error ini ditampilkan karena setelah waktu tunggu router habis, router akan menutup koneksi dengan Message Processor. Setelah menyelesaikan pemrosesannya, Message Processor akan mencoba menulis respons ke router. Karena koneksi ke router sudah ditutup, Anda akan mendapatkan Broken Pipe exception pada Pemroses Pesan.

Pengecualian ini diharapkan akan terlihat dalam situasi yang dijelaskan di atas. Jadi, penyebab sebenarnya error 504 Gateway Timeout masih karena server backend memerlukan waktu lebih lama untuk merespons dan Anda perlu mengatasi masalah tersebut.

Resolusi

Jika server backend kustom, maka

Periksa mengapa server backend memerlukan waktu lama untuk merespons dan lihat apakah server tersebut dapat diperbaiki/dioptimalkan untuk merespons lebih cepat.

Jika tidak dapat memperbaiki/mengoptimalkan server backend atau sudah diketahui bahwa server backend memerlukan waktu lama, Tingkatkan nilai waktu tunggu di Router dan Message Processor.

Ide: Tetapkan nilai waktu tunggu pada berbagai komponen dalam urutan berikut:

Waktu Tunggu di Klien > Waktu Tunggu di Router > Waktu Tunggu pada Pemroses Pesan > Waktu Tunggu dalam Proxy API

Jika ini adalah server backend NodeJS, maka:
1. Periksa apakah kode NodeJS melakukan panggilan ke server backend lainnya dan apakah memerlukan waktu lama untuk menampilkan respons. Periksa alasan server backend memerlukan waktu lebih lama dan perbaiki masalahnya sebagaimana mestinya.
2. Periksa apakah Pemroses Pesan mengalami penggunaan CPU atau Memori yang tinggi:
  1. Jika Message Processor mengalami penggunaan CPU yang tinggi, buat tiga dump thread setiap 30 detik menggunakan perintah berikut:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Jika Message Processor mengalami penggunaan memori yang tinggi, buat dump heap menggunakan perintah berikut:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. Mulai ulang Message Processor menggunakan perintah di bawah. Tindakan ini akan menurunkan CPU dan memori:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
  4. Pantau panggilan API untuk mengonfirmasi apakah masalah masih ada.
  5. Hubungi Dukungan Apigee Edge dan berikan log thread dump, heap dump, dan Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)untuk membantu menyelidiki penyebab penggunaan CPU/memori yang tinggi.

Periksa Ini: Bagaimana waktu tunggu dikontrol untuk server backend NodeJS di Message Processor

Server backend NodeJS berjalan dalam proses JVM dari Message Processor. Nilai waktu tunggu untuk server backend NodeJS dikontrol melalui properti http.request.timeout.seconds dalam file nodejs.properties. Properti ini disetel ke 0 secara default, yaitu waktu tunggu dinonaktifkan secara default untuk semua Proxy API milik organisasi yang dilayani oleh Pemroses Pesan ini. Jadi, meskipun server backend NodeJS memerlukan waktu lama, Message Processor tidak akan habis waktu tunggunya.
Namun, jika server backend NodeJS memerlukan waktu lama dan jika waktu yang diperlukan oleh permintaan API > 57 detik, Router akan habis waktu tunggunya dan mengirimkan error 504 Gateway Timeout ke klien.

Skenario #3 - Waktu tunggu aplikasi klien habis sebelum Router/Pemroses Pesan/server backend merespons

Anda mungkin mendapatkan error 504 Gateway Timeout jika waktu tunggu aplikasi klien habis sebelum server backend merespons. Situasi ini dapat terjadi jika:

Nilai waktu tunggu yang ditetapkan di aplikasi klien lebih rendah daripada nilai waktu tunggu yang ditetapkan di router dan Message Processor:

Misalnya, jika nilai waktu tunggu berikut ditetapkan:

Waktu Tunggu pada Klien	Waktu tunggu habis di Router	Waktu tunggu habis di Message Processor
50 detik	57 detik	55 detik

Dalam hal ini, total waktu yang tersedia untuk mendapatkan respons permintaan API melalui Edge adalah <= 50 detik. Hal ini mencakup waktu yang diperlukan untuk membuat permintaan API, permintaan yang diproses oleh Edge (Router, Message Processor), permintaan yang dikirim ke server backend (jika ada), backend yang memproses permintaan dan mengirim respons, Edge memproses respons, dan akhirnya mengirimnya kembali ke klien.

Jika router tidak merespons klien dalam waktu 50 detik, klien akan kehabisan waktu tunggu dan menutup koneksi dengan router. Klien akan mendapatkan kode respons 504.

Ini akan menyebabkan NGINX menetapkan kode status 499 yang menunjukkan klien menutup koneksi.

Diagnosis

Jika waktu tunggu aplikasi klien habis sebelum mendapatkan respons dari router, aplikasi akan menutup koneksi dengan router. Dalam situasi ini, Anda akan melihat kode status 499 di log akses NGINX untuk permintaan API tertentu.
Contoh Entri Log NGINX yang menampilkan kode status 499
Pada contoh di atas, perhatikan bahwa status 499 di NGINX dan total waktu yang berlalu adalah 50.001 detik. Hal ini menunjukkan bahwa waktu klien habis setelah 50.001 detik.

Dalam hal ini, Anda akan melihat Pengecualian Broken Pipe di log Pemroses Pesan (/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>

)

Setelah waktu tunggu Router habis, koneksi dengan Pemroses Pesan akan ditutup. Saat Message Processor menyelesaikan pemrosesannya, Message Processor akan mencoba menulis respons ke Router. Karena koneksi ke Router sudah ditutup, Anda akan mendapatkan Broken Pipe exception di Message Processor.
Pengecualian ini diharapkan dalam situasi yang dijelaskan di atas. Jadi, penyebab sebenarnya dari error 504 Gateway Timeout masih karena server backend memerlukan waktu lama untuk merespons dan Anda perlu mengatasi masalah tersebut.

Resolusi

Jika server backend kustom Anda:

Periksa server backend untuk mengetahui mengapa perlu waktu lebih dari 57 detik dan lihat apakah server tersebut dapat diperbaiki/dioptimalkan untuk merespons lebih cepat.

Jika tidak dapat memperbaiki/mengoptimalkan server backend atau jika Anda tahu bahwa server backend akan memerlukan waktu lama, tingkatkan nilai waktu tunggu di router dan Message Processor.

Ide: Tetapkan nilai waktu tunggu pada berbagai komponen dalam urutan berikut:

Waktu Tunggu di Klien > Waktu Tunggu di Router > Waktu Tunggu pada Pemroses Pesan > Waktu Tunggu dalam Proxy API

Jika backend-nya adalah NodeJS, maka:
1. Periksa apakah kode NodeJS melakukan panggilan ke server backend lainnya dan apakah kode tersebut memerlukan waktu lama untuk ditampilkan. Periksa alasan server backend tersebut memerlukan waktu lebih lama.
2. Periksa apakah Pemroses Pesan mengalami penggunaan CPU atau memori yang tinggi:
  1. Jika Pemroses Pesan mengalami penggunaan CPU yang tinggi, buat tiga dump thread setiap 30 detik menggunakan perintah berikut:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Jika Pemroses Pesan mengalami penggunaan memori yang tinggi, buat dump heap menggunakan perintah berikut:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. Mulai ulang Message Processor menggunakan perintah di bawah. Tindakan ini akan menurunkan CPU dan memori:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
  4. Pantau panggilan API untuk mengonfirmasi apakah masalah masih ada.
  5. Hubungi Dukungan Apigee Edge dan berikan thread dump, heap dump, dan log Pemroses Pesan (/opt/apigee/var/log/edge-message-processor/logs/system.log)untuk membantu mereka menyelidiki penyebab tingginya penggunaan CPU/memori.

Meningkatkan nilai waktu tunggu di Router dan Message Processor

Pilih nilai waktu tunggu yang akan ditetapkan di Router dan Message Processor dengan cermat, bergantung pada persyaratan Anda. Jangan menetapkan nilai waktu tunggu yang terlalu besar secara acak. Jika Anda memerlukan bantuan, hubungi Dukungan Apigee Edge.

Router

chown apigee:apigee /opt/apigee/customer/application/router.properties

Buat file /opt/apigee/customer/application/router.properties di komputer Router, jika belum ada.

Tambahkan baris berikut ke file ini:

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

Misalnya, jika Anda ingin menetapkan nilai waktu tunggu 120 detik, tetapkan sebagai berikut:

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

Pastikan file ini dimiliki oleh apigee:

Mulai ulang router:

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

Jika Anda memiliki lebih dari satu router, ulangi langkah-langkah di atas di semua router.

Message Processor

Buat file /opt/apigee/customer/application/message-processor.properties di komputer Message Processor, jika belum ada.
Tambahkan baris berikut ke file ini:
```
conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS
```
Misalnya, jika Anda ingin menetapkan nilai waktu tunggu 120 detik, maka tetapkan sebagai berikut:
```
conf_http_HTTPTransport.io.timeout.millis=120000
```

Pastikan file ini dimiliki oleh apigee:

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

Mulai ulang Message Processor:

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

Jika Anda memiliki lebih dari satu Pemroses Pesan, ulangi langkah-langkah di atas di semua Pemroses Pesan.

Ide: Tetapkan nilai waktu tunggu pada berbagai komponen dalam urutan berikut:

Waktu tunggu habis di Klien > Waktu tunggu habis di Router > Waktu tunggu habis di Message Processor > Waktu tunggu habis dalam API Proxy

Pemrosesan permintaan API yang lambat oleh Edge

Jika Edge sangat lambat dan/atau memerlukan waktu lama untuk memproses permintaan API, Anda akan mendapatkan error 504 Gateway Timeout.

Diagnosis

Lacak API yang terpengaruh di UI Edge.
Tunggu hingga error terjadi atau jika Anda memiliki panggilan API, lalu lakukan beberapa panggilan API dan rekonstruksi error 504 Gateway Timeout.
Perhatikan bahwa dalam hal ini, Anda mungkin melihat respons yang berhasil di Pelacakan.
1. Waktu tunggu Router/klien habis karena Pemroses Pesan tidak merespons kembali dalam periode waktu tunggu yang ditentukan pada Router/klien (mana saja yang memiliki periode waktu tunggu terendah). Namun, Pemroses Pesan akan terus memproses permintaan dan mungkin berhasil diselesaikan.
2. Selain itu, nilai HTTPTransport.io.timeout.millis yang ditetapkan pada Pemroses Pesan hanya dipicu jika Pemroses Pesan berkomunikasi dengan server backend HTTP/HTTPS. Dengan kata lain, waktu tunggu ini tidak akan dipicu saat kebijakan apa pun (selain kebijakan ServiceCallout) dalam API Proxy memerlukan waktu lama.
Setelah error terjadi, periksa permintaan tertentu yang memiliki waktu yang telah berlalu paling lama.
Periksa waktu yang berlalu di setiap fase dan catat fase yang menghabiskan waktu paling banyak.
Jika Anda mengamati waktu berlalu terpanjang di salah satu kebijakan selain kebijakan Info Layanan, hal itu menunjukkan bahwa Edge memerlukan waktu lama untuk memproses permintaan.
Berikut adalah contoh rekaman aktivitas UI yang menunjukkan waktu berlalu yang sangat tinggi pada Kebijakan JavaScript:
Pada contoh di atas, Anda melihat bahwa kebijakan JavaScript memerlukan waktu yang sangat lama, yaitu ~ 245 detik.

Resolusi

Periksa apakah kebijakan yang memerlukan waktu lama untuk merespons dan apakah ada kode kustom yang mungkin memerlukan waktu lama untuk diproses. Jika ada kode tersebut, lihat apakah Anda dapat memperbaiki/mengoptimalkan kode yang diidentifikasi.
Jika tidak ada kode kustom yang dapat menyebabkan waktu pemrosesan yang tinggi, periksa apakah Message Processor mengalami penggunaan CPU atau memori yang tinggi:
1. Jika Message Processor mengalami penggunaan CPU yang tinggi, buat tiga dump thread setiap 30 detik menggunakan perintah berikut:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
2. Jika Message Processor memiliki penggunaan Memori yang tinggi, buat dump heap menggunakan perintah berikut:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
3. Mulai ulang Message Processor menggunakan perintah di bawah. Tindakan ini akan menurunkan CPU dan Memori.
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
4. Pantau panggilan API dan konfirmasi apakah masalah masih ada.
5. Hubungi Dukungan Apigee Edge dan berikan dump thread, dump heap, dan log Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)untuk membantu mereka menyelidiki penyebab penggunaan CPU/memori yang tinggi.

Mendiagnosis masalah menggunakan Pemantauan API

Pemantauan API memungkinkan Anda mengisolasi area masalah dengan cepat untuk mendiagnosis masalah error, performa, dan latensi serta sumbernya, seperti aplikasi developer, proxy API, target backend, atau platform API.

Ikuti contoh skenario yang menunjukkan cara memecahkan masalah 5xx dengan API menggunakan Pemantauan API. Misalnya, Anda dapat menyiapkan pemberitahuan untuk mendapatkan notifikasi saat jumlah kode status 504 melebihi batas tertentu.