Share this
Finding the haystack: troubleshooting a hard to find software performance problem
by Ben Rowan on 15 February 2016
A client came to us with a problem: The latest release of business critical, web-based software had been deployed into their Production environment. On the morning of the release, the service desk was flooded with calls from users reporting slow performance.
The release had been through the same performance testing process as all prior releases. Testing noted a small increase in measured response times, but users were reporting page load times of several seconds. The issues reported couldn’t be readily reproduced, and the vital statistics (application server resource consumption, etc.) looked good. There were no reports of other desktop or web applications running slow. So what was the problem, and how did we find it? This blog will be split into four parts:
- In 'Part one: On the hunt' (below), I look at the performance testing approach used for this application, and cover off the initial analysis completed, what conclusions were reached, and what areas of the system were left to cover.
- In 'Part two: Following the trail to performance problems in front of the webserver' and 'Part three: Target sighted – is Citrix causing the performance problem?' I look at how we followed the evidence trail, narrowing the problem space each time.
- In 'Part four: Gotcha! Pinpointing a browser performance problem under Citrix' (future post) we reveal the problem, and I discuss a couple of things we’ve now fed back in to our testing process as a result.
Part one: On the hunt
When trying to find a problem like this one, it’s important to understand what work has already been done to assess the known performance impacts associated with the release. This information can be used to do three things:- Determine whether the reported user experience is consistent with the performance test results. This helps to separate an “expected” change in performance from an “unexpected” change.
- Determine whether the performance seen in Production differs significantly from the performance seen during testing. If so, the problem may be environment or deployment related (for example, thread pools not correctly sized during deployment).
- Most importantly, understand the work that’s already been done allowing us to identify any gaps there may be between how real users access the system and how performance testing has been conducted.
Performance testing
The “what” and the “how”
The application was performance tested using Microsoft Visual Studio and WildStrait PI, which applies load to the HTTP layer (emulating requests made from a real web browser). Timing points were gathered by grouping individual HTTP response times together into a “transaction.” The transaction time represents the total time a user waited for the web application to provide the information required to draw the web page.
When done properly, a webserver should not be able to distinguish traffic generated by an HTTP emulation tool from traffic generated by a real web browser. HTTP emulation allows for accurate measurement of the stability, capacity and response time of a web server, and provides an indication of the best-case user experience.
What this approach lacks is an ability to measure browser-side processing (JavaScript, etc). With web-based applications it is often the case that factors such as browser-side performance, internet connection performance, etc, are out of scope for performance testing: While it’s useful to understand how these factors impact usability and the user experience, the end-user’s hardware and internet connection are ultimately outside the control of the system’s owners. In this engagement, browser performance risk is mitigated by having real users exercise the system from a real browser while HTTP load is applied via the test rig.
Releases of the application undergo performance testing in a non-functional test environment which is as close to Production as possible (server resources, data volumes, user volumes, etc). The test workload encompasses some 27 different transaction types, both front-end GUI transactions and back-end SOAP/JMS requests. The overall system workload was expected to remain unchanged for this release (no new functionality was added, and business transaction volumes were unchanged by the release).
Performance test transaction response time results
The results of performance tests that were executed in the test environment showed that, overall, the 80th percentile response time had increased from about 850ms to 950ms, and the 90th percentile from about 1.6 seconds to 1.7 seconds. 100ms in this context is a relatively small change. (I’d challenge anyone to consistently tell the difference between a 850ms and 950ms page draw!) Manual testing executed in parallel with the automated test suite did not identify any performance problems.
None of those results aligned with what users were reporting.
Production versus performance test environments
Most webservers record information about the requests they receive and the responses they provide. Among other things, this information normally includes the URL of the request, the request method (GET/POST/LOCK etc), HTTP response code (200, 304 etc), and – if configured to do so – the response time. While it is difficult to process these logs in a format which makes them comparable with WildStrait PI transaction response times, it was possible to directly compare the logs from the performance test (NFR) and Production environments. We found that:
- Webserver request volumes were a little higher in NFR than Production. This is good as it tells us we slightly overstated the workload.
- Webserver response times were substantially the same between the NFR and Production environments.
This analysis tells us there’s no gross difference between the performance of NFR and Production: We’d expect users to see a response time increase of about 100ms following this release, not the several seconds being reported to the service desk.
Further analysis was conducted to confirm that all application hosts, webservers and application servers reported the same performance. The consistent performance in all dimensions told us this wasn’t a problem on a single app host, web server or app server – all instances have comparable performance.
While the comparable performance between NFR and Production suggested there was no resource-related limitations, we did confirm the key resources (CPU, memory/swapping, network and disk) were operating comfortably at both the VM and physical levels.
Elimination, part one
Measurement of response times at the HTTP layer neatly encapsulates the performance of all components “behind” the webserver:
- Application servers
- Database server
- Underlying storage (SAN), including database storage
- Network interconnects between the above systems
So we could conclude from our investigation that the performance problem is very unlikely to be found server side.
This is a good starting point, as it narrows the problem space considerably. But it does leave a long list of possibilities: Everything in front of the webserver. This includes:
- Load balancer (as this is outside the webserver response time measurements)
- Network (WAN and LAN) between the client and the server
- End-user computing environment
- Web browser and client side script
Look out for the next article in this series 'Part two: Following the trail to performance problems in front of the webserver'.
Share this
- Agile Development (153)
- Software Development (126)
- Agile (76)
- Scrum (66)
- Application Lifecycle Management (50)
- Capability Development (47)
- Business Analysis (46)
- DevOps (43)
- IT Professional (42)
- Equinox IT News (41)
- Agile Transformation (38)
- IT Consulting (38)
- Knowledge Sharing (36)
- Lean Software Development (35)
- Requirements (35)
- Strategic Planning (35)
- Solution Architecture (34)
- Digital Disruption (32)
- IT Project (31)
- International Leaders (31)
- Digital Transformation (26)
- Project Management (26)
- Cloud (25)
- Azure DevOps (23)
- Coaching (23)
- IT Governance (23)
- System Performance (23)
- Change Management (20)
- Innovation (20)
- MIT Sloan CISR (15)
- Client Briefing Events (13)
- Architecture (12)
- Working from Home (12)
- IT Services (10)
- Data Visualisation (9)
- Kanban (9)
- People (9)
- Business Architecture (8)
- Communities of Practice (8)
- Continuous Integration (7)
- Business Case (4)
- Enterprise Analysis (4)
- Angular UIs (3)
- Business Rules (3)
- Java Development (3)
- Lean Startup (3)
- Satir Change Model (3)
- API (2)
- Automation (2)
- GitHub (2)
- Scaling (2)
- Toggles (2)
- .Net Core (1)
- Diversity (1)
- Security (1)
- Testing (1)
- February 2024 (3)
- January 2024 (1)
- September 2023 (2)
- July 2023 (3)
- August 2022 (4)
- August 2021 (1)
- July 2021 (1)
- June 2021 (1)
- May 2021 (1)
- March 2021 (1)
- February 2021 (2)
- November 2020 (2)
- September 2020 (1)
- July 2020 (1)
- June 2020 (3)
- May 2020 (3)
- April 2020 (2)
- March 2020 (8)
- February 2020 (1)
- November 2019 (1)
- August 2019 (1)
- July 2019 (2)
- June 2019 (2)
- April 2019 (3)
- March 2019 (2)
- February 2019 (1)
- December 2018 (3)
- November 2018 (3)
- October 2018 (3)
- September 2018 (1)
- August 2018 (4)
- July 2018 (5)
- June 2018 (1)
- May 2018 (1)
- April 2018 (5)
- March 2018 (3)
- February 2018 (2)
- January 2018 (2)
- December 2017 (2)
- November 2017 (3)
- October 2017 (4)
- September 2017 (5)
- August 2017 (3)
- July 2017 (3)
- June 2017 (1)
- May 2017 (1)
- March 2017 (1)
- February 2017 (3)
- January 2017 (1)
- November 2016 (1)
- October 2016 (6)
- September 2016 (1)
- August 2016 (5)
- July 2016 (3)
- June 2016 (4)
- May 2016 (7)
- April 2016 (13)
- March 2016 (8)
- February 2016 (8)
- January 2016 (7)
- December 2015 (9)
- November 2015 (12)
- October 2015 (4)
- September 2015 (2)
- August 2015 (3)
- July 2015 (8)
- June 2015 (7)
- April 2015 (2)
- March 2015 (3)
- February 2015 (2)
- December 2014 (4)
- September 2014 (2)
- July 2014 (1)
- June 2014 (2)
- May 2014 (9)
- April 2014 (1)
- March 2014 (2)
- February 2014 (2)
- December 2013 (1)
- November 2013 (2)
- October 2013 (3)
- September 2013 (2)
- August 2013 (6)
- July 2013 (2)
- June 2013 (1)
- May 2013 (4)
- April 2013 (5)
- March 2013 (2)
- February 2013 (2)
- January 2013 (2)
- December 2012 (1)
- November 2012 (1)
- October 2012 (2)
- September 2012 (3)
- August 2012 (3)
- July 2012 (3)
- June 2012 (1)
- May 2012 (1)
- April 2012 (1)
- February 2012 (1)
- December 2011 (4)
- November 2011 (2)
- October 2011 (2)
- September 2011 (4)
- August 2011 (2)
- July 2011 (3)
- June 2011 (4)
- May 2011 (2)
- April 2011 (2)
- March 2011 (3)
- February 2011 (1)
- January 2011 (4)
- December 2010 (2)
- November 2010 (3)
- October 2010 (1)
- September 2010 (1)
- May 2010 (1)
- February 2010 (1)
- July 2009 (1)
- April 2009 (1)
- October 2008 (1)