Dariusz on Software

Methods and Tools

About This Site

Software development stuff


Entries from February 2014.

Sat, 08 Feb 2014 20:43:09 +0000

logo_sslSSL is used for (1) encrypting HTTP traffic and for (2) authentication server against browser's database of trusted certificates. Generating SSL certificate properly is important if you want your customer to use https properly. It costs few bugs per year, but your customers won't have any warnings in browser before SSL session (purpose number 2).

However, for internal applications, self-signed certificate may be a sufficient solution (purpose 1 only). You will find below a minimal commands to generate local SSL certificate (accept default values when asked for data on stdin): mkdir -p /etc/lighttpd/ssl/local cd /etc/lighttpd/ssl/local openssl genrsa -passout pass:1234 -des3 -out server.key 1024 openssl req -passin pass:1234 -new -key server.key -out server.csr cp server.key server.key.org openssl rsa -passin pass:1234 -in server.key.org -out server.key openssl x509 -req -in server.csr -signkey server.key -out server.crt cat server.key server.crt > server.pem Then lighttpd installation: $SERVER["socket"] == "<YOUR_IP_ADDRESS>:443" { ssl.engine = "enable" ssl.pemfile = "/etc/lighttpd/ssl/local/server.pem" ssl.ca-file = "/etc/lighttpd/ssl/local/server.crt" } Then you have to accept server certificate in your browser and voila!

Tags: httpd, networking, ssl, web.
Thu, 06 Feb 2014 22:47:50 +0000

I'm a very happy Linode.com (an US VPS supplier) customer and my expectations regarding service quality are pretty high. VPS is a virtualization technique that allows to share the same hardware among few operating systems with dedicated IP and root access. Having migration to another server in mind I've decided to give a try our European VPS providers.

One of the biggest hosting providers is OVH. I hope those French guys do better hosting services than cars :-)

Minimum VPS offer is reachable for 5 EUR + VAT / month. It gives you only 512MB of RAM:


Despite the fact that they announce only 64-bit systems I was very surprised to see 32-bits of operating system version as well (at least of my favourite Debian) available:


The biggest benefit of 64-bit systems are (if you have less than 3GB of RAM) is that you get slight performance upgrade, but you have to pay in slightly bigger memory usage. As CPU resources are usually less important for me than available RAM (especially on low-end VPS instance) I've decided to go with 32-bit version then.

We have three locations in Europe available for selection, I went with Strasbourg as it's close to German border (so to Warsaw/Poland):


You can pay monthly, quarterly, twice a year or yearly. I've selected 3 months (to have a chance to evaluate server stability and performance over a longer period).

Manager software at OVH is the ugliest web interface I've ever seen. It opens new window on every possible occasion, is totally littered and it's very hard to find out there anything.


Anyway, I've switched to "new" interface (another one?) to manage new VPS system. Here you have few typical options you can expect from a VPS provider interface:

  • transfer used
  • selected ports status (nice feature, I can say)
  • admin options: reboot, password reset, reinstall, reverse DNS, OS reload, console prompt, offer change

Note that there's only one (primary) IP address available, so you will have some trouble when hosting multiple HTTPS sites.

Let's check what's inside then.

Network parameters

Ping time from Warsaw is not bad, we have 37ms average time for a packet (ICMP) travel:

$ ping -c 5
PING ( 56(84) bytes of data.
64 bytes from icmp_req=1 ttl=54 time=38.3 ms
64 bytes from icmp_req=2 ttl=54 time=38.8 ms
64 bytes from icmp_req=3 ttl=54 time=41.6 ms
64 bytes from icmp_req=4 ttl=54 time=35.2 ms
64 bytes from icmp_req=5 ttl=54 time=35.3 ms

--- ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 35.282/37.899/41.625/2.371 ms

We can inspect whole route with more details:

$ mtr --report
HOST: dt                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  8.|-- fra-5-6k.fr.eu            40.0%    10   37.4  37.4  29.1  55.2   9.4
  9.|-- sbg-g2-a9.fr.eu            0.0%    10   48.7  46.4  33.7  83.7  15.0
 10.|-- sbg-s9-6k.fr.eu           90.0%    10   36.5  36.5  36.5  36.5   0.0
 11.|-- 50.ip-37-187-39.eu         0.0%    10   36.9  42.2  35.0  62.1   8.4
 12.|-- 178.ip-37-187-198.eu       0.0%    10   40.8  38.0  32.0  48.6   5.1

Finally: the speed tests performed using HTTP (no encryption overhead on VPS, median result from three runs):

# wget -O /dev/null
--2014-02-06 23:15:44--
Connecting to connected.
HTTP request sent, awaiting response... 200 OK
Length: 4415803 (4.2M) [application/zip]
Saving to: `/dev/null'

100%[================================>] 4,415,803   8.04M/s   in 0.5s    

2014-02-06 23:15:45 (8.04 MB/s) - `/dev/null' saved [4415803/4415803]

OVH promises 100 MBit/s, thus ~10 MB/s. As we can see real values are slightly lower, near 8 MB/s. It's not bad (I used U.S. server to test, so may hit local bandwidth restrictions).


# free -h
              total       used       free     shared    buffers     cached
 Mem:          512M        16M       495M         0B         0B       9.0M
 -/+ buffers/cache:       7.7M       504M
 Swap:         128M         0B       128M

It's o,5GB as specified in offer. Note that for OpenVZ your kernel memory is not counted towards used memory - it's different memory model than XEN where you have separate kernel.

For OpenVZ virtualization you might have some additional restrictions (besides memory for all your processes). You can reach those values by /proc/user_beancounters file:

# cat /proc/user_beancounters 
Version: 2.5
       uid  resource                     held              maxheld              barrier                limit              failcnt
    46990:  kmemsize                 10343161             13320192  9223372036854775807  9223372036854775807                    0
            lockedpages                     0                  489               131072               131072                    0
            privvmpages                  1925                25304               131072               524288                    0
            shmpages                      647                  663  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            numproc                        15                   33  9223372036854775807  9223372036854775807                    0
            physpages                   41390                47954                    0               131072                    0
            vmguarpages                     0                    0               131072               131072                    0
            oomguarpages                  833                  833               131072               131072                    0
            numtcpsock                      5                    5  9223372036854775807  9223372036854775807                    0
            numflock                        1                    7  9223372036854775807  9223372036854775807                    0
            numpty                          1                    4  9223372036854775807  9223372036854775807                    0
            numsiginfo                      0                   12  9223372036854775807  9223372036854775807                    0
            tcpsndbuf                   87200               111312  9223372036854775807  9223372036854775807                    0
            tcprcvbuf                   81920               862096  9223372036854775807  9223372036854775807                    0
            othersockbuf                    0                19736  9223372036854775807  9223372036854775807                    0
            dgramrcvbuf                     0                 8720  9223372036854775807  9223372036854775807                    0
            numothersock                   18                   22                  500                  500                    0
            dcachesize                5574544              7664915  9223372036854775807  9223372036854775807                    0
            numfile                       190                  280  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            dummy                           0                    0  9223372036854775807  9223372036854775807                    0
            numiptent                      24                   24  9223372036854775807  9223372036854775807                    0

Typically kmemsize (kernel size for this guest OS) and numproc (the number of available processes) is restricted (I've learned 1&1 restricts numproc to 160!). Here we have no restrictions added for those two parameters, good.


As specified we can see only one core, so will be limited here:

# grep 'cpu MHz\|bogomips' /proc/cpuinfo 
cpu MHz        : 3000.000
bogomips    : 6000.00

The bogomips value (+/- perfomance of the CPU) is 50% better than my 2GHz laptop. The difference comes from higher CPU clock used (3GHz vs 2 GHz).


Typical resource that is oversold by hosting companies. I'm not talking about space itself, but about performance. I've seen many comlaints in the past related to high IO lags (thus high load) due to overused disk usage on crowded servers for virtual and classic hosting.

We can see simfs (virtual filesystem), inodes are shared with host:

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/simfs       25G  401M   25G   2% /
tmpfs            52M   28K   52M   1% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           128M     0  128M   0% /run/shm

As we are on OpenVZ container we don't have access to hdparm tool. We can make quick & dirty workaround for measure disk write speed (medium result selected):

# sync; dd if=/dev/zero of=/tmp/test bs=64k count=16k; rm /tmp/test
16384+0 records in
16384+0 records out
1073741824 bytes (1.1 GB) copied, 8.67465 s, 124 MB/s

Not bad, probably disk is not overloaded. For comparison my ThnkPad with 5200 RPM HDD:

$ sync; dd if=/dev/zero of=/tmp/test bs=64k count=16k; rm /tmp/test
16384+0 records in
16384+0 records out
1073741824 bytes (1,1 GB) copied, 33,3557 s, 32,2 MB/s

Geez, I should switch to SSD! :-)


As you probably know that above measurements are worth nothing if you have long downtimes and / or periods with extremely high load of a host I've launched monitoring of HTTP response time to track changes over longer period: http://site-uptime.net/su.cgi/en/report?publicKey=gd99o41dpg0ya988austo10ebx6px7h9 I'll shave stats report as soon as they're ready in separate post. I can share my recommendation then: is OVH VPS worth of your money or not.

UPDATE 2015-03-17: In recent day OVH started to randomly kill my processes (OOM on host?) even if I'm much below OpenVZ limits and allocated memory usage. I switched to another provider instantly. Thus I DO NOT RECOMMEND OVH VPS SOLUTION. Select Linode instead, you will save your time and money.

Tags: hosting.


Created by Chronicle v3.5