JMeter入门：Web应用性能测试实战指南

需积分: 10 195 浏览量更新于2024-07-18 1 收藏 18.87MB PDF 举报

"《Pro Apache JMeter：Web应用性能测试实战》是一本深入介绍Apache JMeter 3的专业教程，由Sai Matam和Jagdeep Jain共同编著。这本书针对性能测试的基础知识和实践进行了详尽讲解，旨在帮助读者理解和掌握JMeter在Web应用性能测试中的关键作用。第1章“基础”首先探讨了性能测试的重要性，包括响应时间、吞吐量、利用率、系统鲁棒性、可扩展性和用户体验等性能指标。书中解释了为什么进行性能测试以及选择JMeter的原因，强调了其在现代软件开发中的不可或缺性。第二章“性能测试入门”进一步阐述了不同类型性能测试的定义和目标，如压力测试、负载测试、峰值负载测试、耐久性测试（Soak测试）、可扩展性测试、容量测试、尖峰容量测试、性能验证测试和高可用性/故障切换测试。这些章节详细介绍了如何设计和执行有效的性能测试，确保测试环境与生产环境类似但隔离，以便获得准确的结果。此外，作者还讨论了性能测试工具的选择，如何制定性能测试策略文档，明确性能需求和目标，以及如何构建一个完整的性能测试套件。这些都是进行成功性能测试的关键步骤，对于Web应用开发者和运维人员来说，这是一本实用且深入的指南，能够提升他们对JMeter 3的理解和运用能力，尤其是在面对高并发、大数据量和复杂业务场景时，能够有效地优化应用程序性能，确保系统的稳定性和用户满意度。尽管原版书籍在亚马逊售价较高，但本书提供的价值远远超过其价格，是JMeter学习者和专业人员的理想参考资源。"

CHAPTER 2 ■ PERFORMANCE TESTING PRIMER

Utilization

Utilization is the ratio of the throughput of the application relative to its maximum capacity. This is a

measure of how well the application is being used.

It is not desirable to operate above 80% utilization because the user requests do not arrive evenly, and

the system should be able to handle a spike in the load.

Robustness

This is a measure of how well the application detects and handles various errors and exceptions. If the

system crashes or becomes unavailable, the company’s brand and reputation are at stake. Mean Time

between Failures (MTbF) is a metric that is often used for this purpose.

Scalability

Scalability measures how well the system can expand its capacity when additional resources are added.

Ideally the system capacity will increase linearly as additional resources are added. However, this is rarely

achieved in practice. It’s a good measure to know the resources that would be needed so that the system can

handle the projected future load.

Vertical scalability is achieved by upgrading the hardware. For example, by adding more memory, disk,

a better CPU, or additional CPUs.

Horizontal scalability is achieved by adding servers to the cluster. For example, by adding more web

servers and application servers to a webfarm/cluster.

User Perception

The user is the ultimate judge of performance. The user has a set expectation regarding response time and

robustness. If this is a casual news web site, the response time of six seconds may be okay. However, in the

case of stock trading application, a sub-second response may be needed. Performance tuning is done if

the measured performance is less than expected for that category of application. As mentioned earlier, the

request/response may be restructured to improve the user perceived response time.

Cost

The system should consume fewer resources and save money for the company.

Utilization and throughput are some of the measures that influence cost.

Types of Performance Tests

The term performance test is used loosely to mean many different types of tests. Furthermore, the distinction

between the various flavors of the performance tests is not widely understood. This is all the more reason for

you to include a definition of these tests in your Performance Strategy document to make things clear.

Stress Tests

A stress test is a kind of performance test that tests the application beyond the normal limits. The application

is subjected to excess load and after that its stability and performance are noted. This type of test is used to

determine how the application responds to load spikes.

CHAPTER 2 ■ PERFORMANCE TESTING PRIMER

■ Note Performance tests evaluate and measure the application under a normal expected load. The stress

test subjects the application to loads which are in far excess of normal.

Load Tests

A load test is a kind of performance test that’s performed at the specified load level. So ideally, we would like

to perform load tests at varying load levels to note the behavior of the application.

Peak Load Tests

A peak load test is performed at the load that the application is expected to handle. For example, e-commerce

web sites experience their peak traffic during Black Friday, Cyber Monday, and the Christmas holidays. So a

peak load test in this case would test the application within the load specification but at the higher end.

■ Note Stress tests test beyond the peak load.

Soak Tests or Endurance Tests

In a soak test (also called an endurance test), the application is subjected to a specified load that is within the

specified limit but for a long duration. It is performed for many hours at a time. This test determines if the

application is properly reusing its resources.

This test will surface problems like the following:

• Memory leaks in the application

• Database connections exhaustion

• Network connection exhaustion

• Log files becoming full and log rotation

• Other resource exhaustion

Scalability Tests

Successful web applications experience massive and sometimes exponential growth. So it is wise to measure

how the application scales. Scalability is defined as how well the application handles the increase in load

while still meeting the desired performance criteria.

A scalability test would increase the resources and test whether or not the application is providing

a corresponding increase in capacity. Ideally, we expect linear scalability (i.e., doubling the hardware

resources should result in double the application capacity).

Capacity Tests

A capacity test is a load test that establishes the maximum load that the application can handle while

meeting the desired performance criteria. The resulting metric is called the maximum capacity. It is used in

scaling the application and to estimate costs for future growth.

CHAPTER 2 ■ PERFORMANCE TESTING PRIMER

Spike Tests and Burst Capacity

A spike test is a load test where the application is subjected to brief periods of sudden increment in load, a

small fraction beyond the maximum capacity. It is usually done to estimate the weakness/strength of an

application. The application is expected to be robust and continue to meet the performance criteria during

the spike. This metric is called the burst capacity.

Performance Smoke Tests

In a performance smoke test, a few common and essential use-cases along with use-cases pertaining to the

code subject to change are together tested for performance. It is only when the smoke test succeeds that

the full suite of performance tests are conducted. If the smoke test fails, no further performance tests are

conducted until the performance defect has been rectified.

High Availability Test/Fail-Over Tests

Modern web application infrastructure is designed to be highly available and resilient to hardware and

software failures. Ideally, the architecture should ensure that there is no single point of failure and that there

are standby servers that can transparently take over without impacting the user experience.

In this test various equipment and software failures are simulated and relevant performance tests are

run to verify that the application is still meeting the performance criteria.

SIMIAN ARMY AT NETFLIX INC.

Netflix is a well known provider of digital media streaming services, serving more than 74 million

subscribers in 190 countries. Performance and robustness are critical for it to survive.

The Netflix engineering team has come up with the concept of “chaos engineering,” in which defects

are deliberately introduced to the production system to test and validate if the system is robust enough

to fail-over and recover from the errors while meeting the pre-established performance criteria. It

developed a set of tools dubbed as the Simian Army, a couple of which are summarized here.

Chaos Monkey

It randomly disables the production instances to make sure that the system can survive this common

type of failure without any customer impact.

Chaos Gorilla

Similar to Chaos Monkey, but simulates an outage of an entire Amazon availability zone. It verifies that

the services automatically rebalance to the functional availability zones without user-visible impact or

manual intervention.

“Chaos Engineering Upgraded,” The Netflix Tech Blog, September 24, 2015, http://techblog.netflix.com/

2015/09/chaos-engineering-upgraded.html.

CHAPTER 2 ■ PERFORMANCE TESTING PRIMER

The Performance Test Environment

The hardware and software used to conduct performance testing is called the performance test environment.

It is usually separate from the production environment. Although not advisable, sometimes performance

testing is done in the production environment itself.

The Need for Separate Performance Environment

Performance testing should not be performed in the production environment as it may negatively impact

the user experience.

The load from performance testing may:

• Crash the system

• Degrade the application response time

• Create security holes due to the use of test accounts

• Litter the production databases with performance test input and output data

• Fill up the databases, application log files, and system log files

• Affect the analytics

In the long run, it is wise to have a dedicated performance environment as it would avoid these pitfalls

and would provide the benefit of Continuous Integration (CI). In fact, some companies have more than one.

The advent of cloud computing enables such environments to be provisioned on demand at a low cost.

Performance testing needs to happen before software is deployed into production. Ideally this needs to

be a part of the build process so that any performance defects introduced as a result of software changes can

quickly be detected and rectified.

Despite the benefits of a performance test environment, sometimes performance testing is done in the

production environment because it is prohibitively expensive to duplicate the production environment in

terms of hardware, additional software licenses, and third-party services.

The Performance Environment Should Be Like the Production

Environment

The performance environment should be modeled after the production environment. In an ideal scenario,

the performance environment should be a replica of the production environment in terms of hardware,

software, network, components, and topology. However, due to budget and other constraints, this may not

be possible. In such cases, the performance environment should mimic the production environment in all

key aspects. Some logical compromises will have to be made. For example, instead of a cluster of four web

servers, the team may choose to go with a minimal cluster of two servers. They may decide to go with a

single instance of the database instead of a master-slave database configuration in production.

The Performance Environment Should Be Isolated

The performance environment should be on a different subnet, isolated from the production environment

so that any activity on the performance subnet will not influence production and vice versa.

剩余339页未读，继续阅读

Thinlk

粉丝: 3
资源: 20

JMeter入门：Web应用性能测试实战指南

Pro_Apache_JMeter测试工具

pro-apache-jmeter:Sai Matam和Jagdeep Jain的“ Pro Apache JMeter”源代码-apache source code

《Pro Apache JMeter》源码库：深入学习JMeter性能测试

Pro Apache JMeter：2017 Web应用性能测试权威指南

jmeter第8章 高级篇之阿里云压测 html可视化压测报告细讲

ProApache JMeter：精通Web应用性能测试指南

Gel-PRO ANALYZER软件升级与维护：最佳实践

性能监控：proUSB注册机文件改进的关键指标

故障诊断：proUSB注册机文件问题定位速成手册

荣耀路由Pro固件ws851固件稳定性测试：深度分析报告

最新资源

jmeter第8章高级篇之阿里云压测 html可视化压测报告细讲