The here listed options effect the overall settings that are the same for all virtual servers.
- use fork
This is a flag and takes no value, without it posix threads will be used. As of 890 it is recommended to use this mode. It's speed
is almost as fast as the threading mode now for static files, but CGI is a lot faster (especially under high load).
- use nagle
This is a flag and takes no value, without it the Nagle algorythm will be disabled. The Nagle algorithm is used to combine network packets. This might cause a slight answere delay. It will have a positive effect in case a lot pipelined requests are made. Basically it helps to reduce the protocol overhead on the ip-layer which is a good thing. dpfTVS always sends the http-header out with a single write and then any possible content afterwards which will cause the first packet to be smaller than the maximum otherwise. Content has also to be copied from pipes (cgi) and sockets (mugi) which might also cause data packets in non optimal sizes. Don't be fooled by primitive "flooding" type benchmark results into disabling this feature. However, if you benchmark it this way, turn it off.
- max_threads
Sets the maximum number of worker threads/processes. That's basically the number of concurrent connections the server tries to process. Default is 200. The highest value dpfTVS will use internally is limited by the maximum allowed open files per process. This might be capped additionally if the OS just doesn't allow the creation of further threads at runtime. Threading is limited by a lot factors including for example the available system memory. dpfTVS will not start with a value smaller than 1. A Value of 1 will disable threading. In case of a very small number of allowed worker threads (especially 1) you should set the keep alive time to 0 and the keep alive number to 1. Not that this will help in case of large files blocking the connection.
- listenlength
Length of listen queue. That's the number of incoming connections that are put on hold before the server automatically rejects new ones. However, this will only reduce the possible number the OS allows. Linux seems normally to support a max length of 1024. I am sure you can change that as well. Default is 1000.
- listen_ip
Listen IP of the server, for example "192.168.0.1". "*" means listen at all addresses the computer has.
- socket
Number of the port you want dpfTVS to listen at (http standard would be 80). Defaults to 80.
- keep_alive
Seconds to wait until an idle persistent connection is closed. Defaults to a setting of 1. The problem is that many browsers use more than 1 connection. For example Opera uses up to 4, while Mozilla related ones use normally 2, but often can be set higher. Those remain open, often unused until they time out. A setting of 0 will still allow multiple requests as long as they are made one after another, what is the usual behaviour if multiple images are loaded for an html page. However, Mozilla for example with a standard setting won't sent a new request until the previous one is completed, timing out the connection rather ungracefully. If you have many users at once and can't waste connections a setting of 0 or 1 might be needed. But for a less extreme situation 17 seconds might give the user a slightly better response time.
- keep_alive_num
Max number of requests per persistent connection until close is forced, 0 for no max. Defaults to 0. A limit can help reducing the response time on high load servers as well as reduce the effect of a possible abuse of persistent connections.
- max_in_pipe
max number of requests gathered in a piped request, 0 for infinit. Defaults to 5. Will not allow more requests than defined with keep_alive_num. A high number of worker threads with infinite keep_alive_num and a high setting here is a possible and easy DOS target. So I wouldn't use any numbers above 5 or perhaps 10. It's up to you though. Just consider that basically no browser really
supports this feature.
- readbuffer
Read buffer length for request bodies in 1000 byte. should be at least 2, 0 is infinite. There is no longer a read buffer. However, incoming POST requests with chunked body encoding have to be temporary saved to disk. To allow an infinite size here can be used to fill up your hdd quickly. But even if the body is only passed on it can be used to infinitly block a connection. So as a precaution I'd use a setting as low as possible. It defaults to 20 (=20000 bytes) what is plenty for most cases. If you only serve GET requests anyway and don't need the POST command you might want to set this to 1.
- sendbuffersize
Size of sendbuffer in bytes, used to pass on content from cgi or mugi scripts. Defaults to 10000. Too low a number will have a negative effect on performance and will together with a disabled Nagle cause a lot small packets, wasting bandwidth. To set this higher than the system internal buffers for pipe and socket connections is not useful either.
- max_cached_size
This value determins how big a file might be(in bytes) to be added to the cache or that's to be sent using the mmap mode. While we see a major speed up for files that reside in the static or half-static cache as well as being sent with mmap rather than sendfile, we have to make sure that we don't exceed the systems real ram at any time. The server has no means to determin when that'll happen until even the swap area is used up completely. The moment the system requires to swap memory in and out, the moment the whole system suffers a major slow down. The default setting is 10000 Bytes.
- versionstring
This is the value CGI programs get as SERVER_SOFTWARE. It is not used beside that, dpfTVS does not transmit such information in its response headers. Default is "unknown".
|