This directive defines the maximum size of the Appweb data cache. This cache store is used for caching responses and for the session state date for ESP applications. If the maximum size is exceeded, Appweb will prune the oldest data in the cache to make room for newer items.

This directive defines the maximum chunk size when using Transfer Chunk Encoding.

The LimitClients directive defines the maximum number of simultaneous client systems that can connect to the server. Connections in excess of this count will be rejected. A limit of '0' means unlimited.

This directive counts the number of client systems. A system with many users all using the same IP address will be counted as one client.

This directive defines the maximum number of requests that may be serviced using a single TCP/IP connection.

Limiting the number to a reasonable maximum can help reduce the impact of some denial of service attacks.

The LimitMemory directive defines the maximum amount of memory that Appweb can use. On Linux and MacOSX, where a fast memory size API exists, this is the amount of memory currently used by the application. On other platforms, it is the amount of Appweb heap memory and does not include thread stack or code allocations. If the memory limit is exceeded, Appweb will invoke the policy specified by the MemoryPolicy directive.

The LimitRequests directive defines the maximum number of simultaneous incoming HTTP requests that are permitted. Requests in excess of this count will be rejected. A limit of '0' means unlimited.

This directive limits the number of HTTP requests, whereas the LimitClients directive limits the number of connected client systems.

NOTE: that many browsers can and will initiate multiple requests when requesting a page. Some browsers will initiate up to six requests at a time for a single tab.

The LimitRequestBody directive defines a maximum size for the request body. For embedded applications, it is useful to limit the request body to the expected maximum. This ensures that rogue or malicious requests will not cause the server to allocate unwanted memory to servicing the request.

The limit is an integer between zero and 2147483647 (2GB), where zero means unlimited. If a request is received that is larger than the limit, it will be rejected and the client will receive an error. The default limit is 64 MB.

This directive can be quite useful in certain denial-of-service attacks where the attacker sends large documents of a certain type.

The LimitRequestForm directive defines a maximum size for the request form data. Form data is encoded with a Content-Type of "application/x-www-form-urlencoded". Form data is fully buffered before doing Route matching and constructing the pipeline. Whereas, non-form data is streamed to the handler and not buffered.

For embedded applications, it is useful to limit the request body to the expected maximum. This ensures that rogue or malicious requests will not cause the server to allocate unwanted memory to servicing the request.

The limit is an integer between zero and 2147483647 (2GB), where zero means unlimited. If a request is received that is larger than the limit, it will be rejected and the client will receive an error. The default limit is 64 MB.

This directive can be quite useful in certain denial-of-service attacks where the attacker sends large documents of a certain type.

The LimitRequestHeader directive defines the maximum size of the request header from the client. For embedded applications, it is useful to limit the size of the header to the expected maximum. This ensures that rogue or malicious requests will not cause the server to allocate unwanted memory to servicing the request. Typically, HTTP requests will not have more than 4K of header data.

The limit is an integer between zero and 1 MB, where zero means unlimited. If a request is received that has a header larger than the limit, it will be rejected and the client will receive an error. The default limit is 8 K.

This directive can be quite useful in certain denial-of-service attacks where the attacker sends requests with large bogus headers.

The LimitRequestHeaderLines directive defines a maximum number of header lines that may be in a request from a client. For embedded applications, it is useful to limit the number of header lines to the expected maximum. This ensures that rogue or malicious requests will not cause the server to allocate unwanted memory to servicing the request. Typically, HTTP requests will not have more than 15-20 header lines.

The limit is an integer between zero and 4096, where zero means unlimited. If a request is received that has more header lines than the limit, it will be rejected and the client will receive an error. The default limit is 40.

This directive can be quite useful in certain denial-of-service attacks where the attacker sends requests with many spurious header lines.

The LimitResponseBody directive defines the maximum size for response body data.

NOTE: this is a proprietary directive of Appweb and is not supported by Apache.

This directive defines the maximum buffer size in bytes for each stage in the request pipeline. This directive places a limit on the amount of memory consumed by pipeline stages.

NOTE: this does not imply a maximum response size (See LimitResponseBody for that functionality). It merely limits the memory consumed when trying to buffer the response data. Appweb handlers will flush the buffers and use HTTP/1.1 chunked output if the amount of response data exceeds the output buffer size.

NOTE: this is a proprietary directive of Appweb and is not supported by Apache.

The LimitUri directive defines the maximum size of a URL in Appweb. In embedded applications, it is useful to limit the number of header lines to the expected maximum. This ensures that rogue or malicious requests will not cause the server to allocate unwanted memory to servicing the request.

The limit is an integer between zero and 256 K where zero means unlimited. If a request is received that has a URL larger than the limit, it will be rejected and the client will receive an error. The default limit is 4 K.

NOTE: this is a proprietary directive of Appweb and is not supported by Apache.

This directive can be quite useful in certain denial-of-service attacks where the attacker sends requests with bogus URLs.

Appweb manages memory proactively and ensures reliable operation by preventing memory allocation errors before they occur. It does this by defining a memory limit and enforcing a memory policy for how to react when memory is depleted.

The MemoryPolicy directive defines how Appweb will respond to low memory conditions. While the LimitMemory directive defines a maximum amount of memory that Appweb is permitted to use, the MemoryPolicy directive defines how Appweb will respond when the limit is approached and exceeded.

Appweb also institutes a memory redline that is 85% of the memory limit. When memory utilization exceeds the redline value, Appweb will attempt to free non-essential memory such as the data for request caching. If memory utilization exceeds the maximum memory limit, Appweb will invoke the memory depletion policy defined by this directive.

If the memory policy is set to prune, Appweb will prune all non-essential memory, but will continue to run. i.e. the limit becomes a soft limit and can be exceeded. If the policy is set to restart, then Appweb will do a graceful restart if the maximum is exceeded. A graceful restart will allow up to 30 seconds for existing requests to complete. If the policy is set to exit, then Appweb will immediately exit if the maximum is exceeded.

The StartWorkers directive will pre-allocate the specified number of worker threads on startup and then ensure that the worker pool always has at least this number of workers.

Appweb will automatically adjust the number of workers between the minimum specified by this directive and the maximum specified by the WorkerLimit directive or via the Appweb command line. Every ten minutes, Appweb will prune workers that have been idle for five minutes to reduce resource consumption.

Appweb 4 has two non-worker threads: one for the master event loop and one for the garbage collector. So the total number of Appweb threads will be two plus the number of active workers.

The ThreadStack directive defines the size of the thread stack to allocate for each thread. The limit is an integer between zero and an operating system defined maximum  where zero means use the system default. The default limit is zero which implies the system default.

If you are experiencing crashes when running multi-threaded, and Appweb runs without error when running single-threaded, you may need to increase this value. See the Appweb command line for details on running single user by setting the "-p 0" option.

The WorkerLimit directive defines a maximum number of threads for the Appweb thread pool. When running in multithreaded mode, Appweb will use a pool thread to service each request and then will return the thread to the pool. This results in a highly responsive and scalable architecture with excellent throughput characteristics. Each thread requires a thread stack and thus consumes memory. By limiting the number of threads, memory can be conserved.

If the maximum number of threads is also specified via the Appweb command line, the command line value will take precedence.

Appweb will automatically adjust the number of pool threads between the minimum specified by the StartWorkers directive and the maximum specified by this directive. Appweb will prune idle threads to reduce resource consumption as required.