whenpenguinsattack.com

Sunday, April 09, 2006

lighttpd vs apache

By Justin Silverton

What is lighttpd?

it is designed and optimized for high performance environments. With a small memory footprint compared to other web-servers, effective management of the cpu-load, and advanced feature set (FastCGI, CGI, Auth, Output-Compression, URL-Rewriting and many more) LightTPD is the perfect solution for every server that is suffering load problems. And best of all it's Open Source licensed under the revised BSD license.

It can be downloaded Here

PHP Performance

Description

Equipment

  • Netgear GS108 8-Port Switch
  • Server:
    AMD Athlon XP 2000+ (1666 MHz)
    512 Mb RAM
    IBM IC35L060AVVA07-0
    Intel EtherExpress 1000
    Linux 2.6.6
  • Test Host:
    Via Samual 2 (600MHz)
    256 Mb RAM
    Via Rhine III
    (this is a VIA EPIA CL board)

The benchmark follows the rules of:

http://turck-mmcache.sourceforge.net/index_old.html

lighttpd

Concurrency Level:      1
Time taken for tests: 2.209 seconds
Complete requests: 200
Failed requests: 0
Broken pipe errors: 0
Total transferred: 503000 bytes
HTML transferred: 481400 bytes
Requests per second: 90.54 [#/sec] (mean)
Time per request: 11.04 [ms] (mean)
Time per request: 11.04 [ms] (mean, across all concurrent
requests)
Transfer rate: 227.70 [Kbytes/sec] received

Apache

Concurrency Level:      1
Time taken for tests: 2.789 seconds
Complete requests: 200
Failed requests: 0
Broken pipe errors: 0
Total transferred: 518600 bytes
HTML transferred: 480400 bytes
Requests per second: 71.71 [#/sec] (mean)
Time per request: 13.95 [ms] (mean)
Time per request: 13.95 [ms] (mean, across all concurrent
requests)
Transfer rate: 185.94 [Kbytes/sec] received

Doing the test via the loopback-interface on the Server-Host doesn't change the numbers dramaticly (+4-5 req/s)

Conclusion

lighttpd + fastcgi is more than 25% faster than apache + mod_php4.

For static files we already know that lighttpd is 4-6 times faster.

CPU-Utilization

Description

The purpose of the benchmark run was find out which opensource webserver leaves the system enough power to do additional work like handling php request and the like. It allows to estimate how the server would perform in a gigabit network.

Equipment

The network was equipped with really cheap 100Mbit components like

  • Netgear DS108 8-port Hub
  • Server:
    AMD Athlon 1666 MHz
    512 Mb RAM
    IBM IC35L060AVVA07-0
    SiS900
  • Client:
    AMD Duron 1300 MHz
    256 Mb RAM
    Maxtor 33073H3
    SiS900

The benchmark consisted of 8 runs of apache-bench from the client against the server. index.html is about 4kbyte large, dummy.out has a size of 100.000 bytes. Each run is about 10s long for 4k and 60s for 100k.

/usr/sbin/ab    -n 10000 -c  100 http://192.168.2.10:1030/index.html
/usr/sbin/ab -k -n 10000 -c 100 http://192.168.2.10:1030/index.html
/usr/sbin/ab -n 10000 -c 1000 http://192.168.2.10:1030/index.html
/usr/sbin/ab -k -n 10000 -c 1000 http://192.168.2.10:1030/index.html
/usr/sbin/ab -n 5000 -c 100 http://192.168.2.10:1030/dummy.out
/usr/sbin/ab -k -n 5000 -c 100 http://192.168.2.10:1030/dummy.out
/usr/sbin/ab -n 5000 -c 1000 http://192.168.2.10:1030/dummy.out
/usr/sbin/ab -k -n 5000 -c 1000 http://192.168.2.10:1030/dummy.out

Each server was started within 'time' to get the user- and sys-time for the statistics.

time ./lighttpd -D -f ./lighttpd.conf
time ./mathopd -n -f ./mathopd.conf
time ./thttpd -p 1027 -d /home/weigon/wwwroot/servers
/grisu.home.kneschke.de/pages/ -l /dev/null -D
time ./src/boa -d -f boa.conf -c ./

Conclusion

boa performs fine but has a lot of work to do in user-mode when handling 1000 parallel connections. The network saturation for small files can be improved for keep-alive mode.

thttpd can't saturate the 100Mbit network because is still lacking keep-alive support.

lighttpd perfoms fine in all sections. apache uses far to much system resources but is stable. monkey failed in all tests.

mathopd was tested the wrong way and was removed from the benchmark for now.

Results

lighttpd 1.0.2

        con   user         sys        [#/sec]     [Kbytes/sec]
4k file
100 0m0.260s 0m0.880s 1488.54 6889.75
keepalive 100 0m0.260s 0m0.870s 1788.59 8290.74
1000 0m0.350s 0m1.350s 1278.77 5983.60
keepalive 1000 0m0.410s 0m2.380s 1732.20 8333.10

100k files
100 0m0.490s 0m5.730s 81.67 8207.19
keepalive 100 0m0.250s 0m5.620s 85.16 8573.19
1000 0m0.920s 0m48.470s 77.04 8096.55
keepalive 1000 0m0.830s 0m41.480s 79.54 8552.96

thttpd 2.23b

        con   user         sys        [#/sec]     [Kbytes/sec]
4k file
100 0m0.280s 0m0.960s 1481.26 6814.43
1000 0m0.310s 0m1.270s 1300.39 6096.46
100k files
100 0m0.770s 0m5.870s 80.85 8130.32
1000 0m1.360s 0m51.270s 76.92 8085.59

Boa/0.94.14rc16

        con   user         sys        [#/sec]     [Kbytes/sec]
4k file
100 0m0.420s 0m0.940s 1485.00 6778.21
keepalive 100 0m0.300s 0m0.790s 1466.92 6790.01
1000 0m0.330s 0m1.180s 1305.14 5986.00
keepalive 1000 0m0.900s 0m3.360s 1552.07 7529.29

100k files
100 0m1.000s 0m6.330s 81.33 8166.78
keepalive 100 0m0.890s 0m6.240s 85.16 8567.05
1000 0m10.790s 0m47.700s 78.70 8137.15
keepalive 1000 0m10.630s 0m46.600s 82.28 8512.32 [*]
[*] failed requests

Apache 1.3.28


As apache is a (pre-)forking server it is not that easy to measure

the time used by all childs in user- and kernel-mode. That's why we use a
guessed takes from top. This might not be completly correct but should
give you the right impression.

100% CPU Usage means that full 7-8s that the rest runs for the small files
are spent for handling requests. Just check the servers above to see that
same job can be done in 1 second.

          con   CPU Usage               [#/sec]     [Kbytes/sec]
4k file
100 100% 1482.80 6847.20
keepalive 100 80% 1466.92 6790.01
1000 100% 1318.74 6094.71
keepalive 1000 90% 1887.50 8797.84

100k files
100 30% 81.80 8227.11
keepalive 100 30% 86.71 8741.96 [*]
1000 33% 81.80 8258.31
keepalive 1000 33% 90.87 9225.39 [*]
[*] failed requests

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home