Forum OpenACS Q&A: Re: xotcl-request-monitor blocking requests

Collapse
2: Re: xotcl-request-monitor blocking requests (response to 1)
Posted by Gustaf Neumann on 05/19/21 11:51 AM
The request monitor implements several features, where not all of these are wanted on every site.

The main features are
* performance overview
* performance statistics
* rescheduling between different connection thread pools
* request blocking
* request throttling
* value provider for munin-plugins

Performance overview

Performance statistics: display certain slow calls, causing queuing etc.

Connection thread pools: When certain requests take longer than a threshold value, move these on the fly to a "slow" pool, if such a pool is configured. This pool is not especially "slow", but it is typically defined with a larger queue, where requests are potentially rejected, if there are too many. But, the main point is, it avoids that the default pool is blocked by too many slow requests, such ensuring good service quality for most of the users.

To get some picture, below is a site having 5 connection pools defined, including a "slow" and a "fast" pool.

The request blocking can be optionally configured (parameter "do_double_click_prevention"). It is based on a white-list (e.g. embedded requests, members of the "fast" pool) and blocks URLs, which are executed by the same use on the same URL (see throttle_check). Your are right, this does not include the query parameters, and since this check happens in another thread, this thread is no access to the query parameters (if these are not passed explicitly). In general, it would be possible to include these).

The request throttling is something, i would not recommend to use, but i have not deleted it, since due to the new features in NaviServer 4.99.20 it in general possible to move some over-eager users (maybe temporarily) to some slow pool to ensure general liveliness. ... but other things got higher priority.

Concerning the munin-plugins: i thing, these are publically visible at https://openacs.org/munin/

So, in short, you can deactivate the request blocking, and still use the request monitor to get statistics, etc. One can in general extend the request blocking to include the query parameters, but has to check, what the consequences are. Probably the easiest way is to define this separated from the rest.

hope this helps
-gn