Node.js Business Transactions Test

The responsiveness of a transaction is the key determinant of user experience with that transaction; if response time increases, user experience deteriorates. To make users happy, a Node.js business transaction should be rapidly processed by each of the Node.js nodes in its path. Processing bottlenecks on a single Node.js node can slowdown/stall an entire business transaction or can cause serious transaction errors. This in turn can badly scar the experience of users. To avoid this, administrators should promptly identify slow/stalled/errored transactions, isolate the Node.js node on which the slowness/error occurred, and uncover what caused the aberration on that node – is it owing to SQL queries executed by the node? or is it because of external calls – e.g., async calls, SAP JCO calls, HTTP calls, etc. - made by that node? The Node.js Business Transactions test helps with this!

This test runs on a BTM-enabled Node.js node in an IT infrastructure, tracks all the transaction requests received by that Node.js node, and groups requests based on user-configured pattern specifications. For each transaction pattern, the test then computes and reports the average time taken by that Node.js node to respond to the transaction requests of that pattern. In the process, the test identifies the slow/stalled transactions of that pattern, and reports the count of such transactions and their responsiveness. Detailed diagnostics provided by the test accurately pinpoint the exact transaction URLs that are slow/stalled, the total round-trip time of each transaction, and also indicate when such transaction requests were received by that node. The slowest transaction in the group can thus be identified.

Moreover, to enable administrators to figure out if the slowness can be attributed to a bottleneck in SQL query processing, the test also reports the average time the transactions of each pattern took to execute SQL queries. If a majority of the queries are slow, then the test will instantly capture the same and notify administrators.

Additionally, the test promptly alerts administrators to error transactions of each pattern. To know which are the error transactions, the detailed diagnosis capability of the test can be used.

This way, the test effortlessly measures the performance of each transaction to a Node.js node, highlights transactions that are under-performing, and takes administrators close to the root-cause of poor transaction performance.

Target of the Test : A BTM-enabled Node.js

Agent deploying the test : An internal/remote agent

Output of the test : One set of results for each grouped URL

Configurable parameters for the test
Parameter Description

Test Period

How often should the test be executed.

Host

The host for which this test is to be configured.

Port

The port at which the target Host listens to. By default, this is 3000.

Business Transaction Naming Rules

By default, this test automatically 'names' the business transactions that are monitored, based on the number of URL segments that are configured for monitoring against Max URL Segments. For instance, if the Max URL Segments parameter is set as 2,3, then the default naming policy will automatically name transactions to a retail banking web site as /banking/IMPS-fund-transfer, /banking/NEFT-fund-transfer, /banking/Services, and so on. In this case therefore, the static URL segment names become transaction names and are displayed as the descriptors of the test. If you want to use the default naming policy, then set the Business Transaction Naming Rules parameter to None.

Max URL Segments

  • This test groups transaction URLs based on the URL segments count configured for monitoring and reports aggregated response time metrics for every group. Using this parameter, you can specify the number of URL segments based on which the transactions are to be grouped.

    URL segments are the parts of a URL (after the base URL) or path delimited by slashes. So if you had the URL: http://www.eazykart.com/web/shopping/sportsgear/login, then http://www.eazykart.com will be the base URL or domain, /web will be the first URL segment, /shopping will be the second URL segment, and /sportsgear will be the third URL segment, and /login will be the fourth URL segment. By default, this parameter is set to 3. This default setting, when applied to the sample URL provided above, implies that the eG agent will aggregate response time metrics to all transaction URLs under /web/shopping/sportsgear. Note that the base URL or domain will not be considered when counting URL segments. This in turn means that, if the Node.js node receives transaction requests for the URLs such as http://www.eazykart.com/web/shopping/sportsgear/login, http://www.eazykart.com/web/shopping/sportsgear/jerseys, http://www.eazykart.com/web/shopping/sportsgear/shoes, http://www.eazykart.com/web/shopping/sportsgear/gloves, etc., then the eG agent will track the requests and responses for all these URLs, aggregate the results, and present the aggregated metrics for the descriptor /web/shopping/sportsgear. This way, the test will create different transaction groups based on each of the third-level URL segments – eg. /web/shopping/weddings, /web/shopping/holiday, /web/shopping/gifts etc. – and will report aggregated metrics for each group so created.

    If you want, you can override the default setting by providing a different URL segment number here. For instance, your specification can be just 2. In this case, for the URL http://www.eazykart.com/web/shopping/login.js, the test will report metrics for the descriptor web/shopping.

  • UserName / Business Context Configuration

    As part of detailed diagnosis, eG Node.js BTM displays two columns, namely - User Name and Business Context. By default, these two columns will not display any values. This has been done so that administrators can use these columns to display any additional information that they deem useful for troubleshooting transaction slowness. For instance, administrators can configure eG Enterprise to capture the name of the user who initiated each transaction and display the same in the User Name column for every transaction URL in the Detailed Diagnosis page. Likewise, administrators can also tweak eG Enterprise to capture and display information such as transaction ID, product ID etc,. against Business Context. Such custom information can also be captured for specific transaction URLs or URL patterns alone.

    If you do not want detailed diagnosis to report user name / business context, then set the UserName / Business Context Configuration parameter to None. On the other hand, to capture the user name and business context into detailed diagnosis, refer to Configuring User Name and Business Context.

    Excluded Patterns

    By default, this test does not track requests to the following URL patterns:

    *.ttf,*.otf,*.woff,*.woff2,*.eot,*.cff,*.afm,*.lwfn,*.ffil,*.fon,

    *.ttf, *.otf, *.woff, *.woff2, *.eot, *.cff, *.afm, *.lwfn, *.ffil, *.fon, *.pfm, *.pfb, *.std, *.pro, *.xsf, *.jpg, *.jpeg, *.jpe, *.jif, *.jfif, *.jfi, *.jp2, *.j2k, *.jpf, *.jpx, *.jpm, *.jxr, *.hdp, *.wdp, *.mj2, *.webp, *.gif, *.png, *.apng, *.mng, *.tiff, *.tif, *.xbm, *.bmp, *.dib, *.svg, *.svgz, *.mpg, *.mpeg, *.mpeg2, *.avi, *.wmv, *.mov, *.rm, *.ram, *.swf, *.flv, *.ogg, *.webm, *.mp4, *.ts, *.mid, *.midi, *.rm, *.ram, *.wma, *.aac, *.wav, *.ogg, *.mp3, *.mp4, *.css, *.js, *.ico, *.cur, *.avif,/egurkha*

    If required, you can remove one/more patterns from this default list, so that such patterns are monitored, or can append more patterns to this list in order to exclude them from monitoring.

    Method Execution Cutoff (MS)

    From the detailed diagnosis of slow/stalled/error transactions, you can drill down and perform deep execution analysis of a particular transaction. In this drill-down, the methods invoked by that slow/stalled/error transaction are listed in the order in which the transaction calls the methods. By configuring a Method Exec Cutoff, you can make sure that methods that have been executing for a duration greater the specified cutoff are alone listed when performing execution analysis. For instance, if you specify 5 here, then the Execution Analysis window for a slow/stalled/error transaction will list only those methods that have been executing for over 5 milliseconds. This way, you get to focus on only those methods that could have caused the slowness, without being distracted by inconsequential methods. By default, the value of this parameter is set to 250 ms.

    SQL Execution Cutoff (MS)

    Typically, from the detailed diagnosis of a slow/stalled/error transaction on a Node.js node, you can drill down to view the SQL queries (if any) executed by that transaction from that node and the execution time of each query. By configuring a SQL Execution Cutoff (MS), you can make sure that queries that have been executing for a duration greater the specified cutoff are alone listed when performing query analysis. For instance, if you specify 5 here, then for a slow/stalled/error transaction, the SQL Queries window will display only those queries that have been executing for over 5 milliseconds. This way, you get to focus on only those queries that could have contributed to the slowness. By default, the value of this parameter is set to 10 ms.

    Healthy URL Trace

    By default, this flag is set to No. This means that eG will not collect detailed diagnostics for those transactions that are healthy. If you want to enable the detailed diagnosis capability for healthy transactions as well, then set this flag to Yes.

    Max Healthy URLs per Test Period

    This parameter is applicable only if the Healthy URL Trace flag is set to ‘Yes’. Here, specify the number of top-n transactions that should be listed in the detailed diagnosis of the Healthy transactions measure, every time the test runs. By default, this is set to 10, indicating that the detailed diagnosis of the Healthy transactions measure will by default list the top-10 transactions, arranged in the descending order of their response times.

    Max Slow URLs per Test Period

    Specify the number of top-n transactions that should be listed in the detailed diagnosis of the Slow transactions measure, every time the test runs. By default, this is set to 10, indicating that the detailed diagnosis of the Slow transactions measure will by default list the top-10 transactions, arranged in the descending order of their response times.

    Max Stalled URLs per Test Period

    Specify the number of top-n transactions that should be listed in the detailed diagnosis of the Stalled transactions measure, every time the test runs. By default, this is set to 10, indicating that the detailed diagnosis of the Stalled transactions measure will by default list the top-10 transactions, arranged in the descending order of their response times.

    Max Error URLs per Test Period

    Specify the number of top-n transactions that should be listed in the detailed diagnosis of the Error transactions measure, every time the test runs. By default, this is set to 10, indicating that the detailed diagnosis of the Error transactions measure will by default list the top-10 transactions, in terms of the number of errors they encountered.

    Show HTTP Status

    If you want the detailed diagnosis of this test to report the HTTP response code that was returned when a transaction URL was hit, then set this flag to Yes. This will enable you to instantly identify HTTP errors that may have occurred when accessing a transaction URL. By default, this flag is set to No, indicating that the HTTP status code is not reported by default as part of detailed diagnostics.

    Show Cookies

    An HTTP cookie is a small piece of data sent from a website and stored on the user's computer by the user's web browser while the user is browsing. Most commonly, cookies are used to provide a way for users to record items they want to purchase as they navigate throughout a website (a virtual "shopping cart" or "shopping basket"). To keep track of which user is assigned to which shopping cart, the server sends a cookie to the client that contains a unique session identifier (typically, a long string of random letters and numbers). Because cookies are sent to the server with every request the client makes, that session identifier will be sent back to the server every time the user visits a new page on the website, which lets the server know which shopping cart to display to the user. Another popular use of cookies is for logging into websites. When the user visits a website's login page, the web server typically sends the client a cookie containing a unique session identifier. When the user successfully logs in, the server remembers that particular session identifier has been authenticated, and grants the user access to its services. If you want to view and analyze the useful information that is stored in such HTTP response cookies that a web server sends, then set this flag to Yes. By default, this flag is set to No, indicating that cookie information is not reported by default as part of detailed diagnostics.

    Show Headers

    HTTP headers allow the client and the server to pass additional information with the request or the response. A request header is a header that contains more information about the resource to be fetched or about the client itself. If you want the additional information stored in a request header to be displayed as part of detailed diagnostics, then set this flag to Yes. By default, this flag is set to No indicating that request headers are not displayed by default in the detailed diagnosis.

    Advanced Settings

    To optimize transaction performance and conserve space in the eG database, many restraints have been applied by default on the agent’s ability to collect and report detailed diagnostics. Depending upon how well-tuned your eG database is and the level of visibility you require into transaction performance, you may choose to either retain these default settings or override them. If you choose not to disturb the defaults, then set the Advanced Settings flag to No. If you want to modify the defaults, then set the Advanced Settings flag to Yes.

    Non-POJO Method Tracing Limit

    This parameter will appear only if the Advanced Settings flag is set to ‘Yes’. By default, when reporting the detailed diagnosis of a transaction on a particular Node.js node, this test reports the execution time of only the first 1000 non-POJO method calls (which includes JMS, JCO, HTTP, Java, SQL, etc.) that the target Node.js node makes for that transaction. This is why, the Non-POJO Method Tracing Limit parameter is set to 1000 by default. If you want, you can change the tracing limit to enable the test to report the details of more or fewer non-POJO method calls made by a Node.js node. While a high value for this parameter may take you closer to identifying the non-POJO method that could have caused the transaction to slowdown on a particular Node.js node, it may also marginally increase the overheads of the transaction and the eG agent.

    Recursive Method Tracing Limit

    This parameter will appear only if the Advanced Settings flag is set to ‘Yes’. A recursive method is a method that calls itself. By default, when reporting the detailed diagnosis of a transaction on a particular Node.js node, this test reports the execution time of only the first 1000 recursive method calls (which includes JMS, JCO, HTTP, Java, SQL, etc.) that the target Node.js node makes for that transaction. This is why, the Recursive Method Tracing Limit parameter is set to 1000 by default. If you want, you can change the tracing limit to enable the test to report the details of more or fewer recursive method calls made by a Node.js node. While a high value for this parameter may take you closer to identifying the recursive method that could have caused the transaction to slowdown on a particular Node.js node, it may also marginally increase the overheads of the transaction and the eG agent.

    Number of Exceptions To be Traced

    Profiling errors/exceptions in business transactions can be an overhead-intensive exercise for eG Node.js BTM, particularly when the target business application is transaction-heavy. To keep monitoring overheads at an acceptable level, eG Node.js BTM only traces a maximum of 1000 errors/exceptions per transaction, by default. In other words, the first 1000 errors/exceptions per transaction will only be traced by default. This is why, this parameter is set to 1000 by default. If your application is sized with more processing power, then you may want to increase this value. If not, you can decrease it further.

    Capture StackTrace For Exceptions

    When tracing exceptions, eG Node.js BTM collects and reports the stacktrace for those exceptions, along with the exception name, and description. Pulling all these details from eG Node.js BTM for every exception per transaction can significantly strain the eG remote agent. Also, the same could take up considerable space in the eG database. To keep its processing overheads under check and to conserve database space, the eG agent will, by default, pull stacktrace information only for a maximum of 5 exceptions/errors traced by eG Node.js BTM per transaction. In other words, the eG agent will, by default, pull stacktrace information for only the first 5 errors/exceptions per transaction from eG Node.js BTM. This is why, this parameter is set to 5 by default. For these 5 (default) exceptions/errors, the eG agent will pull their name and message as well. You can increase/decrease this value depending upon the processing power of the eG agent and how well-sized and well-tuned the eG database is in your environment.

    Capture Name and Message For Exceptions

    When tracing exceptions, eG Node.js BTM collects and reports the stacktrace for those exceptions, along with the exception name, and description. Pulling all these details from eG Node.js BTM for every exception per transaction can significantly strain the eG remote agent. Also, the same could take up considerable space in the eG database. To keep its monitoring overheads under check and to conserve database space, the eG agent will, by default, pull the name and message for only a maximum of 100 exceptions per transaction. In other words, the eG agent will, by default, pull the name and message for only the first 100 errors/exceptions per transaction from eG Node.js BTM. This is why, this parameter is set to 100 by default. Note that for these 100 (default) exceptions, only name and message will be captured by the eG agent and not stacktrace. You can increase/decrease this value depending upon the processing power of the eG agent and how well-sized and well-tuned the eG database is in your environment.

    Exception Stacktrace Lines

    This parameter will appear only if the Advanced Settings flag is set to ‘Yes’. As part of detailed diagnostics, this test, by default, lists the first 10 stacktrace lines of each JavaScript error/exception that it captures on the target Node.js node for a specific transaction, so as to enable easy and efficient troubleshooting. This is why, the Exception Stacktrace Lines parameter is set to 10 by default. If required, you can have this test display more or fewer stacktrace lines by overriding this default setting.

    Included Exceptions

    This parameter will appear only if the Advanced Settings flag is set to ‘Yes’. By default, this test flags the transactions in which the following errors/exceptions are captured, as Error transactions:

    • All unhandled exceptions;
    • Both handled and unhandled SQL exceptions/errors

    This implies that if a programmatically-handled non-SQL exception occurs in a transaction, such a transaction, by default, will not be counted as an Error transaction by this test.

    Sometimes however, administrators may want to be alerted even if some non-SQL exceptions that have already been handled programmatically, occur. This can be achieved by configuring a comma-separated list of these exceptions in the Included Exceptions text box. Here, each exception you want to include has to be defined using its fully qualified exception class name. For instance, your Included Exceptions specification can be as follows: java.lang.NullPointerException, java.lang.IndexOutOfBoundsException. Note that wild card characters cannot be used as part of your specification. Once the exceptions to be included are configured, then this test will count all transactions in which such exceptions are captured as Error transactions.

    Ignored Exceptions

    This parameter will appear only if the Advanced Settings flag is set to ‘Yes’. By default, this test flags the transactions in which the following errors/exceptions are captured, as Error transactions:

    • All unhandled exceptions;
    • Both handled and unhandled SQL exceptions/errors

    Sometimes however, administrators may want eG to disregard certain unhandled exceptions (or handled SQL exceptions), as they may not pose any threat to the stability of the transaction or to the web site/web application. To achieve this, administrators can configure a comma-separated list of such inconsequential exceptions in the Ignored Exceptions text box. Here, you need to configure each exception you want to exclude using its fully qualified exception class name. For instance, your Excluded Exceptions specification can be as follows: java.sql.SQLException,java.io.FileNotFoundException. Note that wild card characters cannot be used as part of your specification. Once the exceptions to be excluded are configured, then this test will exclude all transactions in which such exceptions are captured from its count of Error transactions.

    Ignored Characters

    This parameter will appear only if the Advanced Settings flag is set to ‘Yes’. By default, eG excludes all transaction URLs that contain the ‘\’ character from monitoring. If you want eG to ignore transaction URLs with any other special characters, then specify these characters as a comma-separated list in the Ignored Characters text box. For instance, your specification can be: \\,&,~

    Max Grouped URLs per Measure Period

    This parameter will appear only if the Advanced Settings flag is set to ‘Yes’. This test groups URLs according to the Max URL Segments specification. These grouped URLs will be the descriptors of the test. For each grouped URL, response time metrics will be aggregated across all transaction URLs in that group and reported.

    When monitoring web sites/web applications to which the transaction volume is normally high, this test may report metrics for hundreds of descriptors. If all these descriptors are listed in the Layers tab page of the eG monitoring console, it will certainly clutter the display. To avoid this, by default, the test displays metrics for a maximum of 50 descriptors – i.e., 50 grouped URLs alone – in the eG monitoring console, during every measure period. This is why, the Max Grouped URLs per Measure Period parameter is set to 50 by default.

    To determine which 50 grouped URLs should be displayed in the eG monitoring console, the eG Node.js BTM follows the below-mentioned logic:

    • Top priority is reserved for URL groups with error transactions. This means that eG Node.js BTM first scans URL groups for error transactions. If error transactions are found in 50 URL groups, then eG Node.js BTM computes the aggregated response time of each of the 50 groups, sorts the error groups in the descending order of their response time, and displays all these 50 groups alone as the descriptors of this test, in the sorted order.
    • On the other hand, if error transactions are found in only one / a few URL groups – say, only 20 URL groups – then, eG Node.js BTM will first arrange these 20 grouped URLs in the descending order of their response time. It will then compute the aggregated response time of the transactions in each of the other groups (i.e., the error-free groups) that were auto-discovered during the same measure period. These other groups are then arranged in the descending order of the aggregated response time of their transactions. Once this is done, eG Node.js BTM will then pick the top-30 grouped URLs from this sorted list.

      In this case, when displaying the descriptors of this test in the Layers tab page, the 20 error groups are first displayed (in the descending order of their response time), followed by the 30 ‘error-free’ groups (also in the descending order of their response time).

      At any given point in time, you can increase/decrease the maximum number of descriptors this test should support by modifying the value of the Max Grouped URLs per Measure Period parameter.

    Max SQl Queries per Transaction

    This parameter will appear only if the Advanced Settings flag is set to ‘Yes’. Typically, from the detailed diagnosis of a slow/stalled/error transaction on a Node.js node, you can drill down to view the SQL queries (if any) executed by that transaction from that node and the execution time of each query. By default, eG picks the first 500 SQL queries executed by the transaction, compares the execution time of each query with the SQL Execution Cutoff configured for this test, and displays only those queries with an execution time that is higher than the configured cutoff. This is why, the Max SQL Queries per Transaction parameter is set to 500 by default.

    To improve agent performance, you may want the SQL Execution Cutoff to be compared with the execution time of a less number of queries – say, 200 queries. Similarly, to increase the probability of capturing more number of long-running queries, you may want the SQL execution cutoff to be compared with the execution time of a large number of queries – say, 1000 queries. For this, you just need to modify the Max SQL Queries per Transaction specification to suit your purpose.

    Error SQL(s) Per Transaction

    This parameter will appear only if the Advanced Settings flag is set to ‘Yes’ If eG's cross-application transaction flow reveals that one/more SQL queries are slowing down a transaction, then, you can quickly drill down that representation to view a detailed Execution Analysis window. Clicking on the Slow SQL Queries option in the window will reveal a table that lists the lethargic and erroneous SQL statements executed by the given transaction. For error SQL, the table will include an additional Error Details column, where the error message will be displayed. .By default, for a single transaction, the eG Enterprise captures and stores in the eG database, the details of the first 10 erroneous SQL statements only. As a result, if one/more erroneous SQL statements are degrading a transaction's performance, the table in the Slow SQL Queries section for that transaction will display the first 10 erroneous queries and their error messages only. This is why, this parameter is set to 10 by default.

    This default setting is ideal for environments in which many erroneous SQL queries are often executed, with each of them throwing long winding error messages. If the eG database in such environments is not sized right or tuned well, storing these errors and messages may impose a significant strain on that database, choking it eventually. By restricting the error SQL and related messages to the first 10 (by default), eG Enterprise prevents such an unpleasant outcome.

    However, if the eG database in your environment is sufficiently sized and well-tuned, then you can increase the value of this parameter, so that more number of error SQL and messages are captured.

    Max MongoDB Query Length

    This parameter will appear only if the Advanced Settings flag is set to ‘Yes’ If eG's cross-application transaction flow reveals that one/more SQL queries are slowing down a transaction, then, you can quickly drill down that representation to view a detailed Execution Analysis window. Clicking on the Slow SQL Queries option in the window will reveal a table that lists the lethargic SQL queries and error SQL statements run by that transaction. By default, in the Query Details column of this table, the first 1024 characters of a query will alone be displayed. Similarly, in the Query section that typically displays the query chosen from the table, the first 1024 characters of the query will only appear. This is because, by default, eG Enterprise captures and stores only the first 1024 characters of each slow/erroneous SQL query in the eG database. This is why, this parameter is set to 1024 by default.

    This default setting is ideal for environments in which a single SQL query may even run across multiple pages. If the eG database in such environments is not sized right or tuned well, storing slow/erroneous queries fully may impose a significant strain on that database, choking it eventually. By restricting the query characters to be stored in the eG database to 1024 (by default), eG Enterprise prevents such an unpleasant outcome.

    However, if the eG database in your environment is sufficiently sized and well-tuned, then you can increase the value of this parameter, so that more number of query characters are stored in the eG database.

    Mask SQL

    Where inefficient SQL queries to a database backend are slowing down business transactions to an application, the detailed diagnostics of this test will display the exact queries responsible for the slowdown. Some of these queries may include fields that look up sensitive/confidential values - e.g., password, transaction ID, credit card number etc. - in the database. Unscrupulous users may sometimes use such queries to retrieve critical business information. To protect BTM-enabled business-critical applications from such attacks, eG Enterprise, by default, masks all field values in queries using the 'x' character. This is why, the Mask SQL flag is set to Yes by default. On the other hand, if you want to unmask all field values in queries, then set the Mask SQL flag to No.

    Mask Public IP

    Many high-security environments consider public IP addresses as 'classified information', as in the wrong hands, such information can cause serious damage to data security and integrity. This is why, by default, eG Enterprise hides/masks the last octet of public IP addresses displayed in detailed diagnosis using the 'x' character (by default). Accordingly, the Mask Public IP flag of this test is set to Yes by default. If you want, you can 'unmask' the last octet of public IP addresses, so the entire IP address is visible in clear text in the detailed diagnostics. For this, set the Mask Public IP flag of this test to No.

    Mask Private IP

    Many high-security environments consider private IP addresses as 'classified information', as in the wrong hands, such information can cause serious damage to data security and integrity. This is why, by default, eG Enterprise hides/masks the last octet of private IP addresses displayed in detailed diagnosis using the 'x' character (by default). Accordingly, the Mask Private IP flag of this test is set to Yes by default. If you want, you can 'unmask' the last octet of private IP addresses, so the entire private IP address is visible in clear text in the detailed diagnostics. For this, set the Mask Private IP flag of this test to No.

    IP Masking Character

    This parameter is applicable only if the Mask Public IP and/or Mask Private IP flags are set to Yes.

    By default, this parameter is set to 'x'. This means that, by default, the last octet of private and public IP addresses in detailed diagnosis are masked using the 'x' character. You can override this default value by specifying any other character that you may want to use as a masking character of IP addresses - e.g., *, ? etc.

    Mask URL Params

    Sometimes, sensitive information - e.g., passwords - may be transmitted in 'clear text' as values of certain URL parameters. To make sure that miscreants have no access to such confidential information, eG Enterprise, by default, uses the * (asterisk) character to hide/mask all parameter values in the URLs displayed in detailed diagnosis. This is why, the Mask URL Params flag is set to Yes by default. If you want, you can unmask all URL parameter values in the detailed diagnosis of this test by setting this flag to No.

    Mask All Header Fields, Exclude Header Fields From Masking

    An HTTP header is a field of an HTTP request or response that passes additional context and metadata about the request or response. Many times, these header fields may pass confidential access/user information - e.g., passwords, login IDs, transaction IDs etc. If users with ulterior motives get a hold of this information, they can hack into your mission-critical applications and cause serious damage. To avoid this, eG Enterprise, by default, uses the * (asterisk) character to mask the values of all HTTP header fields that it captures and displays as part of detailed diagnosis. Accordingly, the Mask All Header Fields flag is set to Yes by default. If you want, you can unmask all header field values by turning off the Mask All Header Fields flag - i.e., by setting that flag to No. Alternatively, you can perform 'masking' selectively. In other words, you can instruct eG Enterprise to unmask the values of only those header fields that do not carry sensitive information. For this, you need to specify a comma-separated list of header fields to exclude from masking in the Exclude Header Fields From Masking text box. For example, your specification can be: Cache-Control,Date,Pragma

    Mask All Cookie Fields

    An HTTP cookie (web cookie, browser cookie) is a small piece of data that a server sends to a user's web browser. Cookies are mainly used for session management, personalization, and tracking user behavior.

    Some times, cookie fields may inadvertently or for troubleshooting purposes transmit confidential information such as passwords to a user's web browser. If the server-browser communication is intercepted by malicious users, they can use the sensitive access information contained within the cookie field values to wreak havoc on your systems/applications. To avoid this, eG Enterprise, by default, uses the * (asterisk) character to mask/hide all cookie field values. This is why, the Mask All Cookie Fields flag is set to Yes by default. If you want, you can unmask all cookie field values by setting this flag to No.

    Mask Exception Message

    Exception messages can sometimes include variables that carry sensitive information in plain text. If users with malicious intent come in contact with such information, it can prove to be a serious threat to the security of your mission-critical apps. To prevent the misuse of such confidential information, eG Enterprise, by default, uses the * (asterisk) character to mask the variables in all exception messages. This is why, the Mask Exception Message flag is set to Yes by default. If you want, you can unmask these variables by setting the same flag to No.

    Timeout

    By default, the eG agent will wait for 1000 milliseconds for a response from the eG Application Server agent. If no response is received, then the test will timeout. You can change this timeout value, if required.

    DD Frequency

    Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD frequency.

    Detailed Diagnosis

    To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option.

    The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled:

    • The eG manager license should allow the detailed diagnosis capability
    • Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.
    Measures reported by the test
    Measurement Description Measurement Unit Interpretation

    All transactions

    Indicates the total number of requests received for transactions of this pattern during the last measurement period.

    Number

    By comparing the value of this measure across transaction patterns, you can identify the most popular transaction patterns. Using the detailed diagnosis of this measure, you can then figure out which specific transactions of that pattern are most requested.

    For the Summary descriptor, this measure will reveal the total number of transaction requests received by the target Node.js application server during the last measurement period. This is a good indicator of the transaction workload on that Node.js application server.

    Avg response time

    Indicates the average time taken by the transactions of this pattern to complete execution.

    Msecs

    Compare the value of this measure across patterns to isolate the type of transactions that were taking too long to execute. You can then use the detailed diagnosis of the All transactions measure of that group to know how much time each transaction in that group took to execute. This will lead you to the slowest transaction.

    For the Summary descriptor, this measure will reveal the average responsiveness of all the transaction requests received by the target Node.js application server during the last measurement period. An abnormally low value for this measure for the Summary descriptor could indicate a serious processing bottleneck on the target Node.js application server.

    Healthy transactions

    Indicates the number of healthy transactions of this pattern.

    Number

    By default, this measure will report the count of transactions with a response time less than 4000 milliseconds. You can change this default setting by modifying the thresholds of the Avg response time measure using the eG admin interface.

    For the Summary descriptor, this measure will report the total number of healthy transactions on the target Node.js application server.

    Healthy transactions percentage

    Indicates what percentage of the total number of transactions of this pattern is healthy.

    Percent

    To know which are the healthy transactions, use the detailed diagnosis of this measure. For the Summary descriptor, this measure will report the overall percentage of healthy transactions on the target Node.js application server.

    Slow transactions

    Indicates the number of transactions of this pattern that were slow during the last measurement period.

    Number

    By default, this measure will report the number of transactions with a response time higher than 4000 milliseconds and lesser than 60000 milliseconds. You can change this default setting by modifying the thresholds of the Avg response time measure using the eG admin interface.

    A high value for this measure is a cause for concern, as too many slow transactions means that user experience with the web application is poor. For the Summary descriptor, this measure will report the total number of slow transactions on the target Node.js application server. This is a good indicator of the processing power of the target Node.js application server.

    Slow transactions response time - avg

    Indicates the average time taken by the slow transactions of this pattern to execute.

    Msecs

    For the Summary descriptor, this measure will report the average response time of all the slow transactions on the target Node.js application server.

    Slow transactions percentage

    Indicates what percentage of the total number of transactions of this pattern is currently slow.

    Percent

    Use the detailed diagnosis of this measure to know which precise transactions of a pattern are slow. You can drill down from a slow transaction to know what is causing the slowness. For the Summary descriptor, this measure will report the overall percentage of slow transactions on the monitored Node.js application server.

    Error transactions

    Indicates the number of transactions of this pattern that experienced errors during the last measurement period.

    Number

    A high value is a cause for concern, as too many error transactions to a web application can significantly damage the user experience with that application. For the Summary descriptor, this measure will report the total number of error transactions on the target Node.js application server. This is a good indicator of how error-prone the target Node.js application server is.

    Note:

    You can configure what types of transactions are to be counted and reported as Error transactions by this measure. For this, do the following:

    • Edit the btmOther.props file on the Node.js application server being monitored.

    • Look for the ERROR_STATUS_CODE_RANGE parameter in the file.

    • Once you find the parameter, specify a comma-separated list of HTTP error response code ranges against this parameter. For example, your specification can be:

      ERROR_STATUS_CODE_RANGE= 204-250,304-325,408-430

      eG Node.js BTM will only consider those transactions that return HTTP response codes that fall within the code ranges configured here as 'error transactions'. The count of such transactions will then be reported as the value of the 'Error transactions' measure.

    Error transactions response time - avg

    Indicates the average duration for which the transactions of this pattern were processed before an error condition was detected.

    Msecs

    The value of this measure will help you discern if error transactions were also slow. For the Summary descriptor, this measure will report the average response time of all error transactions on the target Node.js application server.

    Error transactions percentage

    Indicates what percentage of the total number of transactions of this pattern is experiencing errors.

    Percent

    Use the detailed diagnosis of this measure to isolate the error transactions. You can even drill down from an error transaction in the detailed diagnosis to determine the cause of the error. For the Summary descriptor, this measure will report the overall percentage of transactions of this pattern on the target Node.js application server that is currently experiencing errors.

    Stalled transactions

    Indicates the number of transactions of this pattern that were stalled during the last measurement period.

    Number

    By default, this measure will report the number of transactions with a response time higher than 60000 milliseconds. You can change this default setting by modifying the thresholds of the Avg response time measure using the eG admin interface.

    A high value is a cause for concern, as too many stalled transactions means that user experience with the web application is poor. For the Summary descriptor, this measure will report the total number of stalled transactions on the target Node.js application server.

    Stalled transactions response time - avg

    Indicates the average time taken by the stalled transactions of this pattern to execute.

    Msecs

    For the Summary descriptor, this measure will report the average response time of all stalled transactions on the target Node.js application server.

    Stalled transactions percentage

    Indicates what percentage of the total number of transactions of this pattern is stalling.

    Percent

    Use the detailed diagnosis of this measure to know which precise transactions of a pattern are stalled. You can drill down from a stalled transaction to know what is causing that transaction to stall. For the Summary descriptor, this measure will report the overall percentage of transactions of this pattern on the target Node.js application server that is stalling.

    SQL statements executed

    Indicates the number of slow SQL queries that were executed by the transactions of this pattern during the last measurement period.

    Number

    For the Summary descriptor, this measure will report the total number of slow SQL queries executed by all transactions to the target Node.js application server.

    Avg SQL statement time

    Indicates the average execution time of the slow SQL queries that were run by the transactions of this pattern.

    Msecs

    If there are too many slow transactions of a pattern, you may want to check the value of this measure for that pattern to figure out if query execution is slowing down the transactions. Use the detailed diagnosis of the Slow transactions measure to identify the precise slow transaction. Then, drill down from that slow transaction to confirm whether/not database queries have contributed to the slowness. Deep-diving into the queries will reveal the slowest queries and their impact on the execution time of the transaction.

    CPU time - average

    Indicates the average time for which transactions of this pattern were utilizing the CPU.

    Msecs

    Compare the value of this measure across transaction patterns to accurately identify the CPU-intensive transaction patterns.

    For the Summary descriptor, this measure will report the average time for which all the transactions on the target Node.js application server used the CPU.

    Block time - average

    Indicates the average duration for which transactions of this pattern were blocked and could not execute.

    Msecs

    If the Avg response time for any transaction pattern is very high, you may want to check the value of this measure for that pattern. This will help you figure out whether/not prolonged blocking is causing transactions of that pattern to slow down or stall.

    For the Summary descriptor, this measure will report the average time for which all the transactions on the target Node.js application server were blocked.

    Wait time - average

    Indicates the average duration for which transactions of this pattern were waiting before they resumed execution.

    Msecs

    If the Avg response time for any transaction pattern is very high, you may want to check the value of this measure for that pattern. This will help you figure out whether/not a very high waiting time is what is causing the transactions to slow down/stall.

    For the Summary descriptor, this measure will report the average time for which all the transactions on the target application server were waiting.

    Total transactions per minute

    Indicates the number of transactions of this pattern that are executed per minute.

    Number

    For the Summary descriptor, this measure will report the total number of transactions that were executed per minute. This is a good indicator of the transaction processing ability of the target Node.js application server.

    Error transactions per minute

    Indicates the number of error transactions of this pattern that are executed per minute.

    Number

    A very low value is desired for this measure.

    Compare the value of this measure across transaction patterns to find that pattern of transactions that is experiencing errors frequently.

    For the Summary descriptor, this measure will report the total number of error transactions that were executed per minute.

    Satisfaction score

    Indicates the satisfaction score of this pattern based on the response time of the transactions.

    Percent

    The Satisfaction score is derived using the following formula:

    (All transactions-Error transactions-Stalled transactions)-(Slow transactions /2 ) / All transactions

    A score of 100 means all transactions were satisfactory. A score of 0 means none of the transactions were satisfactory.

    Ideally therefore, the value of this measure should be 100. A value less than 100 indicates that the experience of users from this region has been less than satisfactory.