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 yang tepat waktu dari Gateway Edge 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 mungkin juga 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 ditunjukkan pada gambar di bawah:

Aplikasi klien, router, dan Pemroses 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:

Waktu tunggu habis	Detail
Waktu tunggu habis di Pemroses Pesan	Server backend tidak merespons Pemroses Pesan dalam periode waktu tunggu yang ditentukan pada Pemroses Pesan. Waktu Pemroses Pesan habis dan mengirimkan status respons sebagai `504 Gateway Timeout` ke Router.
Waktu tunggu habis di Router	Pemroses Pesan tidak merespons router dalam periode waktu tunggu yang ditentukan di Router. Waktu router habis dan mengirimkan 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. Waktu aplikasi Klien habis dan mengakhiri status respons sebagai `504 Gateway Timeout` untuk 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 bebannya 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 lambat

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

Waktu Prosesor Pesan habis sebelum server backend merespons.
Waktu router habis sebelum Pemroses Pesan/server backend merespons.
Waktu aplikasi klien habis sebelum Router/Pemroses Pesan/server backend merespons.

Bagian berikut menjelaskan cara mendiagnosis dan menyelesaikan masalah pada setiap skenario.

Skenario #1 Waktu Pemroses Pesan habis sebelum server backend merespons

Diagnosis

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

Prosedur #1 Menggunakan Jejak

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

Melacak API yang terpengaruh di UI Edge. Tunggu hingga error terjadi atau jika Anda memiliki panggilan API, kemudian buat beberapa panggilan API dan rekonstruksi error 504 Gateway Timeout.
Setelah error terjadi, periksa permintaan khusus yang menampilkan kode respons sebagai 504.
Periksa waktu berlalu di setiap fase dan catat fase yang paling banyak menghabiskan waktu.
Jika Anda mengamati error dengan waktu berlalu yang paling lama tepat setelah salah satu fase berikut, berarti server backend lambat atau memerlukan waktu lama untuk memproses permintaan:
- Permintaan dikirim ke server target
- Kebijakan ServiceCallout

Berikut ini contoh Rekaman Aktivitas yang menunjukkan bahwa server backend tidak merespons bahkan setelah 55 detik sehingga menghasilkan error 504 Gateway Timeout:

Pada pelacakan di atas, Waktu Proses Pesan akan 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 Pemroses Pesan telah kehabisan waktu.

Contoh log Prosesor Pesan yang menampilkan Error Waktu Tunggu 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 ditandai dengan alamat IP XX.XX.XX.XX tidak merespons bahkan setelah 55 detik (lastIO=55000 md). Akibatnya, waktu Pemroses Pesan habis dan 504 Gateway Timeout error dikirim.

Periksa ini: Bagaimana waktu tunggu dikontrol di Message Processor?

Bagaimana waktu tunggu dikontrol di Pemroses Pesan. 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 milik organisasi yang disalurkan oleh Pemroses Pesan ini.
- Jika server backend tidak merespons dalam waktu 55 detik, Waktu Proses Pesan akan habis dan mengirim error 504 Gateway Timeout ke klien.
Nilai waktu tunggu yang ditentukan dalam Pemroses Pesan dapat diganti oleh properti io.timeout.millis yang ditentukan dalam Proxy API. Nilai waktu tunggu ini berlaku untuk Proxy API tertentu yang menentukan properti yang disebutkan di atas. Misalnya, jika io.timeout.millis ditetapkan ke 10 detik dalam Proxy API, nilai waktu tunggu 10 detik akan digunakan untuk Proxy API khusus ini.
- Jika server backend tidak merespons dalam waktu 10 detik untuk Proxy API tertentu, Waktu Pemroses Pesan akan habis dan mengirim error 504 Gateway Timeout ke klien.

Resolusi

Periksa mengapa server backend memerlukan waktu lebih dari 55 detik dan lihat apakah server backend 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, maka Tingkatkan nilai waktu tunggu di Router dan Pemroses Pesan ke nilai yang sesuai.

Skenario #2 - Waktu router habis sebelum Pemroses Pesan/server backend merespons

Anda mungkin mendapatkan error 504 Gateway Timeout jika waktu router habis sebelum Pemroses Pesan/server backend merespons. Hal ini dapat terjadi dalam salah satu keadaan berikut:

Nilai waktu tunggu yang disetel pada Router lebih pendek daripada nilai waktu tunggu yang disetel pada Pemroses Pesan. Misalnya, waktu tunggu pada Router adalah 50 detik, sedangkan Prosesor Pesan adalah 55 detik.

Waktu tunggu di Router Waktu Tunggu Pemroses Pesan

50 detik 55 detik

Waktu tunggu di Router	Waktu Tunggu Pemroses Pesan
50 detik	55 detik

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

Misalnya, jika nilai waktu tunggu berikut telah disetel:

Waktu tunggu di Router	Waktu Tunggu Pemroses Pesan	Waktu tunggu 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, Prosesor Pesan tidak akan habis waktu tunggunya 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 pada Pemroses Pesan diganti dengan nilai 120 detik yang ditetapkan dalam Proxy API. Jadi, nilai waktu tunggu Pemroses Pesan untuk Proxy API khusus ini adalah 120 detik.

Karena Router memiliki nilai waktu tunggu yang lebih rendah (57 detik) dibandingkan 120 detik yang ditetapkan dalam Proxy API, router akan habis waktu tunggunya 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 waktu tunggu router habis sebelum Pemroses Pesan, Anda akan melihat status 504 pada log akses NGINX untuk permintaan API tertentu dan message id dari Pemroses Pesan akan ditetapkan sebagai -. Hal ini karena Router tidak mendapatkan respons apa pun dari Pemroses Pesan dalam periode waktu tunggu yang ditetapkan pada router.

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

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-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, koneksi dengan Pemroses Pesan akan ditutup. Setelah menyelesaikan pemrosesan, Pemroses Pesan akan mencoba menulis respons ke router. Karena koneksi ke router sudah tertutup, Anda akan mendapatkan Broken Pipe exception di Pemroses Pesan.

Pengecualian ini diperkirakan akan terjadi 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 itu adalah server backend kustom,

Periksa alasan server backend membutuhkan waktu lama untuk merespons dan lihat apakah server backend dapat diperbaiki/dioptimalkan untuk merespons lebih cepat.

Jika server backend tidak dapat diperbaiki/dioptimalkan atau diketahui bahwa server backend membutuhkan waktu lama, Tingkatkan nilai waktu tunggu di Router dan Pemroses Pesan.

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

Waktu Tunggu di Klien > Waktu Tunggu di Router > Waktu Tunggu di Prosesor Pesan > Waktu Tunggu dalam Proxy API

Jika itu adalah server backend NodeJS, maka:
1. Periksa apakah kode NodeJS melakukan panggilan ke server backend lain, dan apakah perlu waktu lama untuk menampilkan respons. Periksa mengapa server backend memerlukan waktu lebih lama dan perbaiki masalah ini jika perlu.
2. Periksa apakah Prosesor Pesan mengalami penggunaan CPU atau Memori yang tinggi:
  1. Jika Prosesor Message mengalami penggunaan CPU yang tinggi, hasilkan tiga thread dump setiap 30 detik menggunakan perintah berikut:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Jika Prosesor Pesan mengalami penggunaan memori yang tinggi, hasilkan heap dump menggunakan perintah berikut:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. Mulai ulang Prosesor Pesan 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 informasi dump thread dump, heap dump, serta log Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)untuk membantu menyelidiki penyebab tingginya penggunaan CPU/memori.

Periksa Ini: Bagaimana waktu tunggu dikontrol untuk server backend NodeJS di Pemroses Pesan

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

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

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

Nilai waktu tunggu yang ditetapkan pada aplikasi klien lebih rendah daripada nilai waktu tunggu yang ditetapkan pada router dan Pemroses Pesan:

Misalnya, jika nilai waktu tunggu berikut telah disetel:

Waktu tunggu pada Klien	Waktu tunggu di Router	Waktu Tunggu Pemroses Pesan
50 detik	57 detik	55 detik

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

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

Hal ini akan menyebabkan NGINX menetapkan kode status 499 yang menunjukkan bahwa klien menutup koneksi.

Diagnosis

Jika waktu tunggu aplikasi klien habis sebelum mendapatkan respons dari router, aplikasi klien akan menutup koneksi dengan router. Dalam situasi ini, Anda akan melihat kode status 499 dalam log akses NGINX untuk permintaan API tertentu.
Contoh Entri Log NGINX yang menampilkan kode status 499
Pada contoh di atas, perhatikan bahwa status 499 pada NGINX dan total waktu yang berlalu adalah 50,001 detik. Hal ini menunjukkan bahwa waktu tunggu 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. Setelah menyelesaikan pemrosesan, Pemroses Pesan akan mencoba menulis respons ke Router. Karena koneksi ke Router sudah tertutup, Anda akan mendapatkan Broken Pipe exception di Pemroses Pesan.
Pengecualian ini wajar dalam situasi yang dijelaskan di atas. Jadi, penyebab sebenarnya dari error 504 Gateway Timeout adalah bahwa server backend membutuhkan waktu lama untuk merespons dan Anda perlu mengatasi masalah tersebut.

Resolusi

Jika server tersebut adalah server backend kustom Anda, maka:

Periksa server backend untuk mengetahui alasan diperlukannya 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 pada router dan Pemroses Pesan.

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

Waktu Tunggu di Klien > Waktu Tunggu di Router > Waktu Tunggu di Prosesor Pesan > Waktu Tunggu dalam Proxy API

Jika itu adalah backend NodeJS, maka:
1. Periksa apakah kode NodeJS melakukan panggilan ke server backend lain, dan apakah itu perlu waktu lama untuk kembali. Periksa mengapa server backend tersebut membutuhkan waktu lebih lama.
2. Periksa apakah Prosesor Pesan mengalami penggunaan CPU atau memori yang tinggi:
  1. Jika Prosesor Pesan mengalami penggunaan CPU yang tinggi, hasilkan tiga thread dump setiap 30 detik menggunakan perintah berikut:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Jika Prosesor Pesan mengalami penggunaan memori yang tinggi, hasilkan heap dump menggunakan perintah berikut:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. Mulai ulang Prosesor Pesan 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 informasi mengenai thread dump, heap dump, serta log Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)untuk membantu menyelidiki penyebab tingginya penggunaan CPU/memori.

Meningkatkan nilai waktu tunggu di Router dan Pemroses Pesan

Pilih nilai waktu tunggu untuk ditetapkan dengan cermat pada Router dan Pemroses Pesan, bergantung pada persyaratan Anda. Jangan menetapkan nilai waktu tunggu yang besar secara sembarang. 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 mesin 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, maka 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 pada semua router.

Message Processor

Buat file /opt/apigee/customer/application/message-processor.properties di mesin 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 Pemroses Pesan:

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

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

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

Waktu Tunggu di Klien > Waktu Tunggu di Router > Waktu Tunggu di Prosesor Pesan > Waktu tunggu dalam Proxy API

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

Melacak API yang terpengaruh di UI Edge.
Tunggu hingga error terjadi atau jika Anda memiliki panggilan API, lalu buat beberapa panggilan API dan rekonstruksi error 504 Gateway Timeout.
Perhatikan, dalam hal ini, Anda mungkin melihat respons yang berhasil di Trace.
1. Waktu Router/klien habis karena Pemroses Pesan tidak merespons kembali dalam periode waktu tunggu yang ditentukan di Router/klien (mana saja yang memiliki periode waktu tunggu terendah). Namun, Pemroses Pesan akan terus memproses permintaan dan mungkin akan berhasil diselesaikan.
2. Selain itu, nilai HTTPTransport.io.timeout.millis yang ditetapkan pada Pemroses Pesan hanya terpicu jika Pemroses Pesan berkomunikasi dengan server backend HTTP/HTTPS. Dengan kata lain, waktu tunggu ini tidak akan dipicu jika kebijakan apa pun (selain kebijakan ServiceCallout) dalam Proxy API memerlukan waktu yang lama.
Setelah error terjadi, periksa permintaan tertentu yang memiliki waktu terlama.
Periksa waktu berlalu di setiap fase dan catat fase yang paling banyak menghabiskan waktu.
Jika Anda mengamati waktu berlalu yang terlama dalam kebijakan apa pun selain kebijakan Pemanggilan Layanan, hal tersebut 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 membutuhkan waktu lama untuk merespons dan apakah ada kode kustom yang mungkin memerlukan waktu pemrosesan yang lama. Jika ada kode semacam itu, lihat apakah Anda dapat memperbaiki/mengoptimalkan kode yang teridentifikasi.
Jika tidak ada kode kustom yang dapat menyebabkan waktu pemrosesan yang tinggi, periksa apakah Prosesor Pesan mengalami penggunaan CPU atau memori yang tinggi:
1. Jika Prosesor Message mengalami penggunaan CPU yang tinggi, hasilkan tiga thread dump setiap 30 detik menggunakan perintah berikut:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
2. Jika Message Processor memiliki penggunaan Memori yang tinggi, hasilkan heap dump menggunakan perintah berikut:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
3. Mulai ulang Prosesor Pesan 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 tetap ada.
5. Hubungi Dukungan Apigee Edge dan berikan thread dump, heap dump, serta log Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)untuk membantu menyelidiki penyebab tingginya penggunaan CPU/memori.

Mendiagnosis masalah menggunakan API Monitoring

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

Ikuti contoh skenario yang menunjukkan cara memecahkan masalah 5xx pada API Anda menggunakan API Monitoring. Misalnya, Anda mungkin ingin menyiapkan pemberitahuan yang akan dikirimkan saat jumlah kode status 504 melebihi nilai minimum tertentu.