The Evolution of Synthetic Transaction Monitoring
In the early days of application performance monitoring, synthetic transaction monitoring was based on protocol level emulation. For example, HTTP protocol’s GET method was implemented by monitoring agents and used to determine how fast web sites responded, and whether they were available or not. Likewise, ICMP echo (commonly called “ping”) was used to assess whether a server was reachable or not. This approach can be extended to other applications as well. For example, emulation of SMTP and POP3 protocols can be used to determine the performance of email applications. FTP, SQL, IMAP, ICA, and other protocols and applications that support them can also be monitored with this approach.
While protocol level emulation is useful for determining if an application is up or not, it does not assess all aspects of application performance. For example, real applications are session oriented and involve multiple interactions. To truly measure performance as seen by an end user, synthetic monitoring needs to be:
- Session-oriented (i.e., includes login and logout)
- Able to simulate multiple steps when accessing an application (e.g., logging in, browsing a catalog, adding an item to a cart, and logging out),
- Capable of using the very same clients that users make use of (e.g., web browsers, Citrix receivers, etc.)
This is where client emulators come in.
Synthetic Transaction Monitoring is More Than Protocol Emulation
A client emulator includes a recorder that can be used to record a sequence of interactions with an application. The recording is converted into a script that is then played back periodically. During the playback, the availability and response times for each step of the user interaction are tracked, thereby enabling IT managers to pinpoint when a slowdown is detected, and which step is responsible for the slowdown.
Beyond just checking if a response is received and whether it is received on time for each step, client emulators also need to validate the response. For web-based applications, the emulator should verify the HTML response and compare it with the tags available during the recording. For non-browser-based client applications, it is not possible to do a textual comparison of the responses. Emulators for such applications need to embed image capture and recognition technology. Two of eG Innovations’ technology partners provide solutions in this area – Tevron and Itexis.
The drawback with client emulation is the need to manually record the sessions that need to be emulated. Creating the script to simulate multiple steps is not very difficult, but the challenge lies in making sure that all different failure modes of the client application are handled (e.g., exceptions, popups, warnings, etc.), so that a single failure does not disrupt the emulation.
Client emulators have broad applicability – they can be used for off-the-shelf, packaged applications as well as for custom applications. The degree of effort involved in setting up the emulation is the same in both cases. Recently, application-specific emulators have emerged that are almost plug and play. The Citrix Logon Simulator introduced in eG Enterprise 6.2 is an example of an application-specific emulator. Such solutions do not require recording or script creation. Making use of the fact that packaged applications have a pre-defined login form and a click-through format, these solutions offer pre-built solutions that work out of the box with very little configuration and are therefore are very simple to deploy.
Synthetic Monitoring vs. Stress Testing
Synthetic monitoring is often confused with stress testing because they appear to be similar. However, there are key differences between these technologies.
- Synthetic monitoring emulates a single user to check how the target application is performing. Availability and response times are key metrics collected.
- Synthetic monitoring is often deployed in production and its goal is to minimize any overhead on the target application.
On the other hand, stress testing is deployed in staging/test environments. The goal of stress testing is to understand the performance and capacity limits of the target application. Therefore, stress testing simulates multiple user sessions to an application and measures the performance of the application as the stress test load increases. The result of stress testing indicates the max number of concurrent user sessions that can be supported by the existing application configuration.
Key Use Cases for Synthetic Transaction Monitoring
Some of the key situations where synthetic transaction monitoring is useful:
- To understand the performance of an application at any time, even when there is no real user load
- To obtain a consistent benchmark of the availability and performance of an application
- To measure the performance of an application before and after an upgrade, or before and after a migration (e.g., physical to virtual, on premises to cloud, from one operating system to another, etc.)
- To assess the performance of an application from multiple geographies (e.g., where the user population is)
- To ensure that new functionality or a new workflow added to an application is working as expected
- As an SLA benchmark for management
Learn about synthetic transaction monitoring with eG Enterprise >
eG Enterprise is an Observability solution for Modern IT. Monitor digital workspaces,
web applications, SaaS services, cloud and containers from a single pane of glass.
