Known Limitations to Quality of Service

When you use the quality of service features, keep in mind the following limitations:

• The connection or bandwidth statistics are not shared across server processes because of performance. In other words, the setting of MaxProc is not accounted for. All the limits apply individually to a server process, not to the aggregate of all processes. For more information on MaxProcs and multiple processes, see the Sun Java System Web Server 6.1 SP10 Performance Tuning, Sizing, and Scaling Guide.

• The quality of service features only measure the HTTP bandwidth at the application level. The HTTP bandwidth can differ from the actual TCP network bandwidth for a variety of reasons:

  • If SSL is enabled, handshakes and client certificate exchanges add to the traffic but are not measured.

  • If chunked encoding is enabled in one of the directions or both, the chunking layer removes the chunk headers and they are not counted in the traffic. Other headers or protocol items are counted.

  The quality of service features cannot accurately measure traffic from PR_TransmitFile calls. For basic I/O operations such as PR_Send()/net_write or PR_Recv()/net_read, the data transferred can be quickly accounted for by the bandwidth manager, since the number of bytes transferred in one system call is usually the size of a buffer and the I/O call returns quickly. This works very well to measure the instantaneous bandwidth of dynamic content applications. However, because the amount of data transferred from PR_TransmitFile is only known at the end of the transfer, it cannot be measured before the transfer completes.

  If the PR_TransmitFile is short, the quality of service features performs adequately. However, If the PR_TransmitFile is long, such as in the case of a long file downloaded by a dialup user, the whole amount of data transferred is counted at completion time. When the bandwidth manager recomputes bandwidth after the next recompute interval period starts, the bandwidth computed will go up significantly because of that recent large PR_TransmitFile. This case could cause the server to deny all requests until the next metric interval, when the bandwidth manager will "expire" the transmit file operation, since it is too old, and thus the bandwidth value will go back down. If your site has a lot of very long static file downloads, the you should increase the metric interval from the default 30 seconds.

• The bandwidth computed is always an approximation because it is not measured instantaneously, but is recomputed at regular intervals and over a certain period. For example, if the metric interval is the default 30 seconds and the server is idle for 29 seconds, the next second, a client could potentially use 30 times the bandwidth limit in one second.

• The quality of service bandwidth statistics are lost whenever the server is reconfigured dynamically. In addition, the quality of service limitations are not enforced in threads that have connections on an older, inactive configuration, because the bandwidth manager thread only computes bandwidth statistics for the active configuration. Potentially, a client that does not close its socket for a long time and remains active so that the server does not time it out would not be subject to the quality of service limitations after a server dynamic reconfiguration.

• The concurrent connections are computed with a different granularity for virtual servers than for virtual server classes and the global server instance. The connection counter for an individual virtual server is incremented atomically immediately after the request is parsed and routed to the virtual server. It is also decremented atomically at the end of the response processing for that request. This means that the virtual server connection statistics are always exact at any instant.

  However, the connection statistics for the virtual server class and global server instance are not updated instantly. They are updated by the bandwidth manager thread every recompute interval. The connection count for the virtual server class is the sum of the connections on all virtual servers of that class. The global server instance connection count is the sum of connections on all virtual server classes.

  Because of the way these values are computed, the number of connections for a virtual server is always correct (and if you have enforced a limit to the number of connections, you can never have more than the limit), and the virtual server class and server instance values are not quite as accurate, since they are only computed at intervals.