Tracking APRDP project
a. The solution provides the following:
i. Visibility of all users and measure user experience – frustrated, tolerating or satisfied as per the SLA criterion defined by yourself.
ii. Auto-detection of all visits, click paths, page actions and errors.
iii. Capture of all business transactions 24/7, end to end, from browser to database and back on production server.
iv. Provide actionable information to development and testing teams on performance issues in
the application during the test cycles.
b. Performance trends and analysis
i. Provide visibility on
1. User Experience
a. 100% Transaction capture for the real time user b. Visit
c. Client Errors
d. User actions and how the transaction is getting executed between the tiers and time spent on each tier
e. Status of users whether they are satisfied or frustrated
f. State of user from the respective geography
2. Diagnose performance
a. Deep diagnostic for application to code level to identify the slowness or the errors/exceptions received by the user
b. Database performance for the respective application (execution time,
failure rate, exceptions, round trip, no of execution, slows running queries etc.)
c. Web Services performance
d. Method performance
3. Diagnose runtime
a. Health portrait of the infrastructure wrt. CPU, Memory, Disk, N/W
b. CPU Sampling
d. Memory Utilization
e. Processes impacting the application and infrastructure
4. Diagnose Browser
a. Browser Performance
b. Java script errors
5. Functional health of application
6. Response time
c. Performance analysis
i. A more refined analysis of your end-users’ experience, segmented by multiple dimensions
including when there is no actual real user transaction
d. Deep dive diagnosis: We will provide the following:
i. Code level/ Query level error identification by drill down.
ii. Technology provides true distributed tracing across web, web server, Java, .NET and WebSphere, not a stitched together sub-trace per JVM/CLR, which is not able to relate a slow end-user response time measured on Tier1 with poor-performing database access
on Tier2. That is a key reason why the real smart agents need to reside in the collection and server technology.
iii. Technology also captures contextual information such as user session information, method arguments, return values, log messages, exception details, etc. This is important for
architects and developers to identify the true difference between a good and bad transaction.
iv. A single or a set of paths followed should be exported to a session and shared with your
colleagues or third-party providers. The exported session should include the full
transactional trace and all contextual data, it should also contain every system metric captured in the environment at the time of the transaction -- e.g., CPU, memory, application server metrics, etc.