Pressure to deliver new features and functionality fast, often with technologies new to your development/operations team, means you need to be ever more vigilant in how users experience your services – 24×7. This deck reviews performance monitoring best practices and how to implement them.
5. 55 www.apicasystems.com
Mobile-Tablet Synthetic Monitoring
• The time spent per user with digital media on mobile in US daily in 2015 – 2.8 hours
• The total number of iOS app downloads in 2015 – 25 billions
• The total number of Android app downloads in 2015 – 50 billions
• The app category people spend time the most – Social Networking (29% of users)
• The age group that spends the most time on apps monthly – 18-24 (90.6 hrs on smartphone apps,
34.7 hrs. on tablet apps)
• The Top number of apps people use the most – 3 (78% of smartphone app users, 77% of tablet app
users)
• The major age group of uses that operate a smartphone with two hands – 55+ (34% of users)
6. 66 www.apicasystems.com
Monitoring Success Story
• Background:
– App released to Production
– New Sign-Up page
– Multiple Mule Services in the background
– Multiple Load Balancers
7. 77 www.apicasystems.com
Remedies & Recipes to Success
• Understanding the stack, completely.
• Spoke to the Developers to understand main components
of the application stack.
• Did an assessment of the current synthetic monitoring
infrastructure.
• Implemented Uptime checks on servers.
• Build specific user journey scenarios monitoring multiple
depended services.
At Apica we advise our clients on how to improve their monitoring framework for web application, mobile applications, and implement synthetic monitoring. We have worked my way up from support to noc to ops to tam, and now TPM. We’ll be covering Performance Monitoring Best Practices in this presentation.
Here is our Agenda for today, we’ll be covering various topics, the methods that have worked, some of the horror stories, and what we did to remedy them by applying different recipes. I’ll answer all the question in the last part of our webinar.
We’ve all seen some aspect of the image to your left, the infamous SDLC! What most people miss in the SDLC is the monitoring aspect. However, when should we really start thinking about monitoring? From my experience, (back this up) it should be done in design phase, not the development phase. The reason you want to do this in the design phase is because you want to account for how your users are going to use the product, that will give you an indication on how to synthetically monitor the site. For example, you have e-commerce site, your prospect customer comes to the site, search’s for the item, select’s the item and adds it to the cart, finally the customer goes to the and checks out, at which the customer is directed to a payment gateway. What you have here is a user journey! Studies have shown that 32% of consumers will start abandoning slow site between 1 to 5 secs. This can be reduced by small page sizes and speed improvements. Which should be considered in design, so when the developers start developing they have something to work towards and against. Monitoring implementation will help you realize how fast your site is and what your page size is. Take a look at amazon’s site on your right. They’re average response time is 8 secs, that’s with a full user journey. On an average their home page only takes 3.5 secs to load. That’s should be the goal to retain customers and conversions.
On the left you have your traditional APM tool which gives you some insight on your top 5 web transactions. This is a traditional bottom up approach, giving you the ability to drill down on the stack trace. Top-down approaches emphasize planning and a complete understanding of the application. Top-down requires that you reach a sufficient level of detail in the design phase. A top-down approach ensures you have fault-free system, application, at low response time. Risks of only implementing bottom-up approach is that modules may be coded without having a clear idea of how they link to other parts of the application. Monitoring was never included in the start of the conversation rather it was an after thought. Top-Down gives you the ability to start that conversation early in the development cycle. The picture on the right shows Top-down synthetic monitoring, all the domains called and 10 slowest urls, which gives you an indication of where you need to concentrate your effort. Remember every click is revenue on the table.
What this numbers represent is the growth of mobile application usage in US and around the world. We see that as human attention span is decreasing, the ability to get things done on tap of our finger is increasing more and more. One bad experience with the app and customer finds an alternative app to accomplish the same with. Moreover, the time spent on mobile application vs mobile web is 89% to 11%. So what does this all mean to monitoring? If you don’t have the right monitoring in place how will you know if your app is functioning as it should be? Let me ask you what sort of mobile application monitoring do you have in place currently? Some of the monitoring that I have seen be in place is, user-agent monitoring, which all you are doing is manipulating a user-agent in the browser, do you think that’s accurate? I believe not because it doesn’t really track user experience. Think of it as a sandbox environment, it’s good for a test but to apply that logic in continuous monitoring isn’t the best practice. What I have seen work is a Tool like ZebraTester, which sniffs traffic from the device to the backend. We see what calls are being made, if the images are being rendered. This can be recorded and then set as a base for monitoring, not only will you know the functionality, also, what the response time for the application is.
Weight Watchers recently updated their site with a new sign-up page, however, in the backend they changed from their legacy stuff to nodejs/angularjs. However, they did not have much monitoring in place when they released the sign-up page. Moreover, the new sign up page had multiple mule services in the stack that associate with the new sign-up page, such as, meeting finder, geo-location appointment, plan services. Additionally, WW also released an app in iOS and Android, but when users with subscription would try to log in they were redirected to purchasing a new subscription. In the world where ratings really matter, their application really took a hit with bad ratings. Soon after, WW contacted us, Apica, to help them resolve the issue. What WW wanted to achieve is monitor every service to see if there are any breaks in the user experience. Bring the app rating up again. Help determine where the breaks were happening by using both an APM tool and an SM tool. So how did Apica help them achieve such results?
You can see here exactly what we did to achieve these results.