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 |
|
Waktu tunggu habis di Router |
|
Waktu tunggu habis di aplikasi klien |
|
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
danonTimeoutRead
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.
- Jika server backend tidak merespons dalam waktu 55 detik, Waktu Proses
Pesan akan habis dan mengirim error
- 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, jikaio.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.
- Jika server backend tidak merespons dalam waktu 10 detik untuk Proxy API tertentu, Waktu Pemroses Pesan akan habis dan mengirim error
- Bagaimana waktu tunggu dikontrol di Pemroses Pesan. Pemroses Pesan biasanya ditetapkan dengan nilai waktu tunggu default 55 detik) melalui properti
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 - 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 danmessage 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:
- 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.
- Periksa apakah Prosesor Pesan mengalami penggunaan CPU atau Memori yang tinggi:
- 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
- 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
- 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
- Pantau panggilan API untuk mengonfirmasi apakah masalah masih ada.
- 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.
- Jika Prosesor Message mengalami penggunaan CPU yang tinggi, hasilkan tiga thread dump setiap 30 detik menggunakan perintah berikut:
Periksa Ini: Bagaimana waktu tunggu dikontrol untuk server backend NodeJS di Pemroses Pesan
|
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:
- 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.
- Periksa apakah Prosesor Pesan mengalami penggunaan CPU atau memori yang tinggi:
- 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
- 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
- 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
- Pantau panggilan API untuk mengonfirmasi apakah masalah masih ada.
- 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.
- Jika Prosesor Pesan mengalami penggunaan CPU yang tinggi, hasilkan tiga thread dump setiap 30 detik menggunakan perintah berikut:
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.
- 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.
- 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:
- 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
- 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
- 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
- Pantau panggilan API dan konfirmasi apakah masalah masih tetap ada.
- 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.
- Jika Prosesor Message mengalami penggunaan CPU yang tinggi, hasilkan tiga thread dump setiap 30 detik menggunakan perintah berikut:
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.