I am currently facing an issue monitoring a web application using AJAX technology.
To browse this application, the users need to login and then they can browse the AJAX application. In order to see all the action from the users in the DCRUM platform 12.1, I needed to add the content type "application/json". But I still have an issue with the statistics.
Sometimes, for the login page there are all the components of that page but also for the next pages. The load time of this login page is wrong because that also takes into account the browsing of the users.
The question is : how remove these components of the login pages?
Thank you for your answer.
Thank you for your answer.
This solution was proposed to the Customer, but they rejected it this reason:
-the end of page component could change with the future versions of the monitored application
This is why it is impossible to use that and we need to use another configuration.
So what do they consider a page load?
Is that when the user has something on the screen or when "everything" is loaded?
To measure something that is dynamic, you need to identify what is the start and the end in the stream of data, else you will continue to have different responses due to what people click on.
For the customer, a page load is when a user does an action and the page is loaded.
The propostion you made is good but the Customer doesn't want to configure a specific "End of page component", this can change with time.
Do you have any option in the configuration to monitor this application?
When you define a certain url or url group (with regex) as manually defined url, it will never be attached to any page and always compose a standalone component. This is the best approach to these ajax actions that are related to user input (e.g. tooltips, popups, etc). They will not be mapped to originating page but will be represented on reports individually. You can also set up some more accurate threshold for them as they typically are expected to be faster than full-blown pages.
Thank you for your explaination.
In our case, apparently there is only one URL that is related to real user actions.
The issue comes from the sub components of this URL who are attached to the login operation. May be there is a way to un attached them
Please note that the "url" which Pawel refers to is a virtual being - an operation name that the AMD reports. It includes any parameters you define as the unique identifiers of a user action - may be a name of a JSON parameter, a POST parameter value, whatever unique identifier determines the operation performed by the user (because there must be one - otherwise how would server know what to do?). If you define those parameters (or set auto-learnin of them), then for each of these values we will report "url" and that one will be unique and determine beginning of each action measured separately.
Thank you for your answer
For your information, the URL related to the user actions is already manually configured.
As I understood, for the resolution, the login URL also needs to be manually configured in order for the AMD to determine the end of this URL and so measures good operation time for it.
The configuration for the action URL needs to be optimize by adding specific JSON or POST parameter.
Is it correct?