Lighttpd configuration and performance optimization

Premise: for web applications with high load, static pages, and freebsd systems. I think it is difficult to select between LSWS (LiteSpeedWebServer) and lighttpd. It is difficult to have an authoritative statement from the existing online materials. Because there is no special standard for testing. For example, in the current situation, is the configuration of webserver optimal? even if you only test the one-in-one webserver, you will find that the same configuration is continuously tested.

Premise: for web applications with high load, static pages, and freebsd systems.
I think it is difficult to select between LSWS (LiteSpeed Web Server) and lighttpd. It is difficult to have an authoritative statement from the existing online materials. Because there is no special standard for testing. For example, in the current situation, is the configuration of the web server optimal? even if you only test the one-in-one webserver, you will find that the same configuration is continuously tested, their results may fluctuate. Therefore, it may be difficult to tell which configuration is the best and suitable for the current situation. In this case, we can only go through a lot of repeated experiments and observations.
The following is a test chart of the LSWS official website. we can see that LSWS and lighttpd are not very bad in keep alive. of course, they do not rule out their own web server bias, or they are more familiar with their complete server configuration.

In terms of the technology used, lighttpd uses Linux 2.6 + epoll, while FreeBSD uses kqueue. By default, poll is used, and our system is freebsd. Unfortunately, when I use the kqueue feature on bsd, the test results show that the efficiency is significantly lower. I don't want to understand why I don't have enough time to read c10k articles. I can make a reference.
For more infomation in this topic take a look at http://www.kegel.com/c10k.html
The other is the sendfile () technology, which can minimize the work done by the application and directly send a file to the NIC.
Using sendfile64 on Linux 2.6 +, we can see that many small httpd currently support Linux 2.6 + well, such as tux.
Make some modifications to the configuration file for our applications. Time per request: up to 0.65 [MS] relative to the previous test of 0.734 [MS] about, performance has greatly improved. If there is a lot of time to test each performance indicator, remove unnecessary modules and features, it should be improved in performance, it is estimated that it is best to reach 0.61 [MS. Recent tests are as follows:
Lighttpd configuration file: removes many unnecessary features.
####### Lighttpd. conf.
Server. port = 7983
Server. modules = ("mod_access ")
Server.doc ument-root = "/usr/home/yangjian/lighttpd/doc /"
Server. pid-file = "/usr/home/yangjian/lighttpd. pid"
Mimetype. assign = (
Pai.html "=>" text/html ",
". Js" => "text/javascript ",
)
Server. max-keep-alive-requests = 4000
Dir-listing.activate = "disable"
Test intensity:./AB-n 100000-c 1000 http: // 192.168.241.109: 7983/index.html
Server Software: lighttpd/1.4.7
Server Hostname: 192.168.241.109
Server Port: 7983
Document Path:/index.html
Document Length: 449 bytes
Concurrency Level: 1000
Time taken for tests: 65.180092 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 68281158 bytes
HTML transferred: 44953431 bytes
Requests per secondd: 1534.21 [#/sec] (mean)
Time per request: 651.801 [MS] (mean)
Time per request: 0.652 [MS] (mean, internal SS all concurrent requests)
Transfer rate: 1023.01 [Kbytes/sec] canceled ed
LiteSpeed is tested under the default configuration. Its results are not stable, and the best record is 0.603 ms. This is not a good result for lighttpd, but in most cases it is around 0.70, and it is more than 0.76 many times. I'm talking about LiteSpeed's standard edition. pro is costly, of course, better performance. LiteSpeed is the same as web management, which is a better feature. If it is optimized, I think it and lighttpd should be consistent.
For the moment, I will first select lighttpd, which is relatively stable, as our web server, and then describe its configuration and optimization. The Lighttpd configuration file is very simple. I believe you can understand it if you have used apache. I will only discuss the indicators that affect performance. Reference http://www.lighttpd.net/documentation
The configuration file above is very short. I removed all unnecessary features. The added module only has mod_access. if it is not accessed, the system will encounter the 403 error. In addition to this, the default modules enabled by the system include
Mod_indexfiles, mod_dirlisting, and mod_staticfile. However, the list of modules compiled by default is as follows:
It is very easy to enable these compiled files. enable is OK. To add a function to Lighttpd, you only need to add one or two lines of commands to the configuration file, which is easier to configure than apache.
Plugins:
Enabled:
Mod_access
Mod_accesslog
Mod_alias
Mod_auth
Mod_cgi
Mod_compress
Mod_dirlisting
Mod_evhost
Mod_expire
Mod_fastcgi
Mod_indexfiles
Mod_proxy
Mod_rrdtool
Mod_scgi
Mod_secdownload
Mod_setenv
Mod_simple_vhost
Mod_staticfile
Mod_status
Mod_userdir
Mod_usertrack
Mod_webdav
Disabled:
Mod_crf
Mod_mysql_vhost
Mod_redirect
Mod_rewrite
Mod_ssi
Mod_trigger_b4_dl
Features:
Enabled:
Auth-crypt
Compress-bzip2
Compress-deflate
Compress-gzip
Large-files
Network-ipv6
Disabled:
Auth-ldap
Network-openssl
Regex-conditionals
Stat-cache-fam
Storage-gdbm
Storage-memcache
Webdav-properties
The role of each module is similar to that mentioned in the performance optimization of apache I wrote last time. So I think the performance should be improved if only the core functions are retained. Configuration options:
Server. chroot
The root directory of the web server when chroot is used to improve security. Recommended.
Server. username = "…" Server. groupname = "…"
Give up the root permission.
Dir-listing.activate
List directories if the index file is not found. Disable is recommended.
Server. event-handler
Set the time processing method. Default: "poll ". By default, kqueue can be used on Bsd, which affects the efficiency. The cause is unknown. The methods for operating systems are as follows:
OS Method Config-Value
All select
Unix poll
Linux 2.4 + rt-signals linux-rtsig
Linux 2.6 + epoll linux-sysepoll
Solaris/dev/poll solaris-devpoll
FreeBSD ,... Kqueue freebsd-kqueue
Server. max-request-size
Maximum size in kbytes of the request (header + body)
Default: 2 Gb
Server. max-worker
By default, lighttpd only starts one process, but also supports starting multiple processes like apache. my experiment shows that starting multiple processes at the same time cannot improve the performance.
Server. max-keep-alive-requests
This is critical and has a significant impact on performance. Maximum number of requests that can be processed before the end of a keep-alive session. Default: 128, which is not enough for a high-load application. I used 4000.
Server. max-keep-alive-idle
The maximum number of seconds before an idle keep-alive connection is discarded. Default: 30.

Servers. error-handler-404
The processing when the page cannot be found has no impact on the performance. for example:
Server. error-handler-404 = "/error-404.php"
Server. max-fds
Because lighttpd is a single-threaded server, its main resource limit is the number of file descriptors. the default value is 1024. If you are on a high-load site, you may need to add the limit value through the following settings.
Server. max-fds = 2048, but this restriction takes effect only when lighttpd is running as the root.

Connection. kbytes-per-second, server. kbytes-per-second
It is also worth mentioning that lighttpd can limit the traffic of each connection or specific virtual machine.

Compress. cache-dir, compress. filetype
If the text is slightly larger, you can use the compression algorithm to reduce bandwidth and improve efficiency. For example:
Compress. cache-dir = "/var/www/cache /"
Compress. filetype = ("text/plain", "text/html ")

Server. stat-cache-engine = "fam"
This item can significantly improve the performance, stat () cache. A stat call may be expensive. Set a cache to save time and avoid context switching. Replace stat () every time to determine the existence of the file. it is only stat () once, and then monitors the directory. if the directory remains unchanged, the files in it remain unchanged. Our memory file system does not need to be retained, depending on the situation.
Server. stat-cache-engine = "fam" # either fam, simple or disabled

FreeBSD may improve some performance. if you enable accept-filters, you can only compile your kernel using the following options: options ACCEPT_FILTER_HTTP.
Write so much first, and then enrich the content with the lighttpd application. Welcome to the discussion.