Comments on running webservers at home – Part 1

I like to experiment all kind of computer technologies especially server applications. I am not one of those who is satisfied with just making a website and putting it in somewhere. I like the full control of the server because I like to try different combination of applications for performance tuning. For example, I doubt regular web hosting company allows you to host the entire system on a ram disk with a reasonable price tag. That’s why I choose to host a server at home. That’s a lot cheaper, plus I have the full control. However, running server application may generate lots of upstream traffic. That’s why most internet server providers (such as Charter) do not allow their customers to run any server related applications using their internet connection service. They do it by blocking most service related common ports, e.g., 80 (HTTP), 21 (FTP), 22 (SSH) etc. So there is really nothing you can do other than hosting your applications on different ports.

Two years ago, I started hosting all of my websites using my own computers. I found a number of benefits.

Benefits of hosting websites at home

1. It saves me tons of money.

I was paying $72/year per domain for web hosting. Since I have more than ten domains, the total running costs per year is pretty high. This amount is really nothing comparing to the cost of the electricity.

Monthly cost for web hosting:

$72 per domain/yr * 10 domains / 12 months
= $60 per domain / month

My monthly electricity cost at home, which includes everything such as running 10 non-gaming computers, washer, dryer, lighting etc:

$80 / month

I haven’t tried measuring the exact energy but you can imagine the electricity used by computers should be under $10 / month.

2. It is fun (and environmental friendly too).

I have few stone-age computers including a Pentium II laptop, a Mac G3 (speed wise similar to Pentium II), a Pentium M Celeron laptop etc. I integrated them to a web server farm (web clusters). Since running a web server does not require a lot of CPU power, they are doing okay for hosting low-traffic websites. Also, it is cool to show off my friends the global data center that I build for my websites.

3. Your data is secured!

Have you ever heard of any bank host their web sites on web hosting? No matter what type of encryption you use for your web applications, you still need to process the raw, original, and unencrypted data on the server side at one point. Processing confidential information on a shared server is like talking your secrets in a study room in a public library. You think you are in an isolated environment, but you can be surveillanced, it’s very simple and easy.

Here is an example:
Supposes I have a web application which accepts the confidential information from my users, and all traffics are encrypted. After the confidential information is decrypted on the server-side, my web application processes the raw information and do further things.

Let’s say the server environment is Apache + PHP + MySQL, the most popular combination of web application environment. Since they are all open-source, it is very easy to modify the source codes and log every single thing into a file, including the raw, original, unencrypted data processed by my web application.

You may think this may require lots of work and it will never happen on you. What if your competitor wants your confidential information? It doesn’t cost much to hire someone to do it.

Sounds scary?

More scary things come along. Shared web hosting (hosting multiple domains on one single server) always come with lots of trouble that many people are ignored. In theory, every website on a shared hosting lives in a virtual, independent environment, think about it as a virtual machine like VMWare or Hyper-V. Practically, it is not easy to set up such environment (e.g., FreeBSD Jail) and many web hosting companies choose to go with a less difficult path, because customers will not realize it anyway. Now here is the interesting part, supposes my domain and your domain are hosted on the same server. I can access the resource at the operating system level first (which will required some hacking), then access your file after that. Now I have access your source code and I can do whatever I want.

The most secure place in the world is the place that can be accessed by you, and no body else, i.e., your home, or any place you have full control

Our sponsors:

fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ngx-fancyindex-0.2.2.tar.bz2: File unavailable (e.g., file not found, no access)

Today I tried to run the upgrade my nginx on my FreeBSD box, and I received the following message:

===>  Vulnerability check disabled, database not found
===>  License accepted by the user
===>  Found saved configuration for nginx-0.7.66
=> ngx-fancyindex-0.2.2.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/.
=> Attempting to fetch from http://connectical.com/attachments/download/26/.
fetch: http://connectical.com/attachments/download/26/ngx-fancyindex-0.2.2.tar.bz2: Not Found
=> Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/.
fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/ngx-fancyindex-0.2.2.tar.bz2: File unavailable (e.g., file not found, no access)
=> Couldn't fetch it - please try to retrieve this
=> port manually into /usr/ports/distfiles/ and try again.

Obviously, the FreeBSD box could not download the file. To fix this problem, simply run the following commands:

cd /usr/ports/distfiles/
sudo wget http://files.connectical.com/gentoo/ngx-fancyindex-0.2.2.tar.bz2

This will allow FreeBSD to skip downloading the file from a wrong URL. Now, go back to the nginx port:

cd /usr/ports/www/nginx

and try to install nginx again:

sudo make install clean

Our sponsors:

nginx vs Tornado Web vs Apache Performance Benchmark

Let’s put the nginx, Tornado and Apache and see who is the winner.

What to test:

A simple Hello World webpage.

How:

ab -n 10000 -c 300 http://myserver.ip

Test Environment:

OS: Ubuntu 9.10 (32-bit) / Linux 2.6.31
CPU: Pentium Celeron M 1.5 GHz
Ram: 512 MB
Apache: 2.2.12
PHP: 5.2.10
Python: 2.6
Tornado: 0.2
nginx: 0.6.13

Result:

Apache

Server Software:        Apache/2.2.12
Server Port:            80

Document Path:          /
Document Length:        13 bytes

Concurrency Level:      300
Time taken for tests:   5.295 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      2863146 bytes
HTML transferred:       130143 bytes
Requests per second:    1888.58 [#/sec] (mean)
Time per request:       158.850 [ms] (mean)
Time per request:       0.529 [ms] (mean, across all concurrent requests)
Transfer rate:          528.05 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    8 151.0      0    3028
Processing:     0  122 602.0     48    5289
Waiting:        0  122 600.8     48    5284
Total:         10  130 622.1     49    5292

Percentage of the requests served within a certain time (ms)
  50%     49
  66%     50
  75%     50
  80%     51
  90%     53
  95%     63
  98%     68
  99%   5271
 100%   5292 (longest request)

nginx

Server Software:        nginx/0.6.13
Server Port:            8000

Document Path:          /
Document Length:        13 bytes

Concurrency Level:      300
Time taken for tests:   3.172 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      2230000 bytes
HTML transferred:       130000 bytes
Requests per second:    3152.12 [#/sec] (mean)
Time per request:       95.174 [ms] (mean)
Time per request:       0.317 [ms] (mean, across all concurrent requests)
Transfer rate:          686.45 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2  68.3      0    3057
Processing:     0   70 359.1     27    3164
Waiting:        0   70 359.1     26    3164
Total:         10   72 365.6     27    3169

Percentage of the requests served within a certain time (ms)
  50%     27
  66%     27
  75%     27
  80%     27
  90%     28
  95%     29
  98%     32
  99%   3157
 100%   3169 (longest request)

Tornado Web:

Server Software:        TornadoServer/0.1
Server Port:            8888

Document Path:          /
Document Length:        12 bytes

Concurrency Level:      300
Time taken for tests:   5.109 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      1680000 bytes
HTML transferred:       120000 bytes
Requests per second:    1957.33 [#/sec] (mean)
Time per request:       153.270 [ms] (mean)
Time per request:       0.511 [ms] (mean, across all concurrent requests)
Transfer rate:          321.12 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   32 309.3      0    3035
Processing:    33  103  28.5    103     375
Waiting:       33  102  28.5    103     375
Total:         36  135 311.3    103    3154

Percentage of the requests served within a certain time (ms)
  50%    103
  66%    105
  75%    108
  80%    112
  90%    116
  95%    126
  98%    313
  99%   3121
 100%   3154 (longest request)

What do these numbers mean?

In a given time, if nginx and Tornado Web can handle 1.66 and 1.036 times more requests than Apache, respectively! In the other words, the server is more efficient and it can use the saved resource to do something else!

–Derrick

Our sponsors: