Performance Engineering 101: The Brass Tacks to Get You Started

DZone 's Guide to

Performance Engineering 101: The Brass Tacks to Get You Started

Welcome to your first lesson in performance testing and engineering. Take a seat and buckle up.

· Performance Zone ·
Free Resource

In a perfect world, software developers write bug-free code, clients are happy with the user experience, and everyone gets along just fine. In reality, application performance is always a challenge – developers and testers strive to make the application perform as close as possible to perfection, but much of this effort is based on assumptions. Often, these assumptions clearly miss the expected service and performance levels. Performance issues are addressed during the testing phase or when the customer complains. Subsequently, achieving customer satisfaction becomes a drawn-out process that could even push the project back to the drawing board.

The Road to Performance Engineering

Applications have become complex, because now they are distributed in nature, spanning across multiple modules and functionalities. For example, Google was primarily known as a search engine. Today, its ecosystem encompasses a browser, email service, word processor, video conferencing app, and much more.

As a result of such growing complexities, software developers have to ensure that the application has to be as scalable, secure, and responsive as possible. It is important to identify basic performance issues during the development phase itself; not just during the quality assurance phase. Designers and developers can then test and work with different solutions.

The basics of performance engineering are all about understanding how all the parts of a system work together and include the performance aspect right from the initial phase of designing and developing the software. Adoption of performance engineering at such an early stage can drastically decrease the need to rework and refactor the application and improves the application outcomes.      

Performance engineering is not only important from a software development perspective, but also in terms of business costs. According to a performance engineering report by Hewlett Packard, average-sized companies stand to lose $100,000 to $500,000 per hour in revenue due to IT outages. Large enterprises can lose up to $5 million an hour. Not exactly an insignificant amount of money that a business can afford to lose.  

Non-Functional Requirements – The Crux of Performance Engineering

The first sign of a successful software project is a clear definition of project requirements. Functional requirements define what the software application should do and non-functional requirements define how the software application should execute a particular function.  

For example, a typical functional requirement would be the sending of a confirmation email when a new user signs up. In terms of a non-functional requirements (NFR), a user should be able to complete the signup process within 60 seconds.

The standard modus operandi for software developers is to focus on getting only the functional requirements right, as meeting the business and process requirements is assigned the highest priority. The non-functional requirements take a backseat or are just based on performance tests. This approach undermines the long-term success of the project and how well the application works. Instead of testing system NFR performance, it is important to understand how they fit together in a system. Performance engineering is basically the application of certain methods to ensure that NFRs are met.     

Non-functional requirements are the primary building blocks that drive performance engineering. NFRs help software developers to understand the usage, load that the application is subjected to, and the expected response time. NFRs also help define the Service Level Agreements (SLA) for the application. Here are some of the vital information that you need when defining NFRs:

  • Application architecture
  • Domain and user information, infrastructure details, usage (transactions and hit count etc), and application load (peak hour, seasonal load information, user growth, etc)
  • Deployment infrastructure
  • User growth patterns (expected usage of the application in a specific period)
  • Scheduled application downtime in Application Maintenance Window
  • Duration of long-running jobs and its performance impact (CPU, memory, network, and I/O) during production hours

Application Performance

Application performance is the time taken by the application to respond to a transaction initiated by a user. This is one of the key factors that determine the operational success of an application. Non-adherence to performance SLA can lead to loss of business, end-user apathy, increased cost of ownership, loss of credibility, etc.

Performance Categories

Application performance is not just limited to a software or hardware perspective. As applications become more complex and platform agnostic, there a number of performance factors that need to be taken into consideration, right from the start of the application development process:

  • Speed (Response Time): The amount of time the system takes to respond to a user request or internally with its own modules.
  • Scalability: The ability of an application to quickly adapt to increasing workload by adding resources accordingly. The two types of application scaling are horizontal and vertical.
  • Stability and Resiliency: The ability of an application to recover from certain error types and at the same time, remain functional from the user perspective.
  • Application performance degradation: The application performance degrades over a period of time. (Memory leak).

The performance engineering process involves the following phases:

  • Performance Modeling – Performance estimation of a new system, the impact of change on an existing system, or impact of workload change on an existing system.
  • Performance Prototyping – Automatic generation and deployment of components, which mirrors the predetermined behavior of actual components under design, into actual IT infrastructure and environments.
  • Performance Testing – Software testing technique to ascertain the non-functional parameters of a system, such as responsiveness, stability, reliability, and resource usage, under different workloads.
  • Performance Analysis – Analysis of performance test results, segregation of relevant data points, trends identification, etc to identify the root cause of performance issues.
  • Performance Tuning –  Changes are made to the application to ensure improved performance through code optimization, configuration optimization, distributed computing, and so on.

The Buck Never Stops with Performance Engineering

Performance is everyone’s responsibility, irrespective of the role you play in the software development life cycle. It has to become part of an organization’s corporate DNA, so that developers, designers, database administrators, and other stakeholders work seamlessly together to achieve performance goals. Performance engineering should be the convention, even before a single line of code is written.    

engineering ,dev and test ,engineer ,developer ,performance engineering ,nfr ,application performance

Published at DZone with permission of Pragya Saxena . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}