5 Real Life Examples on why Mobile Web and Mobile Native Apps failed and Which Metrics would have shown the problem early on.
Using these metrics along your delivery chain allows you go get closer to full automated deployment pipeline but also making sure performance criteria is met
4. Some Examples from Real Life
300 Deployments / Year
10+ Deployments / Day
50-60 Deployments / Day
Every 11.6 seconds
5. More details on Amazon
Deploying every 11.6s
75% fewer outages since 2006
90% fewer outage minutes
~0.001% of deployments cause a problem
Instantaneous automatic rollback
6. The “War Room” – back then
'Houston, we have a problem‘
NASA Mission Control Center, Apollo 13, 1970
11. 1.3 Million iOS
Apps
$ 10 billion iOS
purchases
2013
1.4 million
Android Apps
$ 5 billion
Google Payout
within 1 year
12. Distance Calculation Issues
480km biking
in 1 hour!
Solution: Unit Test in
Live App reports Geo
Calc Problems
Finding: Only
happens on certain
Android versions
15. Slow Network – Bad Latency
Impact of Latency
and Bandwidth
16. Metrics: Crashes, Exceptions, # and
Status of 3rd Party Calls, Payload of
Web Service Calls
Dev: Build for Mobile
Test: Test on Mobile and Diff. Carriers
Ops: Monitor Mobile
19. Mobile Landing Page of Super Bowl Ad
434 Resources in total on that page:
230 JPEGs, 75 PNGs, 50 GIFs, …
Total size of ~ 20MB
20. m.store.com redirects to www.store.com
ALL CSS and JS files are
redirected to the www domain
This is a lot of time “wasted”
especially on high latency mobile
connections
21. Metrics: Load Time,
# Resources (Images, …),
# HTTP 3xx, 4xx, 5xx
Dev: Build for Mobile
Test: Test on Mobile
Ops: Monitor Mobile
31. Using Hibernate results in 4k+ SQL
Statements to display 3 items!
Hibernate Executes
4k+ Statements
Individual Execution
VERY FAST
But Total SUM
takes 6s
33. Using Telerik Controls Results in 9s for
Data-Binding of UI Controls
#1: Slow Stored Procedure
Depending on Request execution
time of this SP varies between 1 and
7.5s
#2: 240! Similar SQL Statements
Most of these 240! Statements are not
prepared and just differ in things like Column
Names
34. Metrics: # Total SQLs
# SQLs / Web Request
# Same SQLs / Request
Transferred Rows
Dev: “Learn” Frameworks
Test: With realistic Data
42. # of Requests / User
# of Log Messages
# of Crashes
Page Size
# Objects In Cache
# Objects Allocated
Cache Hit Ratio
# of Images
# HTTP 3xx, 4xx
# of SQLs
Availability # SQLs per Request
45. How about this idea?
Test Framework Results Architectural Data
Build # Test Case Status # SQL # Excep CPU
12 0 120ms
3 1 68ms
Build 17 testPurchase OK
testSearch OK
Build 18 testPurchase FAILED
testSearch OK
Build 19 testPurchase OK
testSearch OK
Build 20 testPurchase OK
testSearch OK
12 0 120ms
3 1 68ms
12 5 60ms
3 1 68ms
75 0 230ms
3 1 68ms
We identified a regresesion
Problem solved
Let’s look behind the scenes
Exceptions probably reason for
failed tests
Problem fixed but now we have an
architectural regression
Now we have the functional and
architectural confidence
46. How? Performance Focus in Test Automation
Analyzing All Unit /
Performance Tests
Analyze Perf
Metrics
Identify
Regressions
50. Want MORE of these and more details?
http://blog.dynatrace.com
51. FREE Products & More Info
• Dynatrace Free Trial – http://bit.ly/dtrial
– Full End-to-End Visibility in your Java, .NET, PHP Apps
– Sign up for a 30 Days (option for Lifetime) Free Trial on
http://bit.ly/atd2014challenge
• Our Blog: http://blog.dynatrace.com
• My contact: @grabnerandi, agrabner@dynatrace.com
63. Result: Out of Memory Crashes!!
Still crashes
Fixed Version Deployed Problem fixed!
64. Metrics: Heap Size,
# Objects Allocated,
# Objects in Cache
Cache Hit Ratio
Test: With realistic Data
Editor's Notes
Why do we need metrics? What do they allow us to do?
When we look at the results of your Testing Framework from Build over Build we can easily spot functional regressions. In our example we see that testPurchase fails in Build 18. We notify the developer, problem gets fixed and with Build 19 we are back to functional correctness.
Looking behind the scenes
The problem is that Functional Testing only verifies the functionality to the caller of the tested function. Using dynaTrace we are able to analyze the internals of the tested code. We analyze metrics such as Number of Executed SQL Statements, Number of Exceptions thrown, Time spent on CPU, Memory Consumption, Number of Remoting Calls, Transfered Bytes, …
In Build 18 we can see a nice correlation of Exceptions to the failed functional test. We can assume that one of these exceptions caused the problem. For a developer it would be very helpful to get exception information which helps to quickly identify the root cause of the problem and solve it faster.
In Build 19 the Testing Framework indicates ALL GREEN. When we look behind the scenes we see that we have a big jump in SQL Statements as well as CPU Usage. What just happened? The Developer fixed the functional problem but introduced an architectural regression. This needs to be looked into – otherwise this change will have negative impact on the application once tested under load
In Build 20 all these problems are fixed. We are still meeting our functional goals and are back to acceptable number of SQL Statements, Exceptions, CPU Usage, …
Web Architectural Metrics
# of JS Files, # of CSS, # of redirects
Size of Images