andreeaflorescu
commented
5 years ago If you do not want to have a rate limiter, you can just write:
def add_network_interface(self, interface_name, host_interface_name, ):
self.make_put_call('/network-interfaces/%s' % interface_name, {
'iface_id': interface_name,
'host_dev_name': host_interface_name,
'guest_mac': "52:54:00:12:34:56"
})because the rate_limiter is an optional field. I am not sure what are the effects of setting every field of the rate_limiter to 0.
We will get back to you after we get a chance to investigate this.
raduweiss
wkozaczuk
Pusnow
serban300
Before I dive into details of my performance test results I would to take this occasion to announce on this forum that firecracker is officially and fully supported by OSv unikernel as of latest 0.53.0 release (nickname "Firebird", for details please read here). It can boot in as low as 5ms per bootchart and 10ms per firecracker guest boot time measurement. Maybe it is worth mentioning on https://firecracker-microvm.github.io/ (section "What operating systems are supported by Firecracker?") that besides Linux, OSv can boot on firecracker as well ;-) ? From what I am aware of, OSv is the only unikernel and possibly the only other OS besides Linux that can claim this as of this point in time.
As far as performance comparison between OSv running on firecracker vs QEMU/KVM goes, first I must say that at least in one aspect firecracker beats QEMU - file I/O. I have not done any other elaborate file I/IO tests but for example mounting ZFS filesystem is at least 5 times faster on firecracker - on average 60ms on firecracker vs 260ms on QEMU. Now as far networking goes, OSv performs a little worse on firecracker vs QEMU and it varies between 50-90% of the performance on QEMU in terms of requests per second depending mostly on number of vCPUs and type of the application I used to test.
My tests were focused of number of REST API requests handled per seconds by a typical microservice app implemented in Rust, using hyper, Golang and Java using vertx.io. Each app in essence implements simple todo REST api returning a json payload of 100-200 characters long.
The test setup looked like this:
Host:
Client machine:
The host and client machine were connected directly to 1 GBit ethernet switch and host exposed guest IP using a bridged TAP nic.
Here is a list of pure req/sec results:
For more detailed results please see the files where I captured full output from wrk - https://github.com/wkozaczuk/unikernels-v-containers/tree/master/test_results/remote/OSv_firecracker and https://github.com/wkozaczuk/unikernels-v-containers/tree/master/test_results/remote/OSv_qemu.
Would you have any insight of what might be the reason of relatively slower performance of firecracker? I think I have disabled the rate limiting which is what this script does - https://github.com/cloudius-systems/osv/blob/master/scripts/firecracker.py#L23-L97. It could be also that virtio-mmio implementation on OSv side is not very well optimized - with QEMU OSv uses virtio-pci.
Any help will be greatly appreciated.