ns_limits - Connection request resource limits
There are 4 limits which may be set to protect the server: the maximum number of running connections, the maximum number of waiting connections, max number of bytes the server will read, and the response timeout.
The four limits are assembled into a bundle and the bundle is registered for one or more URLs.
A default limits bundle is created at server startup and applies to all URLs which do not have a more specific limit registered. The configuration options can be adjusted for the default limits and any additional limits created at run-time.
Set the configuration options for a named limits bundle. If the limit does not exist it will be created. Default values are used for unspecified options.
Limits bundles exist in a process-wide namespace. The single limit X may be registered for more than one virtual server. This makes sense, as the resources being controlled are a limit of the machine the NaviServer is running on (or some subset of) and affects all virtual servers.
Get the current configuration options and accumulated runtime statistics for the named limits bundle. The result is a list in Tcl array-get format which can be used, for example, to initialise a hash table.
The number of connections currently running with a URL which is mapped to this limit bundle.
The number of active connections waiting to run because either there is no connection thread available or the ?maxrun? limit has been reached.
Number of connections closed due to timeout.
Number of connections dropped due to...
Number of connections dropped due to ...
The current maxrun configuration option, which may be adjusted by a call to ns_limits_set with the -maxrun option.
The current maxwait configuration option, which may be adjusted by a call to ns_limits_set with the -maxwait option.
The current maxupload configuration option, which may be adjusted by a call to ns_limits_set with the -maxupload option.
The current timout configuration option, which may be adjusted by a call to ns_limits_set with the -timeout option.
Register the named limits for the given URL.
List the names of all limit structures, or only those whose name matches the given glob pattern. The limit names can be passed to ns_limits_get and ns_limits_register.
The following configuration options are available to control limits at server startup in addition to the ns_limits commands which can be run once the the server has started:
Global limit names and descriptions:
ns_section "ns/limits" ns_param default "Default connections" ns_param slow "Slow connections"
Global limit configurations:
ns_section "ns/limit/default" ns_param maxrun 100 ns_param maxwait 100 ns_param maxupload 10240000 ns_param timeout 60 ns_section "ns/limit/slow" ns_param maxrun 10 ns_param maxwait 0
Mapping virtual server URLs to global limits:
ns_section "ns/server/server1/limits" ns_param default {GET /*} ns_param slow {GET /download} ns_param slow {GET /*.pdf}
The following example shows how to prevent large file downloads (which may take some time to complete) from using up all available connection slots, preventing other pages from being served.
The large files are loacted in the /download directory. We also want to control large PDF files which are located throughout the URL hierarchy using the same limit.
With this configuration there can be at most 10 simultaneous downloads of PDF files or files in the /download directory, in total, at any one time. Reuquests for other URLs will have the default limit applied.
ns_limits_set -maxrun 10 -maxwait 0 -- slow ns_limits_register slow GET /download ns_limits_register slow GET /*.pdf
The following example proc can be used to log statistics on failed requests peridoically:
proc log_limits {} { foreach limit [ns_limits_list] { array set l [ns_limits_get $limit] ns_log notice "limit[$limit]: " \ "timeouts: $l(ntimeout) drops: $l(ndropped) overflows: $l(noverflow)" } } ns_schedule_proc 3600 log_limits