Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

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.

Error kode status HTTP - 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 dapat muncul:

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

Apa penyebab waktu tunggu gateway?

Jalur umum untuk permintaan API melalui platform Edge adalah Klien -> Router -> Message Processor -> Server Backend 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 habis dapat terjadi di Edge:

Terjadinya waktu tunggu	Detail
Waktu tunggu habis di Message Processor	Server backend tidak merespons Message Processor dalam jangka waktu tunggu yang ditentukan di Message Processor. Message Processor mengalami waktu tunggu habis dan mengirim status respons sebagai `504 Gateway Timeout` ke Router.
Waktu tunggu habis di Router	Message Processor tidak merespons router dalam jangka waktu tunggu yang ditentukan di Router. Router mengalami waktu tunggu dan mengirim status respons sebagai `504 Gateway Timeout` ke aplikasi klien.
Waktu tunggu habis pada aplikasi klien	Router tidak merespons aplikasi klien dalam periode waktu tunggu yang ditentukan di router. Aplikasi Klien mengalami 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 tinggi atau performa buruk.	Pengguna Cloud Publik dan Pribadi
Pemrosesan permintaan API yang lambat oleh Edge	Edge membutuhkan waktu yang 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 di atas, waktu tunggu habis dapat terjadi dalam salah satu skenario berikut:

Proses Pesan kehabisan waktu sebelum server backend merespons.
Router kehabisan waktu sebelum Message Processor/server backend merespons.
Aplikasi klien kehabisan waktu sebelum Router/Message Processor/server backend merespons.

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

Skenario #1 Prosesor Pesan mengalami waktu tunggu habis sebelum server backend merespons

Diagnosis

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

Prosedur #1 Menggunakan Trace

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

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

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

Dalam rekaman aktivitas di atas, Message Processor mengalami waktu tunggu habis setelah 55002 md karena server backend tidak merespons.

Prosedur #2 Menggunakan log Message Processor

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 mengalami waktu tunggu habis.

Contoh log Message Processor yang menampilkan Error Gateway Timeout

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 meskipun setelah 55 detik (lastIO=55000ms). Akibatnya, Message Processor mengalami waktu tunggu habis dan mengirim error 504 Gateway Timeout.

Periksa ini: Bagaimana waktu tunggu dikontrol di Pemroses Pesan?

Cara mengontrol waktu tunggu di Message Processor. Prosesor 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 termasuk dalam organisasi yang dilayani oleh Message Processor ini.
- Jika server backend tidak merespons dalam waktu 55 detik, maka Message Processor akan mengalami waktu tunggu 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 Proxy API. 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 Proxy API, maka nilai waktu tunggu 10 detik akan digunakan untuk Proxy API tertentu ini.
- Jika server backend tidak merespons dalam waktu 10 detik untuk Proxy API tertentu, maka Message Processor akan mengalami waktu tunggu habis dan mengirimkan error 504 Gateway Timeout ke klien.

Resolusi

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

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

Anda mungkin mendapatkan error 504 Gateway Timeout jika waktu tunggu router habis 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 di Message Processor. Misalnya, anggaplah waktu tunggu di Router adalah 50 detik, sedangkan di Message Processor adalah 55 detik.

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

Nilai waktu tunggu di Message Processor diganti dengan nilai waktu tunggu yang lebih tinggi menggunakan set properti io.timeout.millis dalam konfigurasi endpoint target API Proxy:

Misalnya, jika nilai waktu tunggu berikut ditetapkan:

Waktu Tunggu Router Habis	Waktu tunggu Message Processor habis	Waktu tunggu habis dalam Proxy API
57 detik	55 detik	120 detik

Namun, io.timeout.millis ditetapkan 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 tunggu habisnya (55 detik) kurang dari nilai waktu tunggu habis di router (57 detik). Hal ini karena nilai waktu tunggu 55 detik di Message Processor diganti oleh nilai 120 detik yang ditetapkan dalam Proxy API. Jadi, nilai waktu tunggu Message Processor untuk Proxy API tertentu 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 jika server backend tidak merespons setelah 57 detik.

Diagnosis

Periksa log akses NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
Jika router mengalami waktu tunggu 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.

Entri Log NGINX Contoh yang menampilkan 504 karena Router kehabisan waktu
Dalam contoh di atas, perhatikan status 504 di NGINX, ID pesan dari Message Processor adalah - dan total waktu yang berlalu adalah 57,001 detik. Hal ini karena router mengalami waktu tunggu setelah 57.001 detik dan kita tidak mendapatkan respons apa pun dari Message Processor.

Dalam hal ini, Anda akan melihat pengecualian Broken Pipe di 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 router habis, router akan menutup koneksi dengan Message Processor. Saat Pemroses Pesan menyelesaikan pemrosesannya, Pemroses Pesan akan mencoba menulis respons ke router. Karena koneksi ke router sudah ditutup, Anda akan mendapatkan Broken Pipe exception di Message Processor.

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

Resolusi

Jika server backend kustom, maka

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

Jika server backend tidak dapat diperbaiki/dioptimalkan atau sudah diketahui bahwa server backend membutuhkan waktu yang lama, maka Tingkatkan nilai waktu tunggu di Router dan Message Processor.

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 Proxy API

Jika server backend-nya adalah NodeJS, maka:
1. Periksa apakah kode NodeJS melakukan panggilan ke server backend lain dan apakah memerlukan waktu yang lama untuk menampilkan respons. Periksa alasan server backend membutuhkan waktu lebih lama dan perbaiki masalahnya sesuai kebutuhan.
2. Periksa apakah Pemroses Pesan mengalami penggunaan CPU atau Memori yang tinggi:
  1. Jika ada Message Processor yang mengalami penggunaan CPU tinggi, buat tiga thread dump setiap 30 detik menggunakan perintah berikut:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Jika ada Message Processor yang mengalami penggunaan memori 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. Hal 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 Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)untuk membantu menyelidiki penyebab penggunaan CPU/memori yang tinggi.

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

Server backend NodeJS berjalan dalam proses JVM Message Processor. 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, yaitu, waktu tunggu dinonaktifkan secara default untuk semua Proxy API yang termasuk dalam organisasi yang dilayani oleh Message Processor ini. Jadi, meskipun server backend NodeJS memerlukan waktu yang lama, Pemroses Pesan tidak akan mengalami waktu tunggu habis.
Namun, jika server backend NodeJS membutuhkan waktu lama dan jika waktu yang diperlukan oleh permintaan API > 57 detik, Router akan mengalami waktu tunggu habis dan mengirimkan error 504 Gateway Timeout ke klien.

Skenario #3 - Waktu tunggu aplikasi klien habis sebelum Router/Message Processor/server backend merespons

Anda mungkin mendapatkan error 504 Gateway Timeout jika aplikasi klien mengalami waktu tunggu 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 Habis di Klien	Waktu Tunggu Router Habis	Waktu tunggu Message Processor habis
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 diperlukan untuk membuat permintaan API, permintaan yang diproses oleh Edge (Router, Message Processor), permintaan yang dikirim ke server backend (jika berlaku), backend yang memproses permintaan dan mengirimkan respons, Edge yang memproses respons, dan akhirnya mengirimkannya kembali ke klien.

Jika router tidak merespons klien dalam waktu 50 detik, klien akan mengalami waktu tunggu habis 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 aplikasi klien mengalami waktu tunggu habis sebelum mendapatkan respons dari router, aplikasi tersebut 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
Dalam contoh di atas, perhatikan bahwa status 499 di 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 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-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 Router mengalami waktu tunggu, Router akan menutup koneksi dengan Message Processor. 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 keadaan yang dijelaskan di atas. Jadi, penyebab sebenarnya error 504 Gateway Timeout adalah server backend memerlukan waktu yang lama untuk merespons dan Anda perlu mengatasi masalah tersebut.

Resolusi

Jika server backend kustom Anda adalah:

Periksa server backend untuk menentukan mengapa server memerlukan waktu lebih dari 57 detik dan lihat apakah server dapat diperbaiki/dioptimalkan agar merespons lebih cepat.

Jika server backend tidak dapat diperbaiki/dioptimalkan atau jika Anda tahu bahwa server backend akan membutuhkan waktu yang lama, tingkatkan nilai waktu tunggu di router dan Message Processor.

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 Proxy API

Jika backend-nya adalah NodeJS, maka:
1. Periksa apakah kode NodeJS melakukan panggilan ke server backend lain dan apakah memerlukan waktu yang lama untuk ditampilkan. Periksa alasan server backend tersebut membutuhkan waktu lebih lama.
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 heap dump 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. Hal 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 Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)untuk membantu mereka menyelidiki penyebab penggunaan CPU/memori yang tinggi.

Tingkatkan 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 tetapkan nilai waktu tunggu yang sangat besar secara arbitrer. 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 menyetel nilai waktu tunggu 120 detik, tetapkan seperti 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 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 menyetel nilai waktu tunggu 120 detik, tetapkan seperti 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 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 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

Lacak API yang terpengaruh di UI Edge.
Tunggu hingga error terjadi atau jika Anda memiliki panggilan API, lakukan beberapa panggilan API dan reproduksi error 504 Gateway Timeout.
Perhatikan bahwa dalam kasus ini, Anda mungkin melihat respons yang berhasil di Trace.
1. Router/klien mengalami waktu tunggu karena Pemroses Pesan tidak merespons kembali dalam periode waktu tunggu yang ditentukan di Router/klien (mana pun yang memiliki periode waktu tunggu terendah). Namun, Pemroses Pesan terus memproses permintaan dan mungkin berhasil diselesaikan.
2. Selain itu, nilai HTTPTransport.io.timeout.millis yang ditetapkan di Message Processor hanya dipicu jika Message Processor berkomunikasi dengan server backend HTTP/HTTPS. Dengan kata lain, waktu tunggu ini tidak akan dipicu saat kebijakan apa pun (selain kebijakan ServiceCallout) dalam Proxy API membutuhkan waktu yang lama.
Setelah error terjadi, periksa permintaan tertentu yang memiliki waktu berlalu terlama.
Periksa waktu yang telah berlalu di setiap fase dan catat fase yang paling banyak menghabiskan waktu.
Jika Anda mengamati waktu berlalu terlama dalam kebijakan selain kebijakan Panggilan Layanan, hal ini menunjukkan bahwa Edge memerlukan waktu yang lama untuk memproses permintaan.
Berikut adalah contoh rekaman aktivitas UI yang menunjukkan waktu berlalu yang sangat tinggi pada Kebijakan JavaScript:
Dalam contoh di atas, Anda akan melihat bahwa kebijakan JavaScript membutuhkan waktu yang sangat lama sekitar 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 seperti itu, lihat apakah Anda dapat memperbaiki/mengoptimalkan kode yang teridentifikasi.
Jika tidak ada kode kustom yang dapat menyebabkan waktu pemrosesan yang tinggi, periksa apakah Pemroses Pesan mengalami penggunaan CPU atau memori yang tinggi:
1. Jika ada Message Processor yang mengalami penggunaan CPU tinggi, buat tiga thread dump setiap 30 detik menggunakan perintah berikut:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
2. Jika ada Message Processor yang memiliki penggunaan Memori tinggi, buat heap dump 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 thread dump, heap dump, dan log Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)untuk membantu mereka menyelidiki penyebab penggunaan CPU/penggunaan memori yang tinggi.

Mendiagnosis masalah menggunakan Pemantauan API

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

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