Daily Status Report

Intended for use by technical developers, project leads as well as project managers and system administrators, the Status Report contains a complete breakdown of your application / server performance as well as specific slow running requests which need improvement.

Cut out the guesswork and focus where the real problems are!

Get detailed information about the requests, database activity, resource usage and even a breakdown of individual applications running. This report pinpoints specific issues and draws attention to slow running requests, inefficient JDBC calls etc. Action can then be taken to improve performance and increase the overall quality of your applications.

Overview of Daily Status Report

The daily status report allows you to quickly see vital statistics of the requests that have run in the last 24 hours. The arrows easily show if the change is positive, negative or neutral. For example, a red arrow pointing up (negative increase) could signal requests are taking longer to complete.

Each attribute also shows the amount of change as a percentage, the delta value, the actual value as well as the value for the previous day so you can better gauge the health of your application.


System Load Statistics


Reviewing the System Load Statistics on the left we can quickly see that the system is starved of CPU - as most of the time when the software polled the system it had over 90% CPU load. The next step would then be to find how why. Is uneccessary processing taking place, are you dealing with more data than you need to etc.? FusionAnalytics leads you into the metric data to find how long the requests where in the DB, how many requests have taken place, etc.

Looking at the Memory Usage graph we see a more normal looking graph - as most of the time when the software polled the application the memory usage was around 40-60%. This is optimal as the server is balanced. No further action would need to be taken.

After adding more CPU, you should continue to monitor the performance of the application to make sure that this does not negatively affect the memory usage.


Slowest Requests on Average


Reviewing the slowest request URL's you can determine how much time was spent on a specific page (request). Looking at the first URL listed in the screenshot, we see that it took 178 seconds or about 3 minutes for this request to run. In some cases, perhaps in a report script, this may be normal - but for a regular request which a user would wait for a response it would definitely be unnacceptable and requires attention.

In addition, this metric is incredibly useful for Shared Hosting providers/environments as it empowers you to pinpoint problem websites that could be slowing your other customers down.

Session Statistics

Here we can find out how many unique sessions were active during a day. From the data on the left we see that there were 9.658% fewer sessions - which means there were fewer people using the application. This could indicate a holiday, a day of the week trend (i.e. Sunday), or if it is a significant decrease, it could indicate a problem with the application.



Applications


The application metric gives you the top 5 slowest requests per application. This allows you to further pinpoint performance problems and helps you to know which scripts in the applications you can optimize to gain performance improvements.





Application Data Overview


FusionAnalytics allows you to create Applications should you be running multiple applications (e.g. with multiple URLs) from one CF server. This metric gives you an overview of the performance of all your applications being monitored. If there was a problem with your execution time, you could refer to this chart to locate which application/s appear to be causing the problem and therefore better focus your efforts on optimization.


Application JDBC Overview


Similar to the above section, the Application JDBC Overview lists data that is relevant to each application filter that has been configured. From the data in the example, we can see that no resource problems are caused by the DB.