클라이언트에서 요청에 대한 응답을 수신한 시점부터 애플리케이션이 응답을 읽을 때까지의 시간입니다. 이 측정항목은 ReadRows 요청과 가장 관련성이 높습니다. 이 측정항목의 시작 및 중지 시간은 읽기 요청을 보내는 방식에 따라 다릅니다. 자세한 내용은 애플리케이션 차단 지연 타이머 예시를 참조하세요.
지원되는 Bigtable 작업
ReadRow
ReadRows
MutateRow
MutateRows
SampleRowKeys
CheckAndMutateRow
BulkReadRows
BulkMutateRows
유형
배포
사용 가능한 측정기준
프로젝트 ID
인스턴스 ID
표
클러스터
영역
앱 프로필 ID
메서드 이름
클라이언트 이름
애플리케이션 차단 지연 시간 타이머 예시
ReadRows 요청은 일반적으로 반복적, 비동기적 또는 향후 호출 등 3가지 방법 중 하나로 전송됩니다. 다음 예시에서는 각 ReadRows 작업 유형의 애플리케이션 차단 지연 시간의 시작 및 중지 시간을 보여줍니다.
반복
longtotaLatency=0;ServerStream<Row>stream=bigtableDataClient.readRows(query);for(Rowrow:stream){timer.start();// Do something with rowtimer.stop();totalLatency+=timer.elapsed();}
비동기
client.readRowsAsync(query,newResponseObserver<Row>(){@OverridepublicvoidonStart(StreamControllerstreamController){}@OverridepublicvoidonResponse(Rowrow){timer.start();// Do something with the rowtimer.stop();totalLatency+=timer.elapsed();}@OverridepublicvoidonError(Throwablethrowable){// Do something with the error}@OverridepublicvoidonComplete(){}});
향후 호출
이 유형의 ReadRows 요청에서 애플리케이션 차단 지연 시간은 약 0(타이머 없음)이어야 합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eClient-side metrics, available for Java Bigtable clients, provide detailed insights into operation performance and are used alongside server-side metrics for comprehensive debugging.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003eoperation_latencies\u003c/code\u003e metric measures the end-to-end latency of Bigtable operations, including retries, while \u003ccode\u003eattempt_latencies\u003c/code\u003e measures the latency of individual RPC attempts.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003eRetry_count\u003c/code\u003e tracks the number of attempts an operation requires, while \u003ccode\u003eapplication_blocking_latencies\u003c/code\u003e gauges the time an application takes to process a response.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003eFirst_response_latencies\u003c/code\u003e measures the time it takes to receive the first response row, and \u003ccode\u003eserver_latencies\u003c/code\u003e measures the latency between when Google's frontend receives a request and when it sends the first response byte.\u003c/p\u003e\n"],["\u003cp\u003e\u003ccode\u003eConnectivity_error_count\u003c/code\u003e tracks the number of requests that fail to reach Google's network, and \u003ccode\u003eclient_blocking_latencies\u003c/code\u003e measures delays caused by client-side request blocking or queuing.\u003c/p\u003e\n"]]],[],null,["# Client-side metrics descriptions\n================================\n\nClient-side metrics are available when you use the Bigtable client\nlibrary for Java or the Bigtable HBase client for Java. This page\nprovides a detailed description of each client-side metric.\n\nTo learn how to set up and configure client-side metrics, see\n[Set up client-side metrics](/bigtable/docs/client-side-metrics-setup). For an overview, see the [Client-side metrics overview](/bigtable/docs/client-side-metrics).\n\nMetrics are published to the region of the Bigtable cluster that\nthey are for. If Bigtable can't resolve the cluster for a metric,\nlike when an operation fails, then the metric is published to the global region\nand the `cluster` tag has the value `unspecified`.\n\nUse client-side metrics in conjunction with server-side metrics for performance debugging. For a comprehensive list of Bigtable server-side and client-side metrics, see [Metrics](/bigtable/docs/metrics).\n\nOperation latencies\n-------------------\n\nAttempt latencies\n-----------------\n\nRetry count\n-----------\n\nApplication blocking latencies\n------------------------------\n\n### Application blocking latencies timer examples\n\n`ReadRows` requests are typically sent in one of three ways: iteratively,\nasynchronously, or as a future call. The following examples demonstrate the\nstart and stop times for the application blocking latencies for each type of\n`ReadRows` operation.\n\n#### Iterative\n\n long totaLatency=0;\n ServerStream\u003cRow\u003e stream = bigtableDataClient.readRows(query);\n\n for (Row row : stream) {\n timer.start();\n // Do something with row\n timer.stop();\n totalLatency += timer.elapsed();\n }\n\n#### Asynchronous\n\n client.readRowsAsync(query, new ResponseObserver\u003cRow\u003e() {\n @Override\n public void onStart(StreamController streamController) {\n\n }\n\n @Override\n public void onResponse(Row row) {\n timer.start();\n // Do something with the row\n timer.stop();\n totalLatency += timer.elapsed();\n }\n\n @Override\n public void onError(Throwable throwable) {\n // Do something with the error\n }\n\n @Override\n public void onComplete() {\n }\n });\n\n#### Future call\n\nThe application blocking latencies should be approximately 0 (no timer) for\nthis type of `ReadRows` request. \n\n List\u003cRow\u003e rows = bigtableDataClient.readRowsCallable().all().call(query);\n\nFirst-response latencies\n------------------------\n\nServer latencies\n----------------\n\nConnectivity error count\n------------------------\n\nClient blocking latencies\n-------------------------\n\nWhat's next\n-----------\n\n- [See all\n Google Cloud metrics](/monitoring/api/metrics_gcp).\n- [Install and configure client-side metrics.](/bigtable/docs/client-side-metrics-setup)"]]
