Throttling
The Content Engine has a a number of throttle services that you can use to limit the number of concurrent requests that various parts of the system will attempt to handle. Once the specified threshold is reached, requests to the overloaded part of the system will be refused.
The following throttle services are available:
WebServiceThrottle
-
Limits access to the Content Engine web service used by Content Studio.
DatabaseUpdateThrottleService
-
Limits the number of concurrent database updates.
DatabaseReadThrottleService
-
Limits the number of concurrent database reads.
JspThrottleService
-
Limits the number of concurrent page requests.
The throttle services are all enabled by default and set up with default configurations. You should not switch the throttle services off in a production environment, as overload situations are then likely to be handled in an unpredictable manner. You can, however, configure the throttle services by editing the appropriate files in one of your configuration layers (see Configuring The Content Engine).
All the throttle services are instances of the
ResourceThrottle
class, and are configured by setting
ResourceThrottle
properties. The most important
property you can set is maximumConcurrent
, which
determines the maximum number of concurrent requests that will be handled.
For WebServiceThrottle
,
DatabaseUpdateThrottleService
and
DatabaseReadThrottleService
,
maximumConcurrent
is set by default to 100, which is a
relatively high value that can most likely be left unmodified. Database
accesses should normally be controlled by the database system itself, so
DatabaseUpdateThrottleService
and
DatabaseReadThrottleService
can be seen as "failsafe"
devices that will only ever be needed if something is badly configured
elsewhere. Similarly, usage of the
Content Engine's
web service is unlikely under normal operation ever to reach a level of
100 concurrent accesses, even in large installations, so if this limit is
ever reached, it is probably a sign that something is wrong.
JspThrottleService
, on the other hand, is not just a
failsafe device, it is vital to ensuring that the
Content Engine
handles periods of high activity in a controlled manner. Moreover, the
optimum setting for maximumConcurrent
is entirely
installation-dependent, and must be based on experience and testing. For
this reason, the default value is deliberately set set to a low value of
10. There is no sensible default: you must observe the
Content Engine's
performance and arrive at the optimum setting by trial and error.
In order to find out the optimum settings in a production environment, you
need to examine performance numbers, and the number of HTTP 503 messages
returned. The escenic-admin
application's
Performance summary option displays a page of
performance data including an Activity Monitors
section containing throttle activity data (see
Activity Monitors).
The Current Usage column in the Activity
Monitors section shows the current number of concurrent
accesses. Above the Current Usage section, the
/neo/io/reports/HitCollector
entry in the Load
Averages
section shows the request load reaching the
Content Engine.
The Failures field shows how many requests have
failed or been rejected. If failures are being recorded by the
/neo/io/reports/HitCollector
, and you see that
incrementations of this value coincide with high Current
Usage values for the JspThrottleService
,
then maximumConcurrent
is probably set too low.
All the throttles are implemented using the
ResourceThrottle
class, and therefore have the same set
of configuration properties, described in the following section.