Geplaatst: 25 August 2022

Frequently companies ask for our seven-day trial – to try out the capabilities of the ADF Performance Monitor on their ADF application. This trial is meant only for companies that are interested in purchasing an ADFPM license. Often, we have had trials where everything that can go wrong went wrong. With disappointing results. In this blog I will describe what frequently went wrong and how to prevent it.

(Lees meer..)

Geplaatst: 21 June 2022

We are happy to announce that we have a new whitepaper on the ADF Performance Monitor. This blog publishes a new whitepaper that gives more information about the architecture, features and implementation of the ADF Performance Monitor. It is updated with the many features of our new major version 9.5. Recently we also made also a quick introduction video on the product.

(Lees meer..)

Geplaatst: 29 March 2022

We have a new introduction video of the ADF Performance Monitor (3:40 minutes) ! It gives a quick introduction on the product.

Geplaatst: 2 December 2021

Last week we had a new version of the ADF Performance Monitor available – version 9.5.

In this blog I will write on one of the new features; thread wait and thread blocked time of requests. Sometimes we cannot explain a poor performance, disruptions, hiccups. If we dive into the world of Java threads, we often can. It can be that some threads were waiting on some resources or were being blocked. Or if there was JVM garbage collection during the request (that froze all threads). We can see all this now in the monitor for each HTTP request in detail. We have much more insight into time gaps that were sometimes hard to explain before.
(Lees meer..)

Geplaatst: 29 September 2021

We have again a major new version of the ADF Performance Monitor available – version 9.5 ! We have added many new valuable features and improvements. Many overview screens have got a facelift and new charts. In several blogs I will write on them.

This blog is on one of those new features, automatic SLA and health KPI warnings. The monitor will automatically interpret the metrics and will show warnings if the ADF application is not meeting the configured SLA thresholds (KPIs). Or if configured JVM and system health thresholds are not met – like JVM garbage collection, JVM CPU load, system CPU load, OS memory, database, webservice, application server, network, and browser. From now on it will be even more fast and simple to interpret the metrics. You do not have to be a performance expert/engineer, the monitor will already show the (type of) problems!
(Lees meer..)

Geplaatst: 15 July 2020

Last week I blogged in part 1 on our major new version of the ADF Performance Monitor – version 9.0. It was about monitoring the CPU load of the JVM process and of the whole underlying operating system. It was also about the total used and free physical (RAM) memory of the whole system, and the Linux load averages that provides an excellent view on the system load.

This blog (part 2) describes more new features. The CPU execution time of individual HTTP requests and click actions is now available. “What request/click action in the application is responsible for burning that CPU ? ” That question you can now answer with the monitor. The monitor gives a clear indication how expensive certain HTTP requests and click actions are in terms of CPU cost. Further we added browser (user-agent) metrics for each request. We also improved the ADF callstacks (snapshot that gives visibility into which ADF method caused other methods to execute, organized by the sequence of their execution and execution times).
(Lees meer..)

Geplaatst: 8 July 2020

I’m very excited to announce that we have a major new version of the ADF Performance Monitor – version 9.0 !

We have added many valuable new features; new metrics that can detect and help explain poor performance, disruptions, hiccups, and help troubleshooting ADF applications. Like operating system metrics: the CPU usage of the ADF application, the total CPU usage of the whole underlying operating system, the total used and free physical (RAM) memory of the whole system, and the Linux load averages. A high CPU usage rate and memory usage may indicate a poorly tuned or designed application. Optimizing the application can lower CPU utilization. Generic APM tools have these kinds of metrics too in some way, but the combination of system metrics with ADF specific metrics of the ADF Performance Monitor makes it even more possible to relate performance problems.

Another reason to pay attention to system metrics is that nowadays more and more applications are deployed on the cloud. Very likely there will be shared virtual machines and resources (CPU, memory, network). Applications and processes could influence each other if frequently other processes have a very high usage of the available CPU or memory capacity.

This blog (part 1) describes the first part of these new features. Part 2 describes the CPU execution time of individual HTTP requests and click actions. It answers the question: “What request/click action in the application is responsible for burning that CPU ? (Lees meer..)

Geplaatst: 2 April 2020

Application errors are often hard to retrieve, or take a lot of time to resolve. When you are suffering from errors, and have a lack of clarity when errors happen, you would like to have useful error diagnostics for analysis.

The ADF Performance Monitor automatically captures detailed diagnostics for each and every error/exception occurrence. You can view your errors to see the highest priority issues your team should focus on. This blog shows the renewed error overview of our newest version of the ADF Performance Monitor – with real production metrics.

(Lees meer..)

Geplaatst: 19 March 2019

Recently I was analyzing and troubleshooting the performance of an ADF application. Much was already improved before I came. Due to a very recent new hardware/infrastructure environment, the server and database process time was nearly 50% faster after migration. In this blog I want to show you the impact it had on the total server process time of HTTP requests. Such a sudden improvement is visible in the ADF Performance Monitor in a glance, and in Week and Month trend analysis overviews. Maybe you need to investigate your hardware/infrastructure as well ,and consider an upgrade; if your hardware/infrastructure is relatively old, if your machines are full, or if virtualization software is not implemented efficiently.

(Lees meer..)

Geplaatst: 7 January 2019

Intris is the leading Belgian provider of freight forwarding, customs and warehousing management solutions. Headquartered in Antwerp, Intris provides its integrated software and cloud-based solutions to logistics services providers in Belgium and the Netherlands.

Ben Rombouts is Chief Operating Officer at Intris. Recently he has written a detailed review on the ADF Performance Monitor – a tool Intris uses for monitoring the performance of their large Oracle ADF application.

For what and how the ADF Performance Monitor is used

The ADF Performance Monitor is used within our development team as an extra quality check when building new functionalities. After developing the code, the developers carry out their test scenarios and check the results based on the metrics generated by the tool. With this, non-performing queries are instantly removed, and we get a better insight where we need to work on additional performance improvements.

Since our standard application consists of several modules, our customers do not use all functionalities in the same way, or equally frequently. That is why the tool is also used for many LIVE customers in production, considering the following parameters:

• Number of users
• Type of hardware that the application runs on
• Functionalities used by the customer

Our account managers use the data in different ways and base themselves mainly on the dashboard:

1 – Average Response Time

General information about the average response time to give a correct indication of the performance during steering committee meetings. Previously there was much more subjectivity here (type “Every action takes seconds in your application”). This has ensured that these discussions are over now and that we can focus on the real issues.

2 – Errors that are reported

These are split into effective technical errors and errors that are of a more functional nature. This also gives a good impression of the fact that some users make the same mistakes and so there is a need for additional training. The technical errors are made into issues that are passed on to the development team and, depending on the importance, included in new releases.

3 – Discussions about what the performance issues are related to

Since we enable the tool at different clients on different platforms, we can also compare this over the environments. For example, we can see that the database time is always a constant, but that there are variations in network and browser time. This can then be addressed to the system administrator of the customer.

4 – Click Actions

From the ADF Click Actions overview we also get very useful information about the specific use of our application:

• which actions last the longest?
• which actions are carried out most frequently?
• which users experience the most problems?

This makes it much more convenient to focus on the real problems and clearly report to the customer why we focus on certain matters, and why we give other things a lower priority.

5 – Addressing Technical Problems

At frequent intervals we also try to go through several environments with a senior developer to check more technical problems that can be improved in the application. Sometimes, for example, if we notice things at a customer where certain actions take longer and longer, so there is a problem in the queries. Other customers do not have any problems with this now, for example because they have less data, but in the future, they will not run into this type of problem because we can take them pro-actively from the application.

How the ADF Performance Monitor helped

1 – View things in an objective way

The tool mainly helped us to view things in an objective way. For example, some actions in the application can take quite a long time for an end-user but are only executed 2-3 times a week. If we put this in perspective in relation to actions that are carried out 100 times a day, it is already much clearer where you need to focus.

2 – Quickly Troubleshoot problems

When customers report certain errors via our support, we can consult logging much faster because we can see very quickly which actions were performed by which user at that specific moment.

3 – ADFBC Memory Overview

From the overview ADFBC memory overview you can quickly find out where there are any problems in queries. These are issues that are sometimes not noticed by customers, but where you can prevent problems in a proactive way.

4 – Objective Insight in Use of the Application

The tool also gave us a much clearer and more objective insight into the use of the application. This is rather a ‘side effect’ of using the tool, but it gives a quick and clear overview to prepare steering committees for reporting.

How the ADF Performance Monitor saved much time (and money)

To express this in time/money is quite difficult, but you can safely say that you can win a lot of time in the following areas:

• 50-60% time savings for researching performance-related issues. Because developers really get a very low-level insight into the framework, it is much easier to tackle performance issues and generate large performance profits with limited actions
• 5-10% time savings by incorporating extra quality checks in development cycle (time gains come from avoiding hotfixes)
• 20-30% time saving when investigating errors reported by customers
• Great time gain during steering committees to keep the subjectivity out of the discussions so that there can be focused on the actions that really matter to end users. For example, a manager can complain that he does a certain action 2 or 3 times a week which takes him about 5 minutes per action. If you put a workload of 1 day in improving this specific action you can decrease the time to 2 minutes, which is a 60% time gain for this specific action. This will save 6-9 minutes each week, but just for 1 person. Compare this to an action that 20 end users are executing each day for more than 100 times. They don’t complain about it, but with the same effort of 1 day workload we can improve this action with “only” 2 seconds. This will gain you more than 20.000 seconds or 333 minutes each week!! In this way you can put things in a broader context and convince customers where they will really gain time.

Read all our customer reviews on our reviews page.