L
lecuyer
Guest
There is no simple way to empirically identify the specific requests that cause large values for the rqWait time. However, it may be possible to narrow down the source of this a bit. As requests arrive in the broker, agents are assigned in a FIFO manner to serve these request. If agents are 'available' to serve the request, they are assigned immediately ... no waiting involved. If no agents are available at that moment, the request waits for a short time for an existing agent to become available, on the assumption that an existing agent may become available in less time than it would take to start a new agent. The duration of this timeout is specified by the srvrStartupTimeout property (def=3 secs)in the ubroker.properties file Once this first timeout occurs, behavior depends on whether all allowed agents have been started (based on the srvrMaxInstance property). If all agents have been started, then the request waits again for an existing agent to become available. The duration of this second wait is defined by the requestTimeout property (def= 15 secs). If no agent becomes available within this interval, an error response is returned to the client. For these types of requests, the maximum rqWait should be no greater than the sum of the srvrStartupTimeout and the requestTimeout (approximately). If the number of agents has not reached its maximum, then the broker attempts to start a new agent. It is important to note that at this point, the requestTimeout timer is stopped, since the amount of time necessary to start a new agent is application dependent. Consequently, for requests where a new agent process is started 'on demand', the rqWait time will include the srvrStartupTimeout plus the amount of time it takes to start a new agent process. It is also important to note that this time also includes the time necessary to run the agent startup procedure (which may involve connecting to databases, loading of application context information, caching of static temptables, etc.). This would suggest, therefore, that the large rqWait times represent large agent startup times. This time could be aggravated by the frequency with which agents are started 'on demand', and whether multiple agents are started up simultaneously. This could be the result of request 'storms' due to application requirements. As far as the discrepancies in the nRq, nSent, and nRcvd values, this is perfectly normal. It would suggest that the average request transfers a lot of data in each direction. As the kbase suggests, as requests are sent and received, they are serialized into 'packets' of (relatively) fixed length. A request/response message may involve multiple packets depending on the size of parameter data.
Continue reading...
Continue reading...