Halaman ini diterjemahkan oleh Cloud Translation API.

Waktu Tunggu Gateway 504

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

ini.

Gejala

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

Kode status HTTP - 504 Gateway Timeout error 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 Klien -> {i>Router<i} -> Pemroses Pesan -> Server Backend seperti yang ditunjukkan pada gambar di bawah:

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

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

Kemunculan waktu tunggu	Detail
Waktu tunggu terjadi pada Pemroses Pesan	Server backend tidak merespons Pemroses Pesan dalam waktu tunggu yang ditentukan pada Pemroses Pesan. Waktu Pemroses Pesan habis dan mengirimkan status respons sebagai `504 Gateway Timeout` ke Router.
Waktu tunggu terjadi di Router	Pemroses Pesan tidak merespons router dalam waktu tunggu yang ditentukan titik di {i>Router<i}. Router kehabisan waktu dan mengirimkan status respons sebagai `504 Gateway Timeout` ke aplikasi klien.
Waktu tunggu terjadi di aplikasi klien	Router tidak merespons aplikasi klien dalam waktu tunggu yang ditentukan titik di {i>router<i}. Aplikasi Klien kehabisan waktu 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 lambat oleh Edge	Edge memerlukan waktu lama untuk memproses permintaan API karena beban yang tinggi atau buruk tingkat tinggi.

Lambat server backend

Jika server backend sangat lambat atau membutuhkan waktu lama untuk memproses permintaan API, maka Anda akan mendapatkan error 504 Gateway Timeout. Seperti yang dijelaskan di bagian 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.
Waktu aplikasi klien habis sebelum Router/Pemroses Pesan/server backend merespons.

Bagian berikut menjelaskan cara mendiagnosis dan menyelesaikan masalah berdasarkan yang signifikan.

Skenario #1 Waktu Pemroses Pesan 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 Rekaman Aktivitas

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

Lacak API yang terpengaruh di UI Edge. Baik menunggu hingga kesalahan terjadi atau jika Anda memiliki Panggilan API, lalu lakukan beberapa panggilan API dan rekonstruksi error 504 Gateway Timeout.
Setelah kesalahan terjadi, periksa permintaan khusus yang menampilkan kode respons sebagai 504.
Periksa waktu yang berlalu pada setiap fase dan catat fase yang memiliki waktu paling banyak pengeluaran Google Cloud Anda.
Jika Anda mengamati error dengan waktu berlalu terlama, tepat setelah salah satu berikut ini, maka hal itu menunjukkan bahwa server {i>backend<i} lambat atau membutuhkan waktu lama untuk memproses permintaan:
- Permintaan dikirim ke server target
- Kebijakan ServiceInfo

Berikut ini contoh Trace yang menunjukkan bahwa server backend bahkan tidak merespons setelah 55 detik yang mengakibatkan error 504 Gateway Timeout:

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

Prosedur #2 Menggunakan log Pemroses Pesan

Memeriksa log Pemroses Pesan (/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, maka ini menunjukkan bahwa waktu Pemroses Pesan telah habis.

Contoh log Pemroses Pesan yang menunjukkan 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

Pada log Pemroses Pesan di atas, Anda melihat bahwa server backend dilambangkan dengan IP XX.XX.XX.XX tidak merespons bahkan setelah 55 detik (lastIO=55.000 md). Akibatnya, waktu Pemroses Pesan habis dan mengirim error 504 Gateway Timeout.

Periksa ini: Bagaimana waktu tunggu dikontrol di Pemroses Pesan?

Cara 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 adalah berlaku untuk semua Proxy API yang termasuk dalam organisasi yang dilayani oleh Pemroses Pesan.
- Jika server backend tidak merespons dalam waktu 55 detik, maka pesan Waktu proses habis dan mengirim error 504 Gateway Timeout ke klien.
Nilai waktu tunggu yang ditentukan dalam Pemroses Pesan dapat berupa diganti oleh properti io.timeout.millis yang ditetapkan dalam Proxy API. Nilai waktu tunggu ini berlaku untuk API tertentu Proxy yang menentukan properti yang disebutkan di atas. Misalnya, jika io.timeout.millis disetel ke 10 detik dalam Proxy API, lalu nilai waktu tunggu 10 detik akan digunakan untuk Proxy API khusus ini.
- Jika server backend tidak merespons dalam waktu 10 detik untuk Proxy API, lalu waktu Pemroses Pesan habis dan mengirimkan 504 Gateway Timeout {i>error<i} kepada klien.

Resolusi

Periksa mengapa server backend membutuhkan lebih dari 55 detik dan lihat apakah itu dapat diperbaiki/dioptimalkan untuk merespons lebih cepat.
Jika tidak memungkinkan untuk memperbaiki/mengoptimalkan server backend atau diketahui bahwa backend server membutuhkan waktu lebih lama dari 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 Pesan Pemroses/server backend merespons. Hal ini dapat terjadi dalam salah satu situasi berikut:

Nilai waktu tunggu yang disetel di Router lebih singkat daripada nilai waktu tunggu yang disetel di Message Pemroses. Misalnya, batas waktu tunggu di {i>Router<i} adalah 50 detik, sedangkan Prosesor adalah 55 detik.

Waktu Tunggu di Router Waktu Tunggu pada Pemroses Pesan

50 detik 55 detik

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

Nilai waktu tunggu pada 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 disetel:

Waktu Tunggu di Router	Waktu Tunggu pada 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, Pemroses Pesan tidak akan kehabisan waktu setelah 55 detik meskipun waktu tunggunya habis (55 detik) kurang dari nilai waktu tunggu pada 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 berdurasi 120 detik.

Karena {i>Router<i} memiliki nilai waktu tunggu yang lebih rendah (57 detik) dibandingkan dengan 120 detik yang diatur dalam Proxy API, waktu tunggu router akan habis jika server backend tidak merespons setelah 57 detik.

Diagnosis

Memeriksa 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 di log akses NGINX untuk permintaan API tertentu dan message id dari Pemroses Pesan akan ditetapkan sebagai -. Hal ini karena {i>Router<i} tidak mendapatkan respons apa pun dari Pemroses Pesan dalam periode waktu tunggu yang disetel pada router.

Contoh Entri Log NGINX yang menampilkan 504 karena waktu habis Router
Pada contoh di atas, perhatikan status 504 di NGINX, ID pesan dari bagian Prosesor - dan total waktu yang berlalu adalah 57,001 detik. Penyebabnya adalah waktu router habis setelah 57.001 detik dan kami tidak mendapatkan tanggapan apa pun dari {i>Message Processor<i}.

Dalam hal ini, Anda akan melihat pengecualian Broken Pipe di Pesan Log pemroses (/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>

Pesan ini ditampilkan karena setelah waktu {i>router<i} habis, koneksi akan ditutup dengan Pemroses Pesan. Ketika Pemroses Pesan menyelesaikan pemrosesannya, ia mencoba untuk menulis respons terhadap {i>router<i}. Karena koneksi ke {i>router<i} sudah ditutup, Anda mendapatkan Broken Pipe exception pada Pemroses Pesan.

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

Resolusi

Jika ini adalah server backend khusus, maka

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

Jika tidak mungkin untuk memperbaiki/mengoptimalkan server backend atau itu adalah fakta yang diketahui bahwa server backend memerlukan waktu lama, lalu Tingkatkan nilai waktu tunggu Router dan Pemroses Pesan.

Ide: Setel nilai waktu tunggu pada berbagai komponen di bawah ini berikut:

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

Jika ini adalah server backend NodeJS, maka:
1. Periksa apakah kode NodeJS melakukan panggilan ke server backend lain waktu yang lama untuk memberikan respons. Periksa mengapa server {i>backend<i} membutuhkan waktu lebih lama dan memperbaiki masalah sebagaimana mestinya.
2. Periksa apakah Pemroses Pesan mengalami penggunaan CPU atau Memori yang tinggi:
  1. Jika ada Pemroses Pesan yang mengalami penggunaan CPU yang tinggi, buat tiga rangkaian pesan dumps setiap 30 detik menggunakan perintah berikut:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Jika ada Pemroses Pesan yang mengalami penggunaan memori tinggi, buat sebuah heap dump menggunakan perintah berikut:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. Mulai ulang Pemroses Pesan menggunakan perintah di bawah ini. 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 menyelidiki penyebab tingginya penggunaan CPU/memori.

Periksa Ini: Cara waktu tunggu dikontrol untuk server backend NodeJS di Message Pemroses

Server backend NodeJS berjalan dalam proses JVM dari Message Processor. Tujuan nilai waktu tunggu untuk server backend NodeJS dikontrol melalui properti http.request.timeout.seconds dalam file nodejs.properties. Ini diatur ke 0 secara default, yaitu, waktu tunggu dinonaktifkan secara default untuk semua Proxy API yang merupakan bagian dari organisasi yang dilayani oleh Pemroses Pesan ini. Jadi bahkan jika server backend NodeJS memakan waktu lama, Pemroses Pesan tidak akan kehabisan waktu.
Namun, jika server backend NodeJS memakan waktu lama dan jika waktu yang dibutuhkan oleh API permintaannya adalah > 57 detik, maka Router akan kehabisan waktu dan mengirim 504 Gateway Timeout {i>error<i} kepada 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 disetel pada aplikasi klien lebih rendah dari nilai waktu tunggu yang disetel di {i>router<i} dan Pemroses Pesan:

Misalnya, jika nilai waktu tunggu berikut disetel:

Waktu Tunggu pada Klien	Waktu Tunggu di Router	Waktu Tunggu pada 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. Ini mencakup waktu yang dibutuhkan untuk membuat permintaan API, permintaan yang diproses oleh Edge (Router, Message Processor), permintaan yang dikirim ke server backend (jika ada), backend yang akan memproses permintaan dan mengirimkan respons, Edge akan memproses respons dan akhirnya mengirimkannya kembali ke klien.

Jika {i>router<i} tidak merespons klien dalam 50 detik, maka klien akan waktu tunggu dan menutup koneksi dengan {i>router<i}. Klien akan mendapatkan kode respons 504.

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

Diagnosis

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

Dalam hal ini, Anda akan melihat Broken Pipe Pengecualian dalam Pesan Log pemroses (/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. Jika Pemroses Pesan menyelesaikan pemrosesannya, mencoba menulis respons ke Router. Karena koneksi ke Router sudah ditutup, Anda akan mendapatkan Broken Pipe exception pada Pemroses Pesan.
Pengecualian ini diharapkan dalam situasi yang dijelaskan di atas. Jadi, penyebab sebenarnya dari error 504 Gateway Timeout masih berarti server backend membutuhkan waktu lama untuk merespons dan Anda perlu mengatasi masalah tersebut.

Resolusi

Jika ini adalah server backend kustom Anda, maka:

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

Jika tidak memungkinkan untuk memperbaiki/mengoptimalkan server backend atau jika Anda tahu bahwa server backend akan membutuhkan waktu lama, lalu tingkatkan nilai waktu tunggu router dan Pemroses Pesan yang sesuai.

Ide: Setel nilai waktu tunggu pada berbagai komponen di bawah ini berikut:

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

Jika ini adalah backend NodeJS, maka:
1. Periksa apakah kode NodeJS melakukan panggilan ke server backend memakan waktu lama untuk kembali. Periksa mengapa 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 rangkaian pesan dumps setiap 30 detik menggunakan perintah berikut:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Jika Pemroses Pesan mengalami penggunaan memori tinggi, buat sebuah heap dump menggunakan perintah berikut:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. Mulai ulang Pemroses Pesan menggunakan perintah di bawah ini. Hal ini seharusnya 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.

Tingkatkan nilai waktu tunggu aktif Router dan Pemroses Pesan

Pilih nilai waktu tunggu untuk disetel di Router dan Pemroses Pesan dengan cermat, tergantung pada persyaratan Anda. Jangan menetapkan nilai waktu tunggu yang terlalu besar secara acak. Jika Anda membutuhkan bantuan, hubungi Dukungan Apigee Edge.

Router

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

Membuat file /opt/apigee/customer/application/router.properties di Mesin {i>router<i}, 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, maka setel menjadi berikut ini:

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 {i>Message Processor<i}, 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, maka setel menjadi berikut ini:
```
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 Prosesor.

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

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

Pemrosesan permintaan API yang lambat oleh Edge

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

Diagnosis

Lacak API yang terpengaruh di UI Edge.
Tunggu hingga error terjadi atau jika Anda memiliki panggilan API, lakukan beberapa panggilan API dan mereproduksi error 504 Gateway Timeout.
Catatan, dalam hal ini, Anda mungkin melihat respons yang berhasil di Rekaman Aktivitas.
1. Waktu tunggu 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). Akan tetapi, Pemroses Pesan terus memproses permintaan itu dan mungkin selesai memulai proyek.
2. Selain itu, nilai HTTPTransport.io.timeout.millis yang ditetapkan pada Pemroses Pesan hanya terpicu jika Pemroses Pesan berkomunikasi dengan HTTP/HTTPS server backend. Dengan kata lain, waktu tunggu ini tidak akan dipicu jika ada kebijakan (other daripada kebijakan ServiceInfo) dalam Proxy API memerlukan waktu lama.
Setelah error terjadi, periksa permintaan khusus yang memiliki jangka waktu waktu berlalu.
Periksa waktu yang berlalu pada setiap fase dan catat fase yang memiliki waktu paling lama pengeluaran Google Cloud Anda.
Jika Anda melihat waktu berlalu terlama dalam salah satu kebijakan selain Layanan kebijakan Keterangan, yang menunjukkan bahwa Edge membutuhkan waktu lama untuk memproses permintaan.
Berikut contoh rekaman aktivitas UI yang menunjukkan waktu berlalu yang sangat tinggi pada Kebijakan JavaScript:
Dalam contoh di atas, Anda melihat bahwa kebijakan JavaScript mengambil jumlah yang sangat lama dengan waktu ~ 245 detik.

Resolusi

Periksa apakah kebijakan tersebut memerlukan waktu lama untuk ditanggapi dan apakah ada kode khusus yang mungkin membutuhkan waktu pemrosesan yang lama. Jika ada kode seperti itu, maka lihat apakah Anda bisa memperbaiki/mengoptimalkan kode yang teridentifikasi.
Jika tidak ada kode khusus yang dapat menyebabkan waktu pemrosesan yang tinggi, periksa apakah Pesan Prosesor mengalami penggunaan CPU atau memori yang tinggi:
1. Jika ada Pemroses Pesan yang mengalami penggunaan CPU yang tinggi, buat tiga rangkaian pesan dumps setiap 30 detik menggunakan perintah berikut:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
2. Jika ada Pemroses Pesan yang menggunakan Memori tinggi, buat sebuah heap dump menggunakan perintah berikut:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
3. Mulai ulang Pemroses Pesan menggunakan perintah di bawah ini. Ini akan menurunkan CPU dan Memori.
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
4. Memantau panggilan API dan mengonfirmasi apakah masalahnya masih ada.
5. Hubungi Dukungan Apigee Edge dan berikan thread log dump, heap dump, dan Pemroses Pesan (/opt/apigee/var/log/edge-message-processor/logs/system.log)untuk membantu mereka menyelidiki penyebab tingginya penggunaan CPU/memori.

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 mungkin ingin menyiapkan peringatan yang akan diberi tahu saat jumlah kode status 504 melebihi nilai minimum tertentu.