As release velocity increases, teams are finding innovative ways to detect and resolve performance issues earlier in the development cycle. This session will explore how to integrate performance testing into a development lifecycle and why the practice is gaining popularity. Learn how to create a balanced test strategy that matches test type, coverage, environment, and defect target. Scale to deliver high-performing applications. Through continuous integration platforms, performance testing tools, and AppDynamics, see how automated performance testing can reduce time-to-market while increasing overall quality.
Key takeaways:
o How to get started with performance test automation
o How to detect and resolve performance issues earlier in the development lifecycle with AppDynamics
o How to maximize the quality and value of your performance test strategy
Brad Stoner
Senior Sales Engineer, AppDynamics
Resources:
KonaKart - http://www.konakart.com/
Adminer - https://www.adminer.org/
Jenkins - https://jenkins.io/
NeoLoad - http://www.neotys.com/neoload/overview
AppDynamics - https://www.appdynamics.com/free-trial/
GitHub - https://github.com/
Docker Hub - https://hub.docker.com/
3. Key takeaways
• How to get started with performance test automation
• How to detect and resolve performance issues earlier in the
development lifecycle with AppDynamics
• How to maximize the quality and value of your performance test
strategy
AppDynamics Confidential and Proprietary 3
4. My background
• 7 years @ H&R Block Load and Performance Team
– 5 person team
– 100k + user concurrency
– Tax peak 2nd week after go-live
– 70 applications annually
– Diverse technology stack – including 3rd party
• 2 years @ Neotys – Senior Performance Engineer
• Currently Sales Engineer @ AppDynamics
AppDynamics Confidential and Proprietary 4
6. Why bother?
AppDynamics Confidential and Proprietary 6
Google - Using page speed in site ranking
Facebook - Launches 'lite' mobile app
Amazon - 100ms delay -> $6.79M sales
decrease
Recent airline industry outages
11. Pull back the layers
AppDynamics Confidential and Proprietary 11
Prod / Perf
Pre-Prod /
Staging
Dev / QA
12. Dev / QA
• Short test cycle
• Low resources / cost
• Rapid feedback
• Component testing
AppDynamics Confidential and Proprietary 12
13. Staging / Pre-Prod
• Increased resources
• Long test durations
• Additional resources
• Multiple test
elements
• Integrated systems
• Build validation
AppDynamics Confidential and Proprietary 13
14. Prod / Perf
• High complexity
• Multiple integrated
systems
• Environmental variance
• Resource intensive
• High cost
AppDynamics Confidential and Proprietary 14
16. Mobile web/app example
Dev testing - APIs
Staging testing – Capacity w/ UI
and API
Build automation
Baseline Pre-Prod / Staging -
platform
Prod / Perf testing (inside
firewall) – stability /
scalability
Prod / Perf testing
(outside firewall) –
network / load
balancing
QA testing – API flows
Optimize app chatter
and network
resources
Mobile app released
Mobile app built
Mobile site releasedMobile site built
APIs released/ BE functionality
Front End
Optimization
17. What if legacy test principles were applied?
Staging testing –
Capacity w/ UI and API
Baseline Pre-Prod /
Staging - platform
Prod / Perf testing (inside firewall) –
stability / scalability
Prod / Perf testing (outside
firewall) – network / load
balancing
Front End
Optimization
Optimize app
chatter and
network
resources
Mobile app released
Mobile app built
Mobile site releasedMobile site built
APIs released/ BE functionality
19. AppDynamics Key Components
AppDynamics Usage
Compare Releases Compare critical metrics for different tests (FE and BE)
Database Monitoring Measure and visualize performance deltas between tests
Server Monitoring Measure and visualize performance deltas between tests
Jenkins Plugin Enables automated pass/fail of tests
Troubleshoot Slow
Response Times
Quickly find root cause of performance issues and test failure
Service Endpoints Track shared services performance over time (APIs)
Custom Match Rules Name Business Transactions to match load test scripts
Custom Dashboards Management and technical level tracking of application
performance
AppDynamics Confidential and Proprietary 19
20. Questions and contact
• Email: brad.stoner@appdynamics.com
• Twitter: @sandbreak80
AppDynamics Confidential and Proprietary 20
21. Please give us your feedback—Session T5808
• Complete the online survey you'll receive via
email later today or via text at:
Text this number: 878787
Text this word: APPSPHERE
• Every time you submit a session survey, your
name will be entered in a random drawing.
We're giving away Amazon Echos
to 5 lucky winners!
• Thank you for your input
APPDYNAMICS CONFIDENTIAL AND PROPRIETARY 21
Win!
37. Demo resources
• AppDynamics controller - https://www.appdynamics.com/free-trial/
• Docker Compose YML: https://github.com/sandbreak80/myapp
• NeoLoad project for KonaKart (localhost):
https://github.com/sandbreak80/konakart
– Jenkins user will need access to modify these files
• Docker Hub for mysql access via adminer:
https://hub.docker.com/r/sandbreak80/adminer/
• Docker Hub for konakart:
https://hub.docker.com/r/sandbreak80/docker_konakart/
AppDynamics Confidential and Proprietary 37
40. Configure AppDynamics
• Connect to the KonaKart instance
– sudo docker exec -i -t konakart /bin/bash
• Install VIM: apt-get install vim
• Edit the tomcat environment file
– vi /usr/local/konakart/bin/setenv.sh
– export CATALINA_OPTS="$CATALINA_OPTS -
javaagent:/home/appdynamics/java_agent/javaagent.jar
– -Dappdynamics.controller.hostName=your_controller_name_or_ip
– -Dappdynamics.controller.port=8090
– -Dappdynamics.agent.applicationName=KonaKart
– -Dappdynamics.agent.tierName=Kona_Server
– -Dappdynamics.agent.nodeName=Node1
– -Dappdynamics.agent.accountName=customer1
– -Dappdynamics.agent.accountAccessKey=your_access_key"
AppDynamics Confidential and Proprietary 40
41. AppDynamics authentication
• BASIC authentication is used in AppDynamics to create custom events and time ranges in the
next two slides
– As a reference, the AppDynamics REST API is documented here -
https://docs.appdynamics.com/display/PRO42/Using+the+Controller+APIs.
– The first call authenticates with the AppDynamics controller, and stores the authentication cookie into
/tmp/session.dat on the Jenkins Server. Note that we’re using a basic authentication header instead of
directly exposing our username and password.
– There are a number of utilities you can leverage to base64 encode a string, like
https://www.base64encode.org/.
– The username / password format to encode is: <username>@<account name>:<password> and the @
symbol needs to be URI encoded.
– By default, in single tenant controllers, the <account name> will always be customer1. So, to get our
base64 authentication header we can encode - admin%40customer1:appdynamics – to get our
authentication header
– YWRtaW4lNDBjdXN0b21lcjE6YXBwZHluYW1pY3M=
– ***Note***
– We need to URI encode our username and password string, which is why we use ‘%40’ instead of the
‘@’ character.
AppDynamics Confidential and Proprietary 41
In software engineering, performance testing is in general, a testing practice performed to determine how a system performs in terms of responsiveness and stability under a particular workload. It can also serve to investigate, measure, validate or verify other quality attributes of the system, such as scalability, reliability and resource usage.*
Load Test
Performance Test
Stress Test
Scalability Test
Capacity Test
Endurance Test
Workload Test
Device, FE, BE, end-to-end
* https://en.wikipedia.org/wiki/Software_performance_testing
Google site speed - https://webmasters.googleblog.com/2010/04/using-site-speed-in-web-search-ranking.html
Facebook lite - https://www.cnet.com/news/facebook-lights-up-slow-old-android-phones-with-messenger-lite-app/
Gartner / Amazon - https://www.gartner.com/doc/2840618/performance-affects-user-experience-line
Test after QA and right before launch / deployment to prod
Test entire application in war room
Complex workloads and use cases
3-5 weeks to complete
3-5 days to script single use case
Difficult to pinpoint root cause
Test high volume, long duration
Peel back onion approach – GIANT ONION (more later)
Test system capacity and scalability
Code focused – only if needed
Require code freeze
Potentially expensive and time consuming changes
Customers want everything faster
Business demands quicker time to market
Reduce risk and pain of ‘giant deployments’
Resolve defects faster at a lower cost
Keep competitive
… Performance testing isn't historically fast
“It takes 2 weeks to script all our use cases and we get releases every 3 days”
“The application is too difficult to test”
“We are moving to agile on our legacy waterfall project. How we get started?”
“QA will always be the bottleneck”
“Issues are difficult to reproduce and our environment is unstable”
“We don’t have visibility into our infrastructure”
“If we find an issue, it still takes a week to fix”
“We have no idea what changed in the application or why we are testing it again”
Too many potential defects to have in large scale, high volume testing
Performance testing is an iterative process
Dev / QA
Single server, low concurrency, short test durations.
DATA SIZE is important in each and every environment
WalMart labs – react w/ node.js - https://medium.com/walmartlabs/introducing-electrode-an-open-source-release-from-walmartlabs-14b836135319#.rtmzneqnk
Front End Optimization (cache, minimize, round trips, content size, compression)
Code issues (concurrency, locking, blocking, deadlock, single threaded)
Queue build-up
Code level performance (method / class)
Slow responses (functional load)
Issues with Memory allocation
3rd party code or frameworks
Having debug enabled
JS execution times
Sync vs async calls
Unlimited queries (return all rows)
Caching (code / object)
Excessive DB queries
Logging Levels
Staging / Pre-Prod
Medium concurrency, soak testing (long duration), multiple servers.
Some tests target web tier, some target database tier, try to stress each for optimal coverage
Isolate tiers – find needed capacity for prod
Memory leaks
Thread exhaustion
User limits
Garbage collection (STW)
Stored procedure inefficiencies
Missing indexes / Schema issues
DB connection pool issues
Keep Alive issues
Data Size Issues
Issues with virus scan / security software
3rd party integrations
Internal integrations
CPU limitations
Memory limitations
Configuration issues / default install – Huge!
Data growth issues
Connection cleanup
Using only clean data
Swappiness
Prod / Perf
High volume (100+%) long duration, multiple locations, inside and outside firewall.
Resource intensive
‘All hands on deck testing’ – costly
3 pages of defects – too many to find in a 1 5 week window as there are always blockers and recoding needed
Load balancing (active / active, device, VIP)
Firewall performance issues
SAN performance issues
Socket / connection issues
Bandwidth limitations
# Of servers required
CDN issues
Geographic limitations
Backups causing issues
Clustering issues / failover issues
Issues with shared services (AD, SSO)
Disk performance issues
Data replication performance issues
Performance impact of scheduled tasks
Load balancing and persistence
Firmware / BIOS issues
Proxy limitations
Proxy / edge caching / FE caching
DDOS / IDS configuration issues
ISP limitations
Noisy neighbors - virtualization
Bad server in farm
Switch / link configuration
PDU / power / overheating issues
OS limitation / tuning
Disk space issues
SAN caching
Resources: load generators, test durations, outage windows, bandwidth, infrastructure footprint, war room environment, use cases, integrations
Speed: scripting, use case complexity, components included in tests, automation, isolation, code focus
Back end API performance is tuned prior to the release of any mobile app or front-end!
Dev has time to iterate once perf defects are found.
What worked?
App was developed with testability in mind
Testing earlier in the development of the mobile app
Back end testing was completed prior to release any front end!
Isolation of back end and front end
Fast feedback for bad builds (functional, errors, performance)
Build validation with automation led to faster iterations
Reusability of test cases between teams and environments
Baseline infrastructure; then focus of code changes
Create experiments to isolate defect targets
Document what defects were caught in each environment; refine
Using production-like data sets as early as possible!
Build test cases as close to dev as possible
Docker Compose YML: https://github.com/sandbreak80/myapp
NeoLoad project for KonaKart (localhost): https://github.com/sandbreak80/konakart
Jenkins user will need access to modify these files
Docker Hub for mysql access via adminer: https://hub.docker.com/r/sandbreak80/adminer/
Docker Hub for konakart: https://hub.docker.com/r/sandbreak80/docker_konakart/
Clone docker-compose file
mkdir myapp
cd myapp
git clone https://github.com/sandbreak80/myapp.git
Pull, build, and start docker containers
sudo docker-compose start
Connect to the KonaKart instance
sudo docker exec -i -t konakart /bin/bash
Install VIM: apt-get install vim
Edit the tomcat environment file
vi /usr/local/konakart/bin/setenv.sh
export CATALINA_OPTS="$CATALINA_OPTS -javaagent:/home/appdynamics/java_agent/javaagent.jar
-Dappdynamics.controller.hostName=your_controller_name_or_ip
-Dappdynamics.controller.port=8090
-Dappdynamics.agent.applicationName=KonaKart
-Dappdynamics.agent.tierName=Kona_Server
-Dappdynamics.agent.nodeName=Node1
-Dappdynamics.agent.accountName=customer1
-Dappdynamics.agent.accountAccessKey=your_access_key"
BASIC authentication is used in AppDynamics to create custom events and time ranges in the next two slides
As a reference, the AppDynamics REST API is documented here - https://docs.appdynamics.com/display/PRO42/Using+the+Controller+APIs.
The first call authenticates with the AppDynamics controller, and stores the authentication cookie into /tmp/session.dat on the Jenkins Server. Note that we’re using a basic authentication header instead of directly exposing our username and password.
There are a number of utilities you can leverage to base64 encode a string, like https://www.base64encode.org/.
The username / password format to encode is: <username>@<account name>:<password> and the @ symbol needs to be URI encoded.
By default, in single tenant controllers, the <account name> will always be customer1. So, to get our base64 authentication header we can encode - admin%40customer1:appdynamics – to get our authentication header
YWRtaW4lNDBjdXN0b21lcjE6YXBwZHluYW1pY3M=
***Note***
We need to URI encode our username and password string, which is why we use ‘%40’ instead of the ‘@’ character.