[[["容易理解","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-03 (世界標準時間)。"],[[["\u003cp\u003eThis document explains how to interpret performance results in AlloyDB Omni on a VM, focusing on throughput and latency scaling graphs and histograms.\u003c/p\u003e\n"],["\u003cp\u003eThroughput generally increases with load until resource exhaustion or contention causes it to plateau or decrease, which indicates areas for optimization.\u003c/p\u003e\n"],["\u003cp\u003eLatency, which is inversely proportional to throughput, typically remains constant until resource contention increases it, and this increase correlates with a decrease in throughput.\u003c/p\u003e\n"],["\u003cp\u003eLatency histograms group latencies into buckets, helping identify performance variations and potential bottlenecks, such as multiple operational modes within an application.\u003c/p\u003e\n"],["\u003cp\u003eUnderstanding the causes behind both longer latencies and increased frequencies of these longer latencies can help identify factors that help explain application performance variations.\u003c/p\u003e\n"]]],[],null,["# Interpret performance results in AlloyDB Omni on a VM\n\nSelect a documentation version: Current (16.8.0)keyboard_arrow_down\n\n- [Current (16.8.0)](/alloydb/omni/current/docs/interpret-results)\n- [16.8.0](/alloydb/omni/16.8.0/docs/interpret-results)\n- [16.3.0](/alloydb/omni/16.3.0/docs/interpret-results)\n- [15.12.0](/alloydb/omni/15.12.0/docs/interpret-results)\n- [15.7.1](/alloydb/omni/15.7.1/docs/interpret-results)\n- [15.7.0](/alloydb/omni/15.7.0/docs/interpret-results)\n\n\u003cbr /\u003e\n\nThis document describes how to interpret the performance results in AlloyDB Omni on a VM. This document assumes that you're familiar with PostgreSQL.\n\n\u003cbr /\u003e\n\nWhen you graph throughput over time as another variable is modified, typically you see throughput increase until the throughput reaches a point of resource exhaustion.\n\nThe following figure shows a typical throughput scaling\ngraph. As the number of clients increases, the workload and throughput\nincreases until all the resources are exhausted.\n\\*\\*Fig. 1:\\*\\* A figure that shows a typical throughput scaling graph. As the number of clients increases, the workload and throughput increases until all the resources are exhausted.\n\nIdeally, as you double the load on the system, throughput should also double. In practice there will be contention on resources that leads to smaller throughput increases. At some point resource exhaustion or contention will cause throughput to flatten out or even decrease. If you are optimizing for throughput, this is a key point to identify as it drives your efforts into where to tune the application or database system to improve throughput.\n\nTypical reasons for throughput to level off or drop include the following:\n\n- CPU resource exhaustion on the database server\n- CPU resource exhaustion on the client so the database server is not being sent more work\n- Database lock contention\n- I/O wait time when data exceeds the size of the Postgres buffer pool\n- I/O wait time due to storage engine utilization\n- Network bandwidth bottlenecks returning data to the client\n\nLatency and throughput are inversely proportional. As latency increases, throughput decreases. Intuitively this makes sense. As a bottleneck begins to materialize, operations start to take longer and the system performs fewer operations per second.\n**Fig. 2:** A figure that shows a typical latency scaling graph. The latency remains constant until friction occurs due to resource contention.\n\nThe latency scaling graph shows how latency changes as the load placed on a system increases. Latency stays relatively constant until friction occurs due to resource contention. The inflection point of this curve generally corresponds to the flattening of the throughput curve in the throughtput scaling graph.\n\nAnother useful way to evaluate latency is as a histogram. In this representation, we group latencies into buckets and count how many requests fall into each bucket.\n**Fig. 3:** A figure that shows a typical latency histogram. The latency remains constant until friction occurs due to resource contention.\\*\n\nThis latency histogram shows most requests are under 100 milliseconds, and latencies longer than 100 milliseconds. Understanding the cause of the requests with longer latencies tail can help explain the application performance variations seen. The causes of the long tail of increased latencies correspond to the increased latencies seen in the typical latency scaling graph and the flattening of the throughput graph.\n\nWhere the latency histogram is most useful is when there are multiple modalities in an application. A modality is a normal set of operating conditions. For example, most of the time the application is accessing pages that are in buffer cache. Most of the time, the application is updating existing rows, however, there might be multiple modes. Some of the time, the application is retrieving pages from storage, inserting new rows, or is experiencing lock contention.\n\nWhen an application encounters these different modes of operation over time, the latency histogram shows these multiple modalities.\n**Fig. 4:** A figure that shows a typical bimodal latency histogram. The latency remains constant until friction occurs due to resource contention.\n\nThis figure shows a typical bimodal histogram where most of the requests are serviced in under 100 milliseconds, but there is another cluster of requests that take 401-500 milliseconds. Understanding the cause of this second modality can help improve the performance of your application. There can be more than two modalities as well.\n\nThe second modality might be due to normal database operations, heterogeneous infrastructure and topology or application behavior. Some examples to consider are the following:\n\n- Most data accesses are from the PostgreSQL buffer pool, but some come from storage\n- Differences in network latencies for some clients to the database server\n- Application logic that performs different operations depending on input or time of day\n- Sporadic lock contention\n- Spikes in client activity"]]
