PHP FPM Web Transactions By Site Test

Ideally, the value of this measure should be 0.

Ideally, the value of this measure should be 0.

A high value is indicative that many transactions are slow. To identify the slow transactions, use the detailed diagnosis of the Total requests processed measure or Requests processed successfully measure (if enabled).

A value close to 100% is a cause for concern, as it implies that the PHP web sites on the server are using the CPU resources excessively. In this case, use the detailed diagnosis of the Total requests processed or the Requests processed successfully measures, to quickly isolate the PHP transactions that are hogging CPU.

This measure is a good indicator of current load on the server.

The detailed diagnosis of this measure, if enabled, provides in-depth insights into the requests processed. The details include the URL of each transaction request, the user who initiated the transaction, the HTTP response status for the transaction, the time taken by the server to process the transaction, the throughput per transaction, the CPU and memory usage of every transaction, the protocol used, and more. Using these useful metrics, administrators can precisely pinpoint the transaction that took the longest to be processed, and who initiated it.

Ideally, the value of this measure should be equal to or close to the value of the Total requests processed measure. A value that is much lower than that of the Total requests processed measure could mean that many requests failed processing or are pending processing. Either way, it is not a sign of good health.

The detailed diagnosis of this measure, if enabled, provides in-depth insights into the successful requests. The details include the URL of each transaction request, the user who initiated the transaction, the HTTP response status for the transaction, the time taken by the server to process the transaction, the throughput per transaction, the CPU and memory usage of every transaction, the protocol used, and more.

A site returns 300 series response codes when it redirects requests to other pages. Redirection is performed for various reasons. For example, when the client browser may have to request a different page on the server or to repeat the request by using a proxy server.

These codes helps the client to ensure that a redirection to a different resource or URL should take place to complete the requests and access the desired resource.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 3xx responses, and which users were impacted.

An HTTP 301 response is returned if the URL of the requested resource has been changed permanently. The new URL is given in the response.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 301 responses, and which users were impacted.

A 302 Found message is an HTTP response status code indicating that the requested resource has been temporarily moved to a different URL. Since the location or current redirection directive might be changed in the future, a client that receives a 302 response code should continue to use the original URL for future requests.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 302 responses, and which users were impacted.

The HTTP 304 response code indicates that there is no need to retransmit the requested resources. It is an implicit redirection to a cached resource. This means that the requested resource is already in the cache and the resource has not been modified since it was cached. Therefore, the client can use the cached copy of the resource, instead of downloading it from the server. This happens when the request method is safe, like a GET or a HEAD request, or when the request is conditional and uses a If-None-Match or a If-Modified-Since header.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 304 responses, and which users were impacted.

The HTTP 307 Temporary Redirect status response code indicates that the resource requested has been temporarily moved to the URL given by the Location headers.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 307 responses, and which users were impacted.

The 4xx HTTP status codes indicate that an error occurred and the client browser appears to be at fault. For example, the client browser may have requested a page that does not exist or may not have provided valid authentication information.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 4xx responses, and which users were impacted.

The web site returns the HTTP 400 code when the request could not be understood by the server due to malformed syntax. This implies that the client should not repeat the request without modifications.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 400 responses, and which users were impacted.

The HyperText Transfer Protocol (HTTP) 401 Unauthorized response status code indicates that the client request has not been completed because it lacks valid authentication credentials for the requested resource.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 401 responses, and which users were impacted.

The login failure error occurs when the logon attempt is unsuccessful, probably because of a user name or password that is not valid.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 401.1 responses, and which users were impacted.

Ideally, the value of this measure should be zero.

The HTTP 401.2 status code indicates a problem in the authentication configuration settings on the server.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 401.2 responses, and which users were impacted.

Ideally, the value of this measure should be zero.

Authorization errors will be reported when the requests are not authenticated by ACL on resource or filter or ISAPI/CGI application.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 401.3, 401.4, and 401.5 responses, and which users were impacted.

Ideally, the value of this measure should be zero.

A web site encounters forbidden errors for various reasons, for example, when the web site receives too many requests from the same client.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 403 responses, and which users were impacted.

Ideally, the value of this measure should be zero.

The 404 error is reported when the server has not found anything matching the Request-URL. This error code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 404 responses, and which users were impacted.

The 405 Method Not Allowed response code indicates that the method specified in the Request-Line is known by the origin server but is not supported by the target resource. To avoid this, administrators should include the response MUST an Allow header containing a list of valid methods for the requested resource.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 405 responses, and which users were impacted.

Ideally, the value of this measure should be zero.

The HTTP 406 (Not Acceptable client) error code indicates that the server cannot produce a response matching the list of acceptable values defined in the request's proactive content negotiation headers, and that the server is unwilling to supply a default representation.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 406 responses, and which users were impacted.

Ideally, the value of this measure should be zero.

The 408 Request Timeout error indicates that the request sent to the web server (e.g. a request to load a web page) took longer than the web server was prepared to wait. In other words, your connection with the web site "timed out".

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 408 responses, and which users were impacted.

Ideally, the value of this measure should be zero.

The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This response code allows the client to place preconditions on the current resource metainformation (header field data) and thus prevent the requested method from being applied to a resource other than the one intended.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 412 responses, and which users were impacted.

Ideally, the value of this measure should be zero.

Response codes in the range of 500-511 often indicate server errors. The server error messages are reported for a wide variety of server-side errors. For more information on the errors, you can refer event viewer logs and find out the reason why the errors occur.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 5xx responses, and which users were impacted.

Ideally, the value of this measure should be zero.

The 500.0 error occurs when the ISAPIModule module is missing from the modules list for the web site. ISAPI filters (modules) are libraries loaded by the IIS web server. Every incoming request and outgoing response passes through the filters, and they are free to perform any handling or translation they wish. They can be used for authentication, content transformation, logging, compression, and myriads of other uses.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 500.0 responses, and which users were impacted.

Ideally, the value of this measure should be zero.

A web site reports 500.11 HTTP error code when an application on the server is shutting down, and thus the received request cannot be processed by the web site.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 500.11 responses, and which users were impacted.

Ideally, the value of this measure should be zero.

This error occurs when you tried to load an ASP page while IIS server was in the process of restarting the application. This error message will disappear when you refresh the page.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 500.12 responses, and which users were impacted.

Ideally, the value of this measure should be zero.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 500.13 responses, and which users were impacted.

Ideally, the value of this measure should be zero.

These errors occur when a dynamic-link library (DLL) that is required by the Microsoft Data Access Components is not registered. To alleviate this kind of errors, administrators should register the DLL before the errors cause serious impacts on the key transactions.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 500.100 responses, and which users were impacted.

Ideally, the value of this measure should be zero.

The 503 errors occur when the application pool/service is stopped or mismatch in user identity settings is recorded. Administrators can fix these issues by restarting the stopped application pool/service and updating the user account settings.

Use the detailed diagnosis of this measure to know which transaction requests returned HTTP 503 responses, and which users were impacted.