#ATAGTR2023 Speaker

Monitoring Web Performance: Leveraging Grafana and Selenium for Real-Time Issue Alerts

Problem Statement:

In the modern world ensuring optimal performance is a key factor for the success of the software. Using the functional automation scripts can we find out the performance issue in our application earlier in the Software development cycle ?

Objective:

The primary objective is to demonstrate how we can achieve the early alerts of performance issue in our application with the help of the Selenium functional test and Grafana

Approach:

We will create a function of all the selenium actions for e.g click,enterText,Drag,Waits then create a jar and store it in nexus repo which we can refer to in all our projects. So now in all our projects we have to just import the jars from the nexus.

Let us take the example of Amazon.It will be having multiple microservice such as Ecommerce,Payment etc.

For each microservice we can import the jar of selenium action from the nexus repo into the respective Automation repository. Due to this approach we don’t need to reimplement the selenium action like click in each repository rather we can call this action in our scripts and just pass the suitable data(Locators, Value to be entered etc).

Selenium action methods are implemented in such a way that before performing any actions it will have an implementation of explicit wait recording the time selenium waits for the element to perform action. Explicit wait of selenium does polling in regular intervals until the condition is satisfied or timeout occurs. This methods will calculate the time, web page name, Locator of the element, current URL, Business name and Module Name of the element and generate a log with this information for each action performed on an element.

For e.g If User has to Checkout a product

click method from jar will be called into scripts then the log will be generated for element Checkout button as follow

Web Page: Checkout,Business name of element:Check Out Button,Locator://button[@text()=’Button”],Locator Strategy: xpath, Time required for element to be interactable=100 ms, Current url:https://amazon.in/product/checkout,Module Name:Shopping Cart

After the execution of the scripts the logs are pushed into Jenkins from where we feed these logs into the Prometheus database. Prometheus records metrics in a time series database built using an HTTP pull model, with flexible queries and real-time alerting.

Grafana is an open source tool which helps to visualize the data in the form of charts, graphs and created alerts. Then we can visualize the data in prometheus in the form of a graph using Grafana

Functional automation scripts are run on daily basis or at least on commit basis. So with these runs we can find out the performance issue in elements earlier and can easily debug the issue as we are aware due to which code commit the issue occurred.

Note: Graph similar to below kind will be generated in Grafana

In the above graph we can notice that Login button response time has increased twice on 10th June 2023 from 8th June 2023. So there is a performance issue in the login button which can be related to the code committed on 9th June 2023.Developer can narrow down their debug area and can fix the issue at a faster pace. With the help of the Functional automation scripts we can create alerts to performance issue.

Future Scope:

If we have kept a threshold of 1 sec for the element to load but our element loaded on day 1 within 100ms but on day 2 it took 200 MS, technically it is within the threshold of 1 sec but the performance has degraded by 100%. So we should also get alerts of change on a daily basis.This can reduce the turnaround time to fix the performance issue because we get alerts the next day after code related to the issue is committed.

Conclusion: This is not an alternative to performance testing. With the help of this strategy we can get basic performance issues while running our functional selenium suite. Since mostly the functional suites are run on a daily basis we can have a good turnaround time for fixing performance issues as we would have a better idea which piece of code committed yesterday could have triggered performance degradation