How a Health-check helped Dedicon fixing an application issue

Dedicon is specialized in making (school)books, papers, magazines, sheet music and other forms of information accessible to people with a reading disability. They do that through streaming services. At the end of 2016 a platform-migration took place. Afterwards there were complaints: the system did not work anymore, or it was too slow.

Access to the streaming service was given through several channels: mobile telephones, tablets and pc’s. On top of that, clients used different browsers, internet service providers and network providers. A Health-check based on the solutions from Performance Vision, the application components between transmitter and receiver was analyzed:

The health-check at Dedicon

picture 1 – the test set-up

Throughout the day more than 3000 clients were monitored, spread over 1 app, a regular browser such as Firefox or Safari, and a Webbox. These users initiated up to 30.000 http transactions (picture 2).

picture 2 – amount of http transactions spread through the day

Many of the 30.000 transactions resulted in errors (picture 3). As you can see, most malfunctions are caused by 4xx errors. The user starts a transaction that the server basically does not understand. Possibly because the requested content is not available at that particular moment (a 404 error), or because a user is not granted access to the content (a 401 or 403 error).

picture 3 – amount of transactions resulting in errors

Additional analysis shows that the most common error is caused by the original book cover not being accessible. There are problems while scrolling forward or backward within the book, or when clients try to download MP3-files that are not available.

With one click PerformanceVision shows the details behind each of the error situations. Picture 4 shows you an example, with from left to right:

  • The name of the application as set in the system.
  • The different parts of the app or the players.
  • The used http method (in this example only GET was used).
  • The http status after request (in this example all 404 errors).
  • The URL used for the request.

picture 4 – results of http transactions conducted by the different user agents

Most common errors

The Android version of the app appeared to have the errors. It was not possible to trace back the errors to a specific machine or Android version.

Based on these results Dedicon did extra research on the app’s functioning. It showed that the so called event listeners weren’t always up-to-date. When playing forward or backward the remaining playing time was not shown correctly. This caused problems in synchronising with the server. In an updated version of the “Daisylezer” app the problem was tackled. After these results, the app was made available through Google Play Store and the Apple App Store.

Time of the project

The project was done in ten weeks time; from the start with the detailed design of the test situation until the final results of the new improved version.

Fill in the form and learn what we did and how we did it.

The long, technical version is available here (in Dutch only).