在对性能进行调优时，请一次只更改一个变量。如果您在运行之间更改多个变量，则无法确定哪个变量改进了性能。事实上，多个更改可能会相互抵消，因此您不会观察到适当更改带来的好处。如果数据库服务器利用率过高，请尝试改用配备更多 vCPU 的机器，同时保持负载不变。如果数据库服务器利用率过低，请尝试增加负载，同时保持 CPU 配置不变。
在部署应用时，您可能需要考虑典型的高流量 Web 应用，以便更好地了解跨可用区延迟时间的影响。应用有一个负载均衡器，用于将请求发送到部署在多个可用区中的多个 Web 服务器，以实现高可用性。由于跨可用区延迟时间存在差异，延迟时间可能会因处理请求的 Web 服务器而异。
下图展示了使用 AlloyDB Omni 的 Web 应用的典型架构。客户端请求由负载均衡器处理，它会将每个请求转发到众多 Web 服务器中的某一个。Web 服务器全部连接到 AlloyDB Omni。某些服务器位于与 AlloyDB Omni 运行位置不同的可用区中，在发出数据库请求时会遇到更长的延迟时间。
图 1：典型 Web 应用架构的图示。我们预计可用区 B 中的 Web 服务器向数据库发出请求时的延迟时间会更短，因为它们与 AlloyDB Omni 数据库位于同一可用区中。
资源监控
如需优化数据库系统的性能，您需要监控数据库系统和使用数据库系统的客户端系统的资源使用情况。通过监控这两个系统，您可以确保客户端系统提供足够的工作负载，以便在数据库系统中获得有意义的测量结果。监控您所测试的系统的资源利用率至关重要。监控您用于驱动工作负载的客户端系统的资源利用率同样重要。例如，如果您想确定数据库系统在用尽 CPU 资源之前可以支持的客户端数量上限，则需要足够的客户端系统来生成用尽数据库系统中所有 CPU 资源所需的工作负载。如果生成负载的客户端机器本身没有足够的 CPU，您将无法充分驱动数据库系统。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-22。"],[[["\u003cp\u003ePerformance testing should have clearly defined goals, such as measuring maximum throughput, query duration, or the impact of the Columnar Engine, to inform the choice of benchmark, environment, and metrics.\u003c/p\u003e\n"],["\u003cp\u003eRepeatability in performance testing is crucial for drawing accurate conclusions, requiring consistent workloads and ideally isolated environments to minimize result variability.\u003c/p\u003e\n"],["\u003cp\u003eThe size of the test dataset should be representative of the application's actual data volume to ensure accurate performance assessments, as the data amount can affect query optimization and performance.\u003c/p\u003e\n"],["\u003cp\u003ePerformance tests should run for at least 20 minutes to account for system warm-up and capture steady-state performance, as well as the impact of database operations like checkpoints.\u003c/p\u003e\n"],["\u003cp\u003eNetwork topology plays a significant role in performance, with co-locating clients and the database in the same zone reducing latency, which is especially important for high-throughput applications.\u003c/p\u003e\n"]]],[],null,["# Performance testing methodology for 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/performance-testing)\n- [16.8.0](/alloydb/omni/16.8.0/docs/performance-testing)\n- [16.3.0](/alloydb/omni/16.3.0/docs/performance-testing)\n- [15.12.0](/alloydb/omni/15.12.0/docs/performance-testing)\n- [15.7.1](/alloydb/omni/15.7.1/docs/performance-testing)\n- [15.7.0](/alloydb/omni/15.7.0/docs/performance-testing)\n\n\u003cbr /\u003e\n\nThis document describes recommendations for running performance tests on AlloyDB Omni on a VM. This document assumes that you're familiar with PostgreSQL.\n\n\u003cbr /\u003e\n\nWhen benchmarking performance, define what you expect to learn from the test before beginning. For example:\n\n- What is the maximum throughput the system can achieve?\n- How long does a particular query or workload take?\n- How does the performance change as the amount of data increases?\n- How does the performance of two different systems compare?\n- How much does the Columnar Engine reduce the response time of my query performance?\n- How much load can a database handle before I should consider upgrading to a more powerful machine?\n\nUnderstanding the goals of your performance study informs what benchmark you run, what environment is required, and what metrics you need to collect.\n\nRepeatability\n-------------\n\nTo draw conclusions from performance testing, the test results must be repeatable. If your test results have a wide variation, assessing the impact of changes you made in the application or the system configuration will be difficult. Running tests multiple times or for longer periods of time to provide more data can help lower the variation amount.\n\nIdeally, performance tests should be run on systems that are isolated from other systems. Running in an environment where external systems can affect the performance of your application can lead to drawing incorrect conclusions. Full isolation is often not possible when running in a multi-tenant, cloud environment, so you should expect to see greater variability in the results\n\nPart of repeatability is ensuring that the test workload remains the same between runs. Some randomness in the input to a test is acceptable as long as the randomness does not cause significantly different application behavior. If randomly generated client input changes the mix of reads and writes from run to run, performance will vary significantly.\n\nDatabase size, caching, and I/O patterns\n----------------------------------------\n\nEnsure the amount of data you are testing with is representative of your application. Running tests with a small amount of data when you have hundreds of gigabytes or terabytes of data will likely not give a true representation of how your application performs. The size of the dataset also influences choices the query optimizer makes. Queries against small test tables may use table scans that give poor performance at larger scales and you won\\`t identify missing indexes in this configuration.\n\nStrive to replicate the I/O patterns of your application. The ratio of reads to writes is important to the performance profile of your application.\n\nBenchmark Duration\n------------------\n\nIn a complex system, there is a lot of state information that is maintained as the system executes: database connections are established, caches are populated, processes and threads are spawned.\nAt the start of a performance test, the initialization of these components could take up system resources and adversely affect the measured performance if the runtime of the workload is too short.\n\nWe recommend running performance tests for at least 20 minutes to minimize the effects of warming up the system. Measure performance during a steady state after startup and long enough to ensure that all aspects of database operations are included. For example, database checkpoints are a critical feature of database systems and can have a significant impact on performance. Running a short benchmark that completes before the checkpoint interval hides this important factor in your application\\`s behavior.\n\nMethodical testing\n------------------\n\nWhen tuning performance, change only one variable at a time. If you change multiple variables between runs, you won't be able to isolate which variable improved performance. In fact, multiple changes can offset each other so you won't see the benefit of an appropriate change. If the database server is overutilized, try switching to a machine with more vCPUs while keeping the load constant. If the database server is underutilized, try increasing the load while keeping the CPU configuration constant.\n\nNetwork topology and latencies\n------------------------------\n\nThe network topology of your system can affect the performance test results. Latency between zones differs. When doing performance testing, ensuring that the client and the database cluster are in the same zone minimizes the network latency and yields the best performance--especially for applications with high throughput, short transactions as the network latency can be a big component of the overall transaction response time.\n\nWhen comparing the performance of two different systems, ensure the network topology is the same for both systems. Note that network latency variability cannot be completely eliminated, even within the same zone there can be differences in latency due to underlying network topologies.\n\nWhen deploying your application, you might want to better understand the impact of cross zone latencies by considering a typical high volume web application. The application has a load balancer sending requests to multiple web servers deployed across multiple zones for high availability. The latencies might differ depending on which web server processes a request because of cross-zone latency differences.\n\nThe following figure shows the typical architecture of a web application using AlloyDB Omni. Client requests are handled by a load balancer, which forwards each request to one web server out of many. The web servers are all connected to AlloyDB Omni. Some servers are in a different zone from where AlloyDB Omni is running, and will encounter higher latencies when making database requests.\n**Fig. 1:** A figure of a typical web application architecture. We would expect lower latencies when the web servers in Zone B make requests to the database because they are in the same zone as the AlloyDB Omni database.\n\nResource Monitoring\n-------------------\n\nTo optimize the performance of your database system, you need to monitor the resource usages of both the database system and the client systems using the database system. By monitoring both systems, you can ensure that the client systems are providing enough workload to get meaningful measurements in the database system. Monitoring the resource utilization of the system you are testing is critical. Monitoring the resource utilization of the client systems you are using to drive the workload is equally important. For example, if you want to determine the maximum number of clients your database system can support before it runs out of CPU resources, you will need sufficient client systems to generate the workload required to use up all the CPU resources in the database system. You won't be able to drive the database system hard enough if the client machines generating load don't have sufficient CPU themselves.\n\nScalability testing\n-------------------\n\nScalability testing is another aspect of performance testing. Scalability refers to how performance metrics change as one characteristic of a workload varies. Some examples of scalability studies include:\n\n- How does an increase in the number of concurrent requests change throughput and response times?\n- How does an increase in database size change the throughput and response times?\n\nScalability tests consist of multiple runs of a workload where a single dimension is varied between runs and one or more metrics are collected and plotted. This type of testing informs decisions about what bottlenecks exist in the system, how much load the system can handle given a specific configuration, the maximum load a system can support, and what the behavior of the system is when the load increases beyond those levels.\n\nMachine size considerations\n---------------------------\n\nAlloyDB Omni introduces many new features to Postgres to improve the reliability and availability of the database. The monitoring necessary to do this uses resources on the machine running AlloyDB Omni. On very small machine sizes there are limited memory and CPU resources to begin with, so for benchmarking, we recommend using machine sizes of four vCPUs minimally."]]
