# Performance Testing Serverside Applications

DevFeed: [Performance Testing Serverside Applications](<https://devfeed.tech/articles/performance-testing-serverside-applications-24962.md>)

Original publisher: [Read original article](<https://codeahoy.com/2016/11/16/performance-testing-serverside-applications/>)

Author: umer

Published: 2016-11-16T00:00:00Z

Content type: article

Language: en

Sources: [Code Ahoy - Articles](<https://devfeed.tech/sources/code-ahoy-articles.md>)

Topics: [Performance Testing](<https://devfeed.tech/topics/performance-testing.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [Back end](<https://devfeed.tech/topics/backend.md>), [cpu](<https://devfeed.tech/topics/cpu.md>), [Database](<https://devfeed.tech/topics/database.md>), [Algorithms](<https://devfeed.tech/topics/algorithms.md>), [Graphs](<https://devfeed.tech/topics/graphs.md>)

Tags: [algorithms](<https://devfeed.tech/tags/algorithms.md>), [backend](<https://devfeed.tech/tags/backend.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [database](<https://devfeed.tech/tags/database.md>), [graph](<https://devfeed.tech/tags/graph.md>), [latency](<https://devfeed.tech/tags/latency.md>), [metrics](<https://devfeed.tech/tags/metrics.md>), [performance-testing](<https://devfeed.tech/tags/performance-testing.md>), [testing](<https://devfeed.tech/tags/testing.md>)

## AI overview

The article explains why teams should begin performance testing server-side applications early in the release cycle. It covers load and soak testing, response times, latency, throughput, resource utilization, capacity planning, and bottleneck detection, and describes a backend service whose CPU-intensive database queries and graph algorithms caused substantially lower-than-expected capacity and higher infrastructure costs.

## Source excerpt

Performance testing server-side applications is a crucial process to help understand how the application behaves under load. It helps software teams fine-tune their applications to get the best performance while keeping the infrastructure costs low. Performance testing answers several important questions such as: Is the application ready to handle the traffic that's going to hit it? What do average response times and latencies look like under normal and peak loads? Can the application be scaled out? What are the bottlenecks? (could be CPU, memory, an external service or a database server) How many instances are needed for supporting the estimated traffic (i.e. max RPS)? What type of instances are needed? Does the application requires an instance with higher CPU to Memory ratio? Or does it need an instance type that supports high network utilization? Does the application slowly degrade in performance under load? Is it slowly leaking a resource that eventually crashes it after a few hours or days? A lesson I learned recently is that performance testing should not be an after-thought. Software teams should start performance testing early in the release cycle and not wait until the end to do it. I once worked on a team that built a backend service that passed all unit, integration and end-to-end tests with flying colors. QA engineers didn't find any bugs in the application's logic. However, the performance was just terrible when we ran load tests on it. On a single m4.large instance, the application supported 80% fewer requests than the team had estimated! The main bottleneck was found to be the 2-core CPU that was utilized to its maximum capacity as the application issued several queries to the database and applied complex algorithms to build a graph. Investigations by developers revealed that to reduce the amount of work the CPU was doing, it would require significant design changes. But it was already too late - the deadline was just weeks away. We decided to proceed