Introduction

The goal of this benchmark is to compare several web server or caching server regarding their respective ability and performance to server small static files. The servers are optimized, contrary to my previous benchmark, where each server was tested using its default settings. I consider in this benchmark only the most performant open source servers, namely Varnish Cache, Nginx, Lighttpd, Apache Traffic Server as well as G-WAN (free, but not open source), as it was the clear winner of the previous test.

Setup

The following version of the software are used for this benchmark:

• Nginx: 0.7.67-3ubuntu1 (64 bit)
• Varnish:  2.1.3-7ubuntu0.1 (64 bit)
• G-WAN: 2.1.20 (32 bit)
• Lighttpd: 1.4.26-3ubuntu2 (64 bit)
• Apache Traffic Server: 2.1.7-unstable (64 bit)

All tests are performed on an ASUS U30JC (Intel Core i3 – 370M @ 2.4 Ghz, Hard drive 5400 rpm, Memory: 4GB DDR3 1066MHz) running Ubuntu 10.10 64 bit (kernel 2.6.35).

Benchmark setup

• HTTP Keep-Alives: enabled
• TCP/IP settings: OS default
• Server settings: default
• Concurrency: from 0 to 1’000, step 10
• Requests: 1’000’000

The following file of 100 byte is used as static content: /var/www/100.html

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

I had to increase the local port range (because of the TIME_WAIT status of the TCP ports), so I’ve edited /etc/sysctl.conf:

net.ipv4.ip_local_port_range = 1024 65535

Disclaimer

Doing a correct benchmark is clearly not an easy task. There are many walls (TCP/IP stack, OS settings, the client itself, …) that may corrupt the results, and there is always the risk to compare apples with oranges (e.g. benchmarking the TCP/IP stack instead of the server itself).

In this benchmark, every server is tested using optimized settings. However, the OS has not been optimized.  If you have comments, improvements, ideas, tips regarding the optimization of a server, please feel free to contact me, I’m always open to improve myself and to learn new things.

Client

The client (available here: http://gwan.ch/source/ab.c.txt) relies on ApacheBench (ab). The client as well as the web server tested are hosted on the same computer.

I’ve evaluated Funkload, but even in a distributed setting, it was not able to saturate the servers. Moreover, I’ve also considered using httperf, but because I had to wait 60 seconds between 2 tests (due to the TIME_WAIT status of the TCP ports), I finally used ApacheBench. Using the latter is also interesting to compare the performance of a server with its default settings or with optimized setings.

Varnish

Configuration:

Based on advices from a Varnish developer and from the Varnish web site, I use the following configuration:

thread_pool_add_delay = 2
thread_pools = 4
thread_pool_min = 200
thread_pool_max = 4000
cli_timeout = 25
session_linger = 100
malloc = 1G

The relevant part of /etc/default/varnish:

DAEMON_OPTS="-a :6081 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -p thread_pool_add_delay=2 \
             -p thread_pools=4 \
             -p thread_pool_min=200 \
             -p thread_pool_max=4000 \
             -p cli_timeout=25 \
             -p session_linger=100 \
             -s malloc,1G"

Finally, as my hard drive is quite slow, I mounted the varnish folder as a tmpfs:

sudo mount -t tmpfs -o size=512M tmpfs /var/lib/varnish

Results:

Let’s start with the output of varnishstat -1:

client_conn            504312       359.20 Client connections accepted
client_drop                 0         0.00 Connection dropped, no sess/wrk
client_req           20443932     14561.21 Client requests received
cache_hit            20443919     14561.20 Cache hits
cache_hitpass               0         0.00 Cache hits for pass
cache_miss                 13         0.01 Cache misses
backend_conn               12         0.01 Backend conn. success
backend_unhealthy            0         0.00 Backend conn. not attempted
backend_busy                0         0.00 Backend conn. too many
backend_fail                0         0.00 Backend conn. failures
backend_reuse               1         0.00 Backend conn. reuses
backend_toolate            11         0.01 Backend conn. was closed
backend_recycle            13         0.01 Backend conn. recycles
backend_unused              0         0.00 Backend conn. unused
fetch_head                  0         0.00 Fetch head
fetch_length               13         0.01 Fetch with Length
fetch_chunked               0         0.00 Fetch chunked
fetch_eof                   0         0.00 Fetch EOF
fetch_bad                   0         0.00 Fetch had bad headers
fetch_close                 0         0.00 Fetch wanted close
fetch_oldhttp               0         0.00 Fetch pre HTTP/1.1 closed
fetch_zero                  0         0.00 Fetch zero len
fetch_failed                0         0.00 Fetch failed
n_sess_mem               1689          .   N struct sess_mem
n_sess                    682          .   N struct sess
n_object                    0          .   N struct object
n_vampireobject             0          .   N unresurrected objects
n_objectcore              986          .   N struct objectcore
n_objecthead              987          .   N struct objecthead
n_smf                       0          .   N struct smf
n_smf_frag                  0          .   N small free smf
n_smf_large                 0          .   N large free smf
n_vbe_conn                  1          .   N struct vbe_conn
n_wrk                     986          .   N worker threads
n_wrk_create              986         0.70 N worker threads created
n_wrk_failed                0         0.00 N worker threads not created
n_wrk_max                   0         0.00 N worker threads limited
n_wrk_queue                 0         0.00 N queued work requests
n_wrk_overflow           2710         1.93 N overflowed work requests
n_wrk_drop                  0         0.00 N dropped work requests
n_backend                   1          .   N backends
n_expired                  13          .   N expired objects
n_lru_nuked                 0          .   N LRU nuked objects
n_lru_saved                 0          .   N LRU saved objects
n_lru_moved               554          .   N LRU moved objects
n_deathrow                  0          .   N objects on deathrow
losthdr                  5622         4.00 HTTP header overflows
n_objsendfile               0         0.00 Objects sent with sendfile
n_objwrite           20394256     14525.82 Objects sent with write
n_objoverflow               0         0.00 Objects overflowing workspace
s_sess                 504312       359.20 Total Sessions
s_req                20443932     14561.21 Total Requests
s_pipe                      0         0.00 Total pipe
s_pass                      0         0.00 Total pass
s_fetch                    13         0.01 Total fetch
s_hdrbytes         5971552835   4253242.76 Total header bytes
s_bodybytes        2044393490   1456120.72 Total body bytes
sess_closed            490612       349.44 Session Closed
sess_pipeline               0         0.00 Session Pipeline
sess_readahead              0         0.00 Session Read Ahead
sess_linger          20443932     14561.21 Session Linger
sess_herd               14205        10.12 Session herd
shm_records         696623209    496170.38 SHM records
shm_writes           21973040     15650.31 SHM writes
shm_flushes                 0         0.00 SHM flushes due to overflow
shm_cont               234697       167.16 SHM MTX contention
shm_cycles                201         0.14 SHM cycles through buffer
sm_nreq                     0         0.00 allocator requests
sm_nobj                     0          .   outstanding allocations
sm_balloc                   0          .   bytes allocated
sm_bfree                    0          .   bytes free
sma_nreq                   26         0.02 SMA allocator requests
sma_nobj                    0          .   SMA outstanding allocations
sma_nbytes                  0          .   SMA outstanding bytes
sma_balloc              11121          .   SMA bytes allocated
sma_bfree               11121          .   SMA bytes free
sms_nreq                    0         0.00 SMS allocator requests
sms_nobj                    0          .   SMS outstanding allocations
sms_nbytes                  0          .   SMS outstanding bytes
sms_balloc                  0          .   SMS bytes allocated
sms_bfree                   0          .   SMS bytes freed
backend_req                13         0.01 Backend requests made
n_vcl                       1         0.00 N vcl total
n_vcl_avail                 1         0.00 N vcl available
n_vcl_discard               0         0.00 N vcl discarded
n_purge                     1          .   N total active purges
n_purge_add                 1         0.00 N new purges added
n_purge_retire              0         0.00 N old purges deleted
n_purge_obj_test            0         0.00 N objects tested
n_purge_re_test             0         0.00 N regexps tested against
n_purge_dups                0         0.00 N duplicate purges removed
hcb_nolock           20417076     14542.08 HCB Lookups without lock
hcb_lock                    3         0.00 HCB Lookups with lock
hcb_insert                  3         0.00 HCB Inserts
esi_parse                   0         0.00 Objects ESI parsed (unlock)
esi_errors                  0         0.00 ESI parse errors (unlock)
accept_fail                 0         0.00 Accept failures
client_drop_late            0         0.00 Connection dropped late
uptime                   1404         1.00 Client uptime

Nginx

Configuration:

The main optimization for Nginx is to adapt the number of worker processes to the number of cores of your server. In my case, I have a dual core processor (i.e. seen as 4 virtual cores), and therefore I changed the value of worker_processes. Based on the useful comments of Igor Sysoev, I also turned off logging and compression, and added open_file_cache:

File /etc/nginx/nginx.conf

user www-data;
worker_processes  2; # or 4
error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;
events {
    worker_connections  1024;
    # multi_accept on;
}
http {
    include       /etc/nginx/mime.types;
    access_log	off;
    open_file_cache max=1000 inactive=20s;
    open_file_cache_valid 30s;
    open_file_cache_min_uses 2;
    sendfile        off;
    #tcp_nopush     on;
    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay        on;
    gzip  off;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

File /etc/nginx/sites-enabled/default

server {
        listen   80; ## listen for ipv4
        server_name  localhost;
        access_log  off;
        location / {
                root   /var/www;
                index  index.html index.htm;
        }
}

Nginx 1.0 was compiled by hand with the following configuration:

./configure --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/
body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx
/proxy --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-ipv6 --without-http_charset_module --without-http_ssi_m
odule --without-http_userid_module --without-http_autoindex_module --without-http_rewrite_module --without-http_limit_zone_module --
without-http_limit_req_module

Results:

Let’s start with 2 worker processes on Nginx 0.7.67

Now with 4 worker processes on Nginx 0.7.67:

Let’s compare with 2 worker processes on Nginx 1.0

Now with 4 worker processes on Nginx 1.0:

Lighttpd

Configuration:

The optimizations for Lighttpd are based on the official documentation as well as a blog entry.

File /etc/lighttpd/lighttpd.conf

server.document-root       = "/var/www/"
server.upload-dirs = ( "/var/cache/lighttpd/uploads" )
server.errorlog            = "/var/log/lighttpd/error.log"
index-file.names           = ( "index.php", "index.html",
                               "index.htm", "default.htm",
                               "index.lighttpd.html" )
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
server.pid-file            = "/var/run/lighttpd.pid"
dir-listing.encoding        = "utf-8"
server.dir-listing          = "enable"
server.username            = "www-data"
server.groupname           = "www-data"
compress.cache-dir          = "/var/cache/lighttpd/compress/"
compress.filetype           = ("text/plain", "text/html", "application/x-javascript", "text/css")
include_shell "/usr/share/lighttpd/create-mime.assign.pl"
include_shell "/usr/share/lighttpd/include-conf-enabled.pl"
# Performance tuning
server.max-fds = 10000
server.event-handler = "linux-sysepoll"
server.network-backend = "linux-sendfile"
server.stat-cache-engine = "fam"
server.use-noatime = "enable"
server.max-worker = 2 # or 4

Results:

Let’s start with 2 worker processes:

Now with 4 worker processes:

Apache Traffic Server

Configuration:

According to the documentation, Traffic Server does not require special optimizations.

File /usr/local/etc/trafficserver/storage.config

var/trafficserver 256M

The file /usr/local/etc/trafficserver/records.config contains a lot of properties. Just check that the following entries are configured to support the reverse proxy mode, and disable logging:

CONFIG proxy.config.reverse_proxy.enabled INT 1
CONFIG proxy.config.proxy_name STRING nico-laptop # <your hostname>
CONFIG proxy.config.log.logging_enabled INT 0

Let’s configure the mapping in the file /usr/local/etc/trafficserver/remap.config:

map          http://127.0.0.1:8080/      http://127.0.0.1/

Nginx is used as the backend server on port 80/tcp.

Results:

G-WAN

Configuration:

Except running G-WAN with root priviledges, nothing has to be done to further optimize the performance:

sudo ./gwan

Results:

Discussion

Minimum RPS

Average RPS

Maximum RPS

CPU Usage

Memory Usage

Conclusion

G-WAN seems again to perform a lot better than the other servers.  Nginx always performs slightly better than Lighttpd, while Apache Traffic server is very similar to Lighttpd in term of performance. Finally, Varnish Cache serves only half of the requests compared to all others. Surprisingly , there are quite few differences between the results with optimized settings and those with the default settings.

Regarding the resources used by each server, Nginx is the winner in term of memory usage, as the amount of memory does not increases with the number of concurrent clients. G-WAN requires 2 times less CPU than the other servers.

Again, keep in mind that this benchmark compares only the servers locally (no networking is involved), and therefore the results might be misleading.

Introduction

Apache is the de facto web server on Unix system. Nginx is nowadays a popular and performant web server for serving static files (i.e. static html pages, CSS files, Javascript files, pictures, …). On the other hand, Varnish Cache is increasingly used to make websites “fly” by caching static content in memory. Recently, I came across a new application server called G-WAN. I’m only interested here in serving static content, even if G-WAN is also able to serve dynamic content, using ANSI C scripting. Finally, I also included Cherokee in the benchmark.

Setup

The following version of the software are used for this benchmark:

• Apache MPM-worker: 2.2.16-1ubuntu3.1 (64 bit)
• Apache MPM-event: 2.2.16-1ubuntu3.1 (64 bit)
• Nginx: 0.7.67-3ubuntu1 (64 bit)
• Varnish:  2.1.3-7ubuntu0.1 (64 bit)
• G-WAN: 2.1.20 (32 bit)
• Cherokee: 1.2.1-1~maverick~ppa1 (64 bit)

All tests are performed on an ASUS U30JC (Intel Core i3 – 370M @ 2.4 Ghz, Hard drive 5400 rpm, Memory: 4GB DDR3 1066MHz) running Ubuntu 10.10 64 bit (kernel 2.6.35).

Benchmark setup

• HTTP Keep-Alives: enabled
• TCP/IP settings: OS default
• Server settings: default
• Concurrency: from 0 to 1’000, step 10
• Requests: 1’000’000

The following file of 100 byte is used as static content: /var/www/100.html

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Disclaimer

Doing a correct benchmark is clearly not an easy task. There are many walls (TCP/IP stack, OS settings, the client, …) that may corrupt the results, and there is always the risk to compare apples with oranges (e.g. benchmarking the TCP/IP stack instead of the server itself).

In this benchmark, every server is tested using its default settings. The same applies for the OS. Of course, on a production environment, each setting will be optimized. This has been done in a second benchmark. If you have comments, improvements, ideas, please feel free to contact me, I’m always open to improve myself and to learn new things.

Client

The client (available here: http://gwan.ch/source/ab.c.txt) relies on ApacheBench (ab). The client as well as the web server tested are hosted on the same computer.

Apache (MPM-worker)

Configuration

Relevant part of file /etc/apache2/apache2.conf

    StartServers          2
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadLimit          64
    ThreadsPerChild      25
    MaxClients          150
    MaxRequestsPerChild   0

Benchmark results

The benchmark took 1174 seconds in total.

Apache (MPM-event)

Configuration

Relevant part of file /etc/apache2/apache2.conf

    StartServers          2
    MaxClients          150
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadLimit          64
    ThreadsPerChild      25
    MaxRequestsPerChild   0

Benchmark results

The benchmark took 1904 seconds in total.

Nginx

Configuration

File /etc/nginx/nginx.conf

user www-data;
worker_processes  1;
error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;
events {
    worker_connections  1024;
    # multi_accept on;
}
http {
    include       /etc/nginx/mime.types;
    access_log  /var/log/nginx/access.log;
    sendfile        on;
    #tcp_nopush     on;
    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay        on;
    gzip  on;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";
    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

File /etc/nginx/sites-enabled/default

server {
        listen   80; ## listen for ipv4
        server_name  localhost;
        access_log  /var/log/nginx/localhost.access.log;
        location / {
                root   /var/www;
                index  index.html index.htm;
        }
}

Benchmark results

The benchmark took 1048 seconds in total.

Varnish

Varnish uses Nginx as backend. However, only one request every 2 minutes hits Nginx, the other requests are served directly by Varnish.

Configuration

File /etc/varnish/default.vcl

backend default {
   .host = "127.0.0.1";
   .port = "80";
}

File /etc/default/varnish

START=yes
NFILES=131072
MEMLOCK=82000
INSTANCE=$(uname -n)
DAEMON_OPTS="-a :6081 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,1G"

Benchmark results

Run: 1
The benchmark took 1297 seconds in total.

Run: 2
The benchmark took 1313 seconds in total.

As some people requested more details regarding the benchmark of Varnish, here is the output of varnishstat -1:

client_conn            504664       281.31 Client connections accepted
client_drop                 0         0.00 Connection dropped, no sess/wrk
client_req           20245482     11285.11 Client requests received
cache_hit            20245471     11285.10 Cache hits
cache_hitpass               0         0.00 Cache hits for pass
cache_miss                 11         0.01 Cache misses
backend_conn               11         0.01 Backend conn. success
backend_unhealthy            0         0.00 Backend conn. not attempted
backend_busy                0         0.00 Backend conn. too many
backend_fail                0         0.00 Backend conn. failures
backend_reuse               0         0.00 Backend conn. reuses
backend_toolate            10         0.01 Backend conn. was closed
backend_recycle            11         0.01 Backend conn. recycles
backend_unused              0         0.00 Backend conn. unused
fetch_head                  0         0.00 Fetch head
fetch_length                0         0.00 Fetch with Length
fetch_chunked              11         0.01 Fetch chunked
fetch_eof                   0         0.00 Fetch EOF
fetch_bad                   0         0.00 Fetch had bad headers
fetch_close                 0         0.00 Fetch wanted close
fetch_oldhttp               0         0.00 Fetch pre HTTP/1.1 closed
fetch_zero                  0         0.00 Fetch zero len
fetch_failed                0         0.00 Fetch failed
n_sess_mem               2963          .   N struct sess_mem
n_sess                   1980          .   N struct sess
n_object                    0          .   N struct object
n_vampireobject             0          .   N unresurrected objects
n_objectcore              393          .   N struct objectcore
n_objecthead              393          .   N struct objecthead
n_smf                       2          .   N struct smf
n_smf_frag                  0          .   N small free smf
n_smf_large                 2          .   N large free smf
n_vbe_conn                  1          .   N struct vbe_conn
n_wrk                     396          .   N worker threads
n_wrk_create              500         0.28 N worker threads created
n_wrk_failed                0         0.00 N worker threads not created
n_wrk_max              118979        66.32 N worker threads limited
n_wrk_queue                 0         0.00 N queued work requests
n_wrk_overflow         133755        74.56 N overflowed work requests
n_wrk_drop                  0         0.00 N dropped work requests
n_backend                   1          .   N backends
n_expired                  11          .   N expired objects
n_lru_nuked                 0          .   N LRU nuked objects
n_lru_saved                 0          .   N LRU saved objects
n_lru_moved               557          .   N LRU moved objects
n_deathrow                  0          .   N objects on deathrow
losthdr                  7470         4.16 HTTP header overflows
n_objsendfile               0         0.00 Objects sent with sendfile
n_objwrite           20215571     11268.43 Objects sent with write
n_objoverflow               0         0.00 Objects overflowing workspace
s_sess                 504664       281.31 Total Sessions
s_req                20245482     11285.11 Total Requests
s_pipe                      0         0.00 Total pipe
s_pass                      0         0.00 Total pass
s_fetch                    11         0.01 Total fetch
s_hdrbytes         5913383706   3296200.51 Total header bytes
s_bodybytes         526382532    293412.78 Total body bytes
sess_closed            382711       213.33 Session Closed
sess_pipeline               0         0.00 Session Pipeline
sess_readahead              0         0.00 Session Read Ahead
sess_linger          20245482     11285.11 Session Linger
sess_herd              124222        69.24 Session herd
shm_records         689986796    384608.02 SHM records
shm_writes           21885539     12199.30 SHM writes
shm_flushes                 0         0.00 SHM flushes due to overflow
shm_cont               282730       157.60 SHM MTX contention
shm_cycles                200         0.11 SHM cycles through buffer
sm_nreq                    22         0.01 allocator requests
sm_nobj                     0          .   outstanding allocations
sm_balloc                   0          .   bytes allocated
sm_bfree           1073741824          .   bytes free
sma_nreq                    0         0.00 SMA allocator requests
sma_nobj                    0          .   SMA outstanding allocations
sma_nbytes                  0          .   SMA outstanding bytes
sma_balloc                  0          .   SMA bytes allocated
sma_bfree                   0          .   SMA bytes free
sms_nreq                    0         0.00 SMS allocator requests
sms_nobj                    0          .   SMS outstanding allocations
sms_nbytes                  0          .   SMS outstanding bytes
sms_balloc                  0          .   SMS bytes allocated
sms_bfree                   0          .   SMS bytes freed
backend_req                11         0.01 Backend requests made
n_vcl                       1         0.00 N vcl total
n_vcl_avail                 1         0.00 N vcl available
n_vcl_discard               0         0.00 N vcl discarded
n_purge                     1          .   N total active purges
n_purge_add                 1         0.00 N new purges added
n_purge_retire              0         0.00 N old purges deleted
n_purge_obj_test            0         0.00 N objects tested
n_purge_re_test             0         0.00 N regexps tested against
n_purge_dups                0         0.00 N duplicate purges removed
hcb_nolock           20219699     11270.74 HCB Lookups without lock
hcb_lock                    1         0.00 HCB Lookups with lock
hcb_insert                  1         0.00 HCB Inserts
esi_parse                   0         0.00 Objects ESI parsed (unlock)
esi_errors                  0         0.00 ESI parse errors (unlock)
accept_fail                 0         0.00 Accept failures
client_drop_late            0         0.00 Connection dropped late
uptime                   1794         1.00 Client uptime

G-WAN

Configuration

The configuration of G-WAN is done through the file hierarchy. Therefore, unzipping the G-WAN archive was enough to have a fully working server.

Benchmark results

The benchmark took 607 seconds in total.

Cherokee

Configuration

Relevant part of file /etc/cherokee/cherokee.conf

# Server
#
server!bind!1!port = 80
server!timeout = 15
server!keepalive = 1
server!keepalive_max_requests = 500
server!server_tokens = full
server!panic_action = /usr/share/cherokee/cherokee-panic
server!pid_file = /var/run/cherokee.pid
server!user = www-data
server!group = www-data

# Default virtual server
#
vserver!1!nick = default
vserver!1!document_root = /var/www
vserver!1!directory_index = index.html

Benchmark results

The benchmark took 1068 seconds in total.

Discussion

Let’s now compare the minimum, the average and the maximum requests per second rate of each server.

Minimum RPS

Average RPS

Maximum RPS

Conclusion

G-WAN is the clear winner of this benchmark, while Nginx and Varnish have simliar average performance. It’s not a real surprise to see Apache at the last position.

• G-WAN can serve 2.25 times more requests per second on average compared to Cherokee, from 4.25 to 6.5 times compared to Nginx and Varnish, and from 9 to 13.5 times more than Apache.
• Nginx / Varnish can serve 2.1 times more requests per second on average compared to Apache.
• Nginx needs 1.73 more time to serve the same amount of requests compared to G-WAN.
• Varnish needs 2.14 more time to serve the same amount of requests compared to G-WAN.
• Apache needs 1.93 more time to serve a similar amount of requests compared to G-WAN (i.e. Apache sometimes replied with an error 503 and didn’t serve the exact same amount of requests).

Again, keep in mind that this benchmark compares only the servers with their out of the box settings locally (no networking is involved), and therefore the results might be misleading.

#!/bin/bash

current_directory=$( pwd )

#remove spaces
for i in *.wma; do mv "$i" `echo $i | tr ' ' '_'`; done

#remove uppercase
for i in *.[Ww][Mm][Aa]; do mv "$i" `echo $i | tr '[A-Z]' '[a-z]'`; done

#Rip with Mplayer / encode with LAME
for i in *.wma ; do mplayer -vo null -vc dummy -af resample=44100 -ao pcm:waveheader $i && lame -m s audiodump.wav -o $i; done

#convert file names
for i in *.wma; do mv "$i" "`basename "$i" .wma`.mp3"; done

rm audiodump.wav

ABSTRACT

The system-to-administrator ratio is commonly used as a rough metric to understand adminis-

trative costs in high-scale services. With smaller, less automated services this ratio can be as low as

2:1, whereas on industry leading, highly automated services, we’ve seen ratios as high as 2,500:1.

Within Microsoft services, Autopilot [1] is often cited as the magic behind the success of the Win-

dows Live Search team in achieving high system-to-administrator ratios. While auto-administration

is important, the most important factor is actually the service itself. Is the service efficient to auto-

mate? Is it what we refer to more generally as operations-friendly? Services that are operations-

friendly require little human intervention, and both detect and recover from all but the most obscure

failures without administrative intervention. This paper summarizes the best practices accumulated

over many years in scaling some of the largest services at MSN and Windows Live.

Zoie is a mature open source project and has been deployed in a real-time large-scale consumer website: LinkedIn.com handling millions of searches as well as hundreds of thousands of updates daily.

All Zoie releases have gone through extensive functional and performance testing by LinkedIn before made public. All major versions are released after a trial period on the production environment.

In a real-time search/indexing system, a document is made available as soon as it is added to the index. This functionality is especially important to time-sensitive information such as news, job openings, tweets etc.

1. Thinking Scalability Is Just About Technology;

2. Overuse of Synchronous Calls;

3. Failure to Weed or Seed Soon Enough;

4. Inappropriate Use of Databases;

5. Cesspools Instead of Swim Lanes;

6. Reliance on Vertical Scale;

7. Failure to Learn from History;

8. Changing Development Methodologies to Fix Problems;

9. Too Little Caching, Too Late;

10. Overreliance on Third Parties to Scale.