Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Dokumen ini mencantumkan praktik terbaik untuk menggunakan Cloud Healthcare API.
Pedoman di halaman ini dirancang untuk meningkatkan efisiensi, akurasi, dan
waktu respons yang optimal dari layanan.
Memahami performa latensi
Performa Cloud Healthcare API diukur dengan latensi
antara:
Saat Anda mengirim permintaan ke Cloud Healthcare API.
Saat Anda menerima respons lengkap atas permintaan tersebut.
Latensi terdiri dari tiga komponen:
Waktu round-trip (RTT)
Latensi pemrosesan server
Throughput server
Jarak geografis antara Anda dan server tempat Anda membuat permintaan dapat memberikan dampak yang signifikan pada RTT dan throughput server. Latensi dan throughput antar-region yang diukur untuk jaringan Google Cloud dapat ditemukan di dasbor live.
Dasbor menampilkan performa yang dapat diharapkan klien dari berbagai
lokasi saat membuat permintaan ke server Cloud Healthcare API.
Mengukur performa latensi
Alat dan dasbor berikut memberikan cara untuk mengukur performa
permintaan ke dan dari server Cloud Healthcare API:
Google Cloud metrik latensi konsol: Anda dapat melihat latensi sisi server permintaan Cloud Healthcare API di Google Cloud konsol.
Untuk informasi selengkapnya, lihat metrikGoogle Cloud .
Metrik kustom Cloud Logging: Anda dapat membuat metrik distribusi menggunakan Logging. Metrik distribusi memungkinkan Anda mengonfigurasi dan memahami latensi menyeluruh di aplikasi. Anda juga dapat memantau dan
melaporkan pengukuran latensi yang ditentukan kustom.
Bagian ini menjelaskan berbagai metode untuk mengurangi latensi permintaan yang dikirim
ke Cloud Healthcare API.
Mengirim permintaan ke lokasi regional terdekat
Untuk mendapatkan performa throughput server dan RTT terbaik, kirim permintaan dari
klien ke lokasi regional Cloud Healthcare API terdekat. Lihat Region untuk mengetahui daftar region yang tersedia.
Mengirim permintaan pemanasan
Saat klien mengirim permintaan ke server Cloud Healthcare API untuk
pertama kalinya selama sesi, klien akan melakukan handshake TCP dengan
server untuk membuat koneksi bagi permintaan HTTP. Setiap permintaan berikutnya
dapat terus menggunakan koneksi yang dibuat ini, sehingga klien dapat
menghindari overhead TCP yang biasanya terkait dengan permintaan. Hal ini menghasilkan
performa yang lebih baik saat mengirim permintaan.
Mengirim permintaan secara serentak dengan HTTP/1.1 atau HTTP/2
Untuk mendapatkan performa terbaik untuk serangkaian permintaan, kirim permintaan secara serentak. Gunakan panduan berikut saat mengirim permintaan serentak:
Saat mengirim permintaan serentak, coba temukan jumlah ideal untuk jumlah
permintaan serentak. Jumlah idealnya bergantung pada beberapa faktor, termasuk
kemampuan hardware dan jaringan Anda serta jumlah permintaan yang dikirim.
Lakukan pengujian untuk menemukan jumlah yang ideal.
Kirim permintaan dari klien menggunakan HTTP/2 jika memungkinkan. HTTP/2 memberikan performa
yang lebih baik daripada HTTP/1.1 karena HTTP/2 hanya memerlukan satu koneksi TCP
saat mengirim beberapa permintaan secara berurutan atau serentak. Dengan demikian,
Anda dapat menghindari overhead handshake TCP.
Jika tidak dapat menggunakan HTTP/2, gunakan HTTP/1.1 dengan koneksi persisten.
Anda dapat menghindari overhead handshake TCP jika permintaan pemanasan
telah dikirim. Menggunakan koneksi persisten mungkin mengharuskan Anda
mengelola koneksi yang dioptimalkan dengan kumpulan koneksi untuk library HTTP.
Misalnya, untuk menetapkan kumpulan koneksi dengan 20 permintaan serentak menggunakan library klien HTTP Google untuk Java, kode Anda akan menyertakan hal berikut:
PoolingHttpClientConnectionManagercm=newPoolingHttpClientConnectionManager();// Support 20 concurrent requests.cm.setDefaultMaxPerRoute(20);cm.setMaxTotal(100);HTTP_CLIENT=HttpClients.custom().setConnectionManager(cm).build();
Untuk menetapkan kumpulan koneksi dengan 20 permintaan serentak menggunakan Node.js, kode Anda akan menyertakan hal berikut:
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-05 UTC."],[[["\u003cp\u003eThis document outlines best practices for enhancing efficiency, accuracy, and response times when using the Cloud Healthcare API.\u003c/p\u003e\n"],["\u003cp\u003eLatency in the Cloud Healthcare API is determined by the time between sending a request and receiving a full response, and is impacted by factors like round-trip time (RTT) and server throughput.\u003c/p\u003e\n"],["\u003cp\u003eTools like Google Cloud console latency metrics, Cloud Logging custom metrics, and the Chrome network panel can be used to measure the performance of requests to and from Cloud Healthcare API servers.\u003c/p\u003e\n"],["\u003cp\u003eTo reduce request latency, send requests to the nearest Cloud Healthcare API regional location, send warmup requests to establish connections, and send concurrent requests using HTTP/2 or HTTP/1.1 with persistent connections.\u003c/p\u003e\n"],["\u003cp\u003eUsing a persistent connection might require you to manage an optimized connection with a connection pool for your HTTP library, and the number of concurrent requests should be tested for your specific usage.\u003c/p\u003e\n"]]],[],null,["# Network latency best practices\n\nThis document lists best practices for using the Cloud Healthcare API.\nThe guidelines in this page are designed for greater efficiency, accuracy, and\noptimal response times from the service.\n\nUnderstanding latency performance\n---------------------------------\n\nThe performance of the Cloud Healthcare API is measured by the latency\nbetween:\n\n1. When you send a request to the Cloud Healthcare API.\n2. When you receive a full response to the request.\n\nLatency comprises three components:\n\n- Round-trip time (RTT)\n- Server processing latency\n- Server throughput\n\nThe geographical distance between you and the server you are making requests\nto can have a significant impact on RTT and server throughput. The measured\ninter-region latency and throughput for Google Cloud networks can be found in a\n[live dashboard](https://lookerstudio.google.com/c/u/0/reporting/fc733b10-9744-4a72-a502-92290f608571/page/70YCB).\nThe dashboard shows the performance a client can expect from different\nlocations when making requests to Cloud Healthcare API servers.\n\nMeasuring latency performance\n-----------------------------\n\nThe following tools and dashboards provide ways to measure the performance\nof requests to and from Cloud Healthcare API servers:\n\n- **Google Cloud console latency metrics** : You can view the server-side latency\n of Cloud Healthcare API requests in the [Google Cloud console](https://console.cloud.google.com/apis/api/healthcare.googleapis.com/metrics).\n For more information, see [Google Cloud metrics](/monitoring/api/metrics_gcp).\n\n- **Cloud Logging custom metrics** : You can [create distribution metrics](/logging/docs/logs-based-metrics/distribution-metrics)\n using Logging. Distribution metrics let you configure and\n understand end-to-end latency in your applications. You can also monitor and\n report on any custom-defined latency measurements.\n\n- **Chrome network panel** : You can [inspect network activity in Chrome DevTools](https://developers.google.com/web/tools/chrome-devtools/network)\n to view the performance details of an HTTP request sent from a browser.\n\nReducing request latency\n------------------------\n\nThis section describes various methods of reducing the latency of requests sent\nto the Cloud Healthcare API.\n\n### Sending requests to the closest regional location\n\nTo get the best RTT and server throughput performance, send requests from the\nclient to the closest Cloud Healthcare API regional location. See\n[Regions](/healthcare-api/docs/concepts/regions) for a list of available regions.\n\n### Sending warmup requests\n\nWhen a client sends requests to a Cloud Healthcare API server for the\nfirst time during a session, the client performs TCP handshakes with the\nserver to establish connections for HTTP requests. Any subsequent requests\ncan continue to use these established connections, allowing the client to\navoid the TCP overhead typically associated with a request. This results\nin better performance when sending requests.\n\n### Sending requests concurrently with HTTP/1.1 or HTTP/2\n\nTo obtain the best performance for a series of requests, send the requests\nconcurrently. Use the following guidelines when sending concurrent requests:\n\n- When sending concurrent requests, try to find an ideal number for the number of concurrent requests. The ideal number depends on several factors including your hardware and network capabilities and how many requests are being sent. Conduct tests to find the ideal number.\n- Send requests from the client using HTTP/2 whenever possible. HTTP/2 provides better performance than HTTP/1.1 because HTTP/2 requires only one TCP connection when sending multiple requests sequentially or concurrently. As a result, you can avoid TCP handshake overhead.\n- If it's not possible to use HTTP/2, use HTTP/1.1 with a persistent connection.\n You can avoid TCP handshake overhead if [warmup requests](#sending_warmup_requests)\n have already been sent. Using a persistent connection might require you to\n manage an optimized connection with a connection pool for your HTTP library.\n\n For example, to set a connection pool with 20 concurrent requests using the [Google HTTP client library for Java](https://github.com/googleapis/google-http-java-client), your code would include the following: \n\n PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();\n // Support 20 concurrent requests.\n cm.setDefaultMaxPerRoute(20);\n cm.setMaxTotal(100);\n HTTP_CLIENT = HttpClients.custom().setConnectionManager(cm).build();\n\n To set a connection pool with 20 concurrent requests using Node.js, your code\n would include the following: \n\n require('http').globalAgent.maxSockets = 20"]]
