A minimal, resource efficient unikernel for cloud services
A few bugs were found and fixed after running a new stress test. The OS seems very stable now, having survived a continous flood of Arp, ICMP and HTTP packets, run in parallel over ~9 hours. The VM showed no signs of having problems and gave a HTTP request rate of 3327.1 conn/s. after the flood had ended.
$ sudo ping -f 10.0.0.42
101095327 packets transmitted, 101095294 received, 0% packet loss, time 31206908ms
$ sudo arping -w 100 10.0.0.42
1715415846 packets transmitted, 857201224 packets received, 50% unanswered (0 extra)
$ time httperf --hog --server 10.0.0.42 --num-conn 100000000
Total: connections 382691 requests 382690 replies 382690 test-duration 31343.418 s`
...
Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
real 522m53.450s
user 74m18.515s
sys 448m57.559s
The connection rate on http was very poor, 12.2 req/s., but I guess that’s quite understandable. Asking httperf to do a 100 million requests as fast as it possible will very likely just suck up all the available outgoing sockets / file descriptors.
Current memory usage: 1122304 b, (1.122304 MB)
Recv: 23726780 Sent: 277016620
$ time httperf --hog --server 10.0.0.42 --num-conn 1000
Connection rate: 3327.1 conn/s (0.3 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 0.3 avg 0.3 max 1.6 median 0.5 stddev 0.0
Connection time [ms]: connect 0.2
Connection length [replies/conn]: 1.000
Request rate: 3327.1 req/s (0.3 ms/req)
Request size [B]: 62.0
Reply rate [replies/s]: min 0.0 avg 0.0 max 0.0 stddev 0.0 (0 samples)
Reply time [ms]: response 0.1 transfer 0.0
Reply size [B]: header 234.0 content 489.0 footer 0.0 (total 723.0)
Reply status: 1xx=0 2xx=1000 3xx=0 4xx=0 5xx=0
CPU time [s]: user 0.09 system 0.21 (user 29.5% system 70.2% total 99.7%)
Net I/O: 2553.3 KB/s (20.9*10^6 bps)
Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
NOTE: We've seen much higher connection rates on other platforms (e.g. 16000 conn/s. has been reported), so the numbers above should not be taken as measure of IncludeOS performance.
On our dev-branch we've replaced the classic PIC-based interrupt system with APIC / IOAPIC and MSI-x. We expect this to give a major boost to resource efficiency and it does make it possible to run virtio-net together with virtio-block. We're also working on a lot of web service stuff, but that's mostly in stealth-mode as of yet - we'll open it up when we have something we think you'll like.
Thanks a lot to the budding community of contributors - we have a long way to go but it feels like we're getting somewhere :-)
Detailed release notes will come with the actual release.
Detailed release notes will come with the actual release.
In this pre-release:
/usr/local/IncludeOS/
. You can move that folder anywhere - just update the first line in the makefiles. (Yes, environment vars are probably what we'll do later, but we're also getting a package manager...)os.a
, which gets installed for re-use. This also has the effect of allowing the linker to only extract the OS-objects required by the service../seed
, which contains everything necessary to start developing.