The primary problem with mobile app performance monitoring is that mobile empowerment creates not so much totally different problems, but totally different risks. That increases the chances of having to address issues that defeat the productivity gains that mobility is supposed to provide.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Some of these differences arise from the fact that mobile connectivity is significantly less reliable than wired connectivity, so software architects are confronting a level of network problems not seen since the age of analog modems. Other differences arise from the fact that mobile applications run differently because they're designed to be highly tactical in their support of workers.
Accommodating these differences, ironically, starts by "harnessing what's the same." It then moves to finding the right information to supplement and ends with ensuring the security and accuracy of your mobile app performance monitoring solution.
Everyone knows that "monitoring" in the application sense means measuring availability and quality of experience (QoE). The former measures the time when the application can be accessed; the latter is largely a matter of response time. Both parameters are measured today, and a savvy architect or planner will start with how these factors are monitored and look to adapt them to the special demands of mobile app performance monitoring.
The most secure mobile-side monitoring strategies are those that ride on existing interfaces and make use of the application components already on the device.
Response time is the easiest thing to monitor. In most cases, it's best to assume that response time will be measured from the application side. Historically, it's measured from the time the worker sends the message to the time the worker receives the response. There's a temptation to start modernizing monitoring for mobile users by attempting to get data from the mobile device, but that's probably not the right answer.
Experience shows that, in most cases, mobile network delay isn't significantly larger than with wired connectivity, so the device-to-data-center connection probably doesn't contribute much to variability in response time. The real issue in dealing with response time in mobile app performance management is the introduction of more complex workflows and customized presentation of information. In many cases, these are accommodated by adding front-end processes to current applications; in most cases, these current applications are where response time is measured. That means front-end tasks aren't accounted for, and response-time data will be misleading.
Be sure to measure response time from the time the first application component is touched to the point where the last component in the workflow releases the data to the mobile connection (some people call this a "first touch to last touch" measurement). Normally, this won't require a change in how response time data is gathered, just where those mechanisms are applied.
Measuring availability: The complex side of mobile app monitoring
Measuring availability is where mobile application monitoring becomes complicated. Traditional applications typically serve branch sites, and their connections are monitored at the site level, so application monitoring would be responsible only for detection availability problems with the actual application components, not with the connection.
In mobile app performance monitoring, the connection is much more likely to be the problem, and because that connection is unique to each mobile worker, it's difficult to assess availability by looking at the network as a whole. In addition, how does a host site know a mobile device is experiencing availability problems if that device can't contact the host?
The obvious solution to that quandary is some periodic health check on the connection, and also perhaps on the device-resident components used to complete the mobile app. This technique has been used for decades in networking, and it's often called a keep-alive message because it's generated during idle periods to advertise that the connection is still available.
The first problem with that approach is that to achieve any precision in availability measurement, the keep-alive messages have to be fairly frequent. That eats up mobile capacity and increases the load on both the device and the host application receiving the messages. Another problem: In many cases where connection is lost, the worker isn't trying to use the device, and so availability doesn't suffer. Most users start their availability planning with the keep-alive strategy -- and most abandon it for those reasons.
A better approach to mobile availability monitoring is to have an agent process on the device count the number and length of periods when a connection was attempted and couldn't be completed. That data is then reported back to the mobile app performance monitoring platform when the device is next able to connect. This, in turn, provides accurate availability data, though that data is only available when a connection can finally be made.
True, some enterprises might consider a delay between the reporting of an availability problem an issue. But remember that there's likely little that a company could do to remedy mobile-worker connectivity issues.
If it's determined that a keep-alive is appropriate, consider having the application contact the device periodically rather than the other way around. That can present some issues in design, given that in most cases, mobile devices don't have a persistent address. But it's possible to accommodate device-addressing issues. Some analysis of the way addresses change through the course of a worker's day of usage would be helpful before undertaking anything here.
Mobile APM: Consider security and compliance
The final point on mobile app performance monitoring is remembering that anything that involves device cooperation in the monitoring process could generate security and compliance issues. The general rule here: Risks are normally related to the extent to which an app can alter device memory or present interfaces through which the device can be contacted.
Generalized agent components, even those intended to add security or compliance features, also add vulnerability because these agents are typically trusted implicitly by others and, in many cases, extending their mission creates holes in security. The most secure mobile-side monitoring strategies are those that ride on existing interfaces and make use of the application components already on the device.
Mobile is different, and in nearly every sense, it's also less available and predictable than traditional network connections are. Beware of trying to get more data than you need to drive your own remedial processes. In some cases, mobile application availability and QoE issues have to be accepted as the price of better empowerment strategies -- and planned for rather than fixed.