On Wed, Mar 27, 2019 at 6:14 PM Waldek Kozaczuk <[email protected]> wrote:
> > > On Wednesday, March 27, 2019 at 8:24:23 PM UTC-4, דור לאור wrote: >> >> On Wed, Mar 27, 2019 at 3:36 PM Waldek Kozaczuk <[email protected]> >> wrote: >> >>> Overall I must say I am not a performance tuning/measuring expert and >>> clearly have lots of things to learn ;-) BTW can you point me to any >>> performance setup/procedures/docs that you guys used with OSv? >>> >> >> I tried to look but didn't find much, I do remember with played with all >> these options when we implemented different >> scheduling options to deal with spin locks, network performance, etc. >> >> >>> I also feel I have tried to kill too many birds with one stone. Ideally >>> I should have divided whole thing into 3 categories: >>> - OSv on firecracker vs QEMU >>> - OSv vs Docker >>> - OSv vs Linux guest >>> >>> On Tuesday, March 26, 2019 at 8:32:00 PM UTC-4, דור לאור wrote: >>>> >>>> While the performance numbers indicate something, a mac book is a >>>> horrible environment for performance >>>> testing. There are effects of other desktop apps, hyperthreading, etc. >>>> >>> Well that is what I have available in my home lab :-) I understand you >>> are suggesting that apps running on the MacBook might affect and skew the >>> results. I made sure the only apps open was one or two terminal windows. I >>> had also mpstat open and most of the time CPUs were idle when tests were >>> not running. But I get your point that ideally I should use proper headless >>> server machine. I also get the effect of hyper threading - is there a way >>> to switch it off in Linux by some kind of boot parameter? >>> >> >> I think it's mainly in the bios. You can pin vcpu to a hyperthread >> running on a different core and thus eliminate 2 hyperthreads on the same >> core and get almost the real thing this way >> >> >>> >>> >>> Also 1gbps network can be a bottle neck. >>>> >>> Very likely, I have been suspecting same thing. >>> >>> Every benchmark case should have a matching performance >>>> analysis and point to the bottleneck reason - cpu/networking/contect >>>> switching/locking/filesystem/.. >>>> >>> To figure this out I guess I would need to use OSv tracing capability - >>> https://github.com/cloudius-systems/osv/wiki/Trace-analysis-using-trace.py >>> >>> >> >> Yes, it has lots of good tactics, using perf and the tracer and also >> figure out where the cpu time go to. >> >> >>> >>> Just hyperthread vs a different thread in another core is very >>>> significant change. >>>> Need to pin the qemu threads in the host to the right physical threads. >>>> >>> I was not even aware that one can pin to specific CPUs. What parameters >>> pass to qemu? >>> >> >> I forgot, need to read the manual.. everything is supported. >> >> >>> >>>> Better to run on a good physical server (like i3.metal on AWS or >>>> similar, could be smaller but not 2 cores) and >>>> track all the metrics appropriately. Best is to isolate workloads (and >>>> make sure they scale linearly too) in terms of cpu/mem/net/disk and only >>>> then >>>> show how a more complex workload performs. >>>> >>> Cannot afford 5$ per hour ;-) Unless I have fully automated test suite. >>> >>> My dream would be to have an automated process I could trigger with a >>> single click of a button that would: >>> 1) Use cloud formation template to create a VPC with all components of >>> the test environment. >>> 2) Automatically start each instance under test and corresponding test >>> client >>> 3) Automatically collect all test results (both wrk and possibly tracing >>> data) and put them somewhere in S3. >>> >>> Finally If I had a suite of visualization tools that would generate >>> whatever graphs I need to analyze. It would save soooooo much time. >>> Possibly under hour => then I could pay 5 bucks for it ;-) >>> >>> But it takes time to build one ;-) >>> >> >> I think it's possible to continue with your desktop (but try to use >> Linux) and focus on 1,2 vcpus and analyze each >> test carefully. Try to realize what's the bottleneck of each test. >> > My Mac is configured as a triple-boot machine that can boot to OSX or > Ubuntu or Windows 10. All the tests were running on bare-metal Linux booted > MacBook Pro. Do you mean that my test client should also run on Linux > bare-metal machine? > No, the client machine shouldn't matter as long as it generates enough requests and it seems this is the case > >> >>> >>>> On Tue, Mar 26, 2019 at 3:29 PM Waldek Kozaczuk <[email protected]> >>>> wrote: >>>> >>>>> Last week I spent some time investigating OSv performance and >>>>> comparing it to Docker and Linux guests. To that end I adopted >>>>> "unikernels-v-containers"' repo by Tom Goethals and extended it with 2 new >>>>> apps (Rust and Node.js) and new scripts to build and deploy OSv apps on >>>>> QEMU/KVM - https://github.com/wkozaczuk/unikernels-v-containers. So >>>>> as you can see my focus was on OSv on QEMU/KVM and firecracker vs Linux on >>>>> firecracker vs Docker whereas Tom's paper was comparing OSv on Xen vs >>>>> Docker (details of discussion around it and the link to the paper you can >>>>> find here - >>>>> https://groups.google.com/forum/#!topic/osv-dev/lhkqFfzbHwk). >>>>> >>>>> Specifically I wanted to compare networking performance in terms of >>>>> number of REST API requests per second processed by a typical microservice >>>>> app implemented in Rust (built using hyper), Golang and Java (built using >>>>> vertx.io) and running on following: >>>>> >>>>> - OSv on QEMU/KVM >>>>> - OSv on firecracker >>>>> - Docker container >>>>> - Linux on firecracker >>>>> >>>>> Each app in essence implements simple todo REST api returning a json >>>>> payload 100-200 characters long (for example see here Java one - >>>>> https://github.com/wkozaczuk/unikernels-v-containers/blob/master/restapi/java-osv/src/main/java/rest/SimpleREST.java). >>>>> The source code of all apps is under this subtree - >>>>> https://github.com/wkozaczuk/unikernels-v-containers/blob/master/restapi. >>>>> One thing to not was that each request would return always the same >>>>> payload >>>>> (I wonder if that may cause the response gets cached and affects results). >>>>> >>>>> The test setup looked like this: >>>>> >>>>> *Host:* >>>>> >>>>> - MacBook Pro with Intel i7 4 cores CPU with hyperthreading (8 >>>>> cpus reported by lscpu) with 16GB of RAM with Ubuntu 18.10 on it >>>>> - firecracker 0.15.0 >>>>> - QEMU 2.12.0 >>>>> >>>>> >>>>> *Client machine:* >>>>> >>>>> - similar to the one above with wrk as a test client firing >>>>> requests using 10 threads and 100 open connections for 30 seconds in 3 >>>>> series one by one (please see this test script - >>>>> >>>>> https://github.com/wkozaczuk/unikernels-v-containers/blob/master/test-restapi-with-wrk.sh >>>>> ). >>>>> - wrk by default uses Keep-Alive for http connections so TCP >>>>> handshake is minimal >>>>> >>>>> The host and client machine were connected directly to 1 GBit ethernet >>>>> switch and host exposed guest IP using a bridged TAP nic (please see the >>>>> script used - >>>>> https://raw.githubusercontent.com/cloudius-systems/osv/master/scripts/setup-external-bridge.sh >>>>> ). >>>>> >>>>> You can find scripts to start applications on OSv and docker here - >>>>> https://github.com/wkozaczuk/unikernels-v-containers (run* scripts). >>>>> Please note --cpu-set parameter used in docker script to limit number of >>>>> CPUs. >>>>> >>>>> You can find detailed results under >>>>> https://github.com/wkozaczuk/unikernels-v-containers/tree/master/test_results/remote >>>>> . >>>>> >>>>> Here are just requests per seconds numbers (full example - >>>>> https://raw.githubusercontent.com/wkozaczuk/unikernels-v-containers/master/test_results/remote/docker/rust_docker_4_cpu.wrk >>>>> ) >>>>> >>>>> OSv on QEMU >>>>> *Golang* >>>>> *1 CPU* >>>>> Requests/sec: 24313.06 >>>>> Requests/sec: 23874.74 >>>>> Requests/sec: 23300.26 >>>>> >>>>> *2 CPUs* >>>>> Requests/sec: 37089.26 >>>>> Requests/sec: 35475.22 >>>>> Requests/sec: 33581.87 >>>>> >>>>> *4 CPUs* >>>>> Requests/sec: 42747.11 >>>>> Requests/sec: 43057.99 >>>>> Requests/sec: 42346.27 >>>>> >>>>> *Java* >>>>> *1 CPU* >>>>> Requests/sec: 41049.41 >>>>> Requests/sec: 43622.81 >>>>> Requests/sec: 44777.60 >>>>> *2 CPUs* >>>>> Requests/sec: 46245.95 >>>>> Requests/sec: 45746.48 >>>>> Requests/sec: 46224.42 >>>>> *4 CPUs* >>>>> Requests/sec: 48128.33 >>>>> Requests/sec: 45467.53 >>>>> Requests/sec: 45776.45 >>>>> >>>>> *Rust* >>>>> >>>>> *1 CPU* >>>>> Requests/sec: 43455.34 >>>>> Requests/sec: 43927.73 >>>>> Requests/sec: 41100.07 >>>>> >>>>> *2 CPUs* >>>>> Requests/sec: 49120.31 >>>>> Requests/sec: 49298.28 >>>>> Requests/sec: 48076.98 >>>>> *4 CPUs* >>>>> Requests/sec: 51477.57 >>>>> Requests/sec: 51587.92 >>>>> Requests/sec: 49118.68 >>>>> >>>>> OSv on firecracker >>>>> *Golang* >>>>> >>>>> *1 cpu* >>>>> Requests/sec: 16721.56 >>>>> Requests/sec: 16422.33 >>>>> Requests/sec: 16540.24 >>>>> >>>>> *2 cpus* >>>>> Requests/sec: 28538.35 >>>>> Requests/sec: 26676.68 >>>>> Requests/sec: 28100.00 >>>>> >>>>> *4 cpus* >>>>> Requests/sec: 36448.57 >>>>> Requests/sec: 33808.45 >>>>> Requests/sec: 34383.20 >>>>> >>>>> >>>>> *Java* >>>>> *1 cpu* >>>>> Requests/sec: 20191.95 >>>>> Requests/sec: 21384.60 >>>>> Requests/sec: 21705.82 >>>>> >>>>> *2 cpus* >>>>> Requests/sec: 40876.17 >>>>> Requests/sec: 40625.69 >>>>> Requests/sec: 43766.45 >>>>> 4 cpus >>>>> Requests/sec: 46336.07 >>>>> Requests/sec: 45933.35 >>>>> Requests/sec: 45467.22 >>>>> >>>>> >>>>> *Rust* >>>>> *1 cpu* >>>>> Requests/sec: 23604.27 >>>>> Requests/sec: 23379.86 >>>>> Requests/sec: 23477.19 >>>>> >>>>> *2 cpus* >>>>> Requests/sec: 46973.84 >>>>> Requests/sec: 46590.41 >>>>> Requests/sec: 46128.15 >>>>> >>>>> *4 cpus* >>>>> Requests/sec: 49491.98 >>>>> Requests/sec: 50255.20 >>>>> Requests/sec: 50183.11 >>>>> >>>>> Linux on firecracker >>>>> *Golang* >>>>> >>>>> *1 CPU* >>>>> Requests/sec: 14498.02 >>>>> Requests/sec: 14373.21 >>>>> Requests/sec: 14213.61 >>>>> >>>>> *2 CPU* >>>>> Requests/sec: 28201.27 >>>>> Requests/sec: 28600.92 >>>>> Requests/sec: 28558.33 >>>>> >>>>> *4 CPU* >>>>> Requests/sec: 48983.83 >>>>> Requests/sec: 47590.97 >>>>> Requests/sec: 45758.82 >>>>> >>>>> *Java* >>>>> >>>>> *1 CPU* >>>>> Requests/sec: 18217.58 >>>>> Requests/sec: 17709.30 >>>>> Requests/sec: 19829.01 >>>>> >>>>> *2 CPU* >>>>> Requests/sec: 33188.75 >>>>> Requests/sec: 33233.55 >>>>> Requests/sec: 36951.05 >>>>> >>>>> *4 CPU* >>>>> Requests/sec: 47718.13 >>>>> Requests/sec: 46456.51 >>>>> Requests/sec: 48408.99 >>>>> >>>>> *Rust* >>>>> Could not get same rust on Alpine linux that uses musl >>>>> >>>>> Docker >>>>> *Golang* >>>>> >>>>> *1 CPU* >>>>> Requests/sec: 24568.70 >>>>> Requests/sec: 24621.82 >>>>> Requests/sec: 24451.52 >>>>> >>>>> *2 CPU* >>>>> Requests/sec: 49366.54 >>>>> Requests/sec: 48510.87 >>>>> Requests/sec: 43809.97 >>>>> >>>>> *4 CPU* >>>>> Requests/sec: 53613.09 >>>>> Requests/sec: 53033.38 >>>>> Requests/sec: 51422.59 >>>>> >>>>> *Java* >>>>> >>>>> *1 CPU* >>>>> Requests/sec: 40078.52 >>>>> Requests/sec: 43850.54 >>>>> Requests/sec: 44588.22 >>>>> >>>>> *2 CPUs* >>>>> Requests/sec: 48792.39 >>>>> Requests/sec: 51170.05 >>>>> Requests/sec: 52033.04 >>>>> >>>>> *4 CPUs* >>>>> Requests/sec: 51409.24 >>>>> Requests/sec: 52756.73 >>>>> Requests/sec: 47126.19 >>>>> >>>>> *Rust* >>>>> >>>>> *1 CPU*Requests/sec: 40220.04 >>>>> Requests/sec: 44601.38 >>>>> Requests/sec: 44419.06 >>>>> >>>>> *2 CPUs* >>>>> Requests/sec: 53420.56 >>>>> Requests/sec: 53490.33 >>>>> Requests/sec: 53320.99 >>>>> >>>>> *4 CPUs* >>>>> Requests/sec: 53892.23 >>>>> Requests/sec: 52814.93 >>>>> Requests/sec: 54050.13 >>>>> >>>>> Full example (Rust 4 CPUs - >>>>> https://raw.githubusercontent.com/wkozaczuk/unikernels-v-containers/master/test_results/remote/docker/rust_docker_4_cpu.wrk >>>>> ): >>>>> [{"name":"Write >>>>> presentation","completed":false,"due":"2019-03-23T15:30:40.579556117+00:00"},{"name":"Host >>>>> meetup","completed":false,"due":"2019-03-23T15:30:40.579599959+00:00"},{"name":"Run >>>>> tests","completed":false,"due":"2019-03-23T15:30:40.579600610+00:00"},{"name":"Stand >>>>> in >>>>> traffic","completed":false,"due":"2019-03-23T15:30:40.579601081+00:00"},{"name":"Learn >>>>> Rust","completed":false,"due":"2019-03-23T15:30:40.579601548+00:00"}]----------------------------------- >>>>> Running 30s test @ http://192.168.1.73:8080/todos >>>>> 10 threads and 100 connections >>>>> Thread Stats Avg Stdev Max +/- Stdev >>>>> Latency 1.86ms 1.20ms 30.81ms 62.92% >>>>> Req/Sec 5.42k 175.14 5.67k 87.71% >>>>> 1622198 requests in 30.10s, 841.55MB read >>>>> Requests/sec: 53892.23 >>>>> Transfer/sec: 27.96MB >>>>> ----------------------------------- >>>>> Running 30s test @ http://192.168.1.73:8080/todos >>>>> 10 threads and 100 connections >>>>> Thread Stats Avg Stdev Max +/- Stdev >>>>> Latency 1.90ms 1.19ms 8.98ms 58.18% >>>>> Req/Sec 5.31k 324.18 5.66k 90.10% >>>>> 1589778 requests in 30.10s, 824.73MB read >>>>> Requests/sec: 52814.93 >>>>> Transfer/sec: 27.40MB >>>>> ----------------------------------- >>>>> Running 30s test @ http://192.168.1.73:8080/todos >>>>> 10 threads and 100 connections >>>>> Thread Stats Avg Stdev Max +/- Stdev >>>>> Latency 1.85ms 1.14ms 8.39ms 54.70% >>>>> Req/Sec 5.44k 204.22 7.38k 92.12% >>>>> 1626902 requests in 30.10s, 843.99MB read >>>>> Requests/sec: 54050.13 >>>>> Transfer/sec: 28.04MB >>>>> >>>>> I am also enclosing an example of iperf run between client and server >>>>> machine to illustrate type of raw network bandwidth (BTW I test against >>>>> iperf running on host natively and on OSv on qemu and firecracker I got >>>>> pretty much identical results ~ 940 MBits/sec - see >>>>> https://github.com/wkozaczuk/unikernels-v-containers/tree/master/test_results/remote >>>>> ). >>>>> >>>>> Connecting to host 192.168.1.102, port 5201 >>>>> [ 5] local 192.168.1.98 port 65179 connected to 192.168.1.102 port >>>>> 5201 >>>>> [ ID] Interval Transfer Bitrate >>>>> [ 5] 0.00-1.00 sec 111 MBytes 930 Mbits/sec >>>>> [ 5] 1.00-2.00 sec 111 MBytes 932 Mbits/sec >>>>> [ 5] 2.00-3.00 sec 112 MBytes 938 Mbits/sec >>>>> [ 5] 3.00-4.00 sec 112 MBytes 939 Mbits/sec >>>>> [ 5] 4.00-5.00 sec 112 MBytes 940 Mbits/sec >>>>> [ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec >>>>> [ 5] 6.00-7.00 sec 112 MBytes 940 Mbits/sec >>>>> [ 5] 7.00-8.00 sec 112 MBytes 940 Mbits/sec >>>>> [ 5] 8.00-9.00 sec 112 MBytes 941 Mbits/sec >>>>> [ 5] 9.00-10.00 sec 112 MBytes 941 Mbits/sec >>>>> [ 5] 10.00-11.00 sec 112 MBytes 939 Mbits/sec >>>>> [ 5] 11.00-12.00 sec 112 MBytes 941 Mbits/sec >>>>> [ 5] 12.00-13.00 sec 112 MBytes 941 Mbits/sec >>>>> [ 5] 13.00-14.00 sec 112 MBytes 942 Mbits/sec >>>>> [ 5] 14.00-15.00 sec 112 MBytes 941 Mbits/sec >>>>> [ 5] 15.00-16.00 sec 111 MBytes 927 Mbits/sec >>>>> [ 5] 16.00-17.00 sec 112 MBytes 941 Mbits/sec >>>>> [ 5] 17.00-18.00 sec 112 MBytes 942 Mbits/sec >>>>> [ 5] 18.00-19.00 sec 112 MBytes 941 Mbits/sec >>>>> [ 5] 19.00-20.00 sec 112 MBytes 941 Mbits/sec >>>>> [ 5] 20.00-21.00 sec 112 MBytes 936 Mbits/sec >>>>> [ 5] 21.00-22.00 sec 112 MBytes 940 Mbits/sec >>>>> [ 5] 22.00-23.00 sec 112 MBytes 941 Mbits/sec >>>>> [ 5] 23.00-24.00 sec 112 MBytes 941 Mbits/sec >>>>> [ 5] 24.00-25.00 sec 112 MBytes 941 Mbits/sec >>>>> [ 5] 25.00-26.00 sec 112 MBytes 941 Mbits/sec >>>>> [ 5] 26.00-27.00 sec 112 MBytes 940 Mbits/sec >>>>> [ 5] 27.00-28.00 sec 112 MBytes 941 Mbits/sec >>>>> [ 5] 28.00-29.00 sec 112 MBytes 940 Mbits/sec >>>>> [ 5] 29.00-30.00 sec 112 MBytes 941 Mbits/sec >>>>> - - - - - - - - - - - - - - - - - - - - - - - - - >>>>> [ ID] Interval Transfer Bitrate >>>>> [ 5] 0.00-30.00 sec 3.28 GBytes 939 Mbits/sec >>>>> sender >>>>> [ 5] 0.00-30.00 sec 3.28 GBytes 939 Mbits/sec >>>>> receiver >>>>> >>>>> iperf Done. >>>>> >>>>> >>>>> Observations/Conclusions >>>>> >>>>> - OSv fares a little better on QEMU/KVM than firecracker and that >>>>> varies from ~5% to ~20% (Golang). Also please note vast difference >>>>> between >>>>> 1 cpu test results on firecracker and QEMU (hyperthreading is handled >>>>> differently). On QEMU there is a small bump from 1 to 2 to 4 cpus >>>>> except >>>>> for Golang, on firecracker there is almost ~90-100% bump from 1 to 2 >>>>> cpus. >>>>> - To that end I have opened firecracker issue - >>>>> https://github.com/firecracker-microvm/firecracker/issues/1034. >>>>> - When you compare OSv on firecracker vs Linux on firecracker >>>>> (comparing OSv on QEMU would be I guess unfair) you can see that: >>>>> - Golang app on OSv was ~ 15% better vs on Linux with 1 cpu, >>>>> almost identical with 2 cpus and app being faster on Linux ~30% >>>>> with 4 CPUs >>>>> (I did check that Golang runtime properly detects number of cpus) >>>>> - Java app on OSv was ~ 5% faster with 1 CPU, ~ 20% faster with >>>>> 2 CPUs and slightly slower with 4 CPUs >>>>> - Could not run Rust app on Linux because it was alpine >>>>> distribution built with musl and I did not have time to get Rust >>>>> build >>>>> properly for that scenario >>>>> - When you compare OSv on QEMU/KVM vs Docker you can see that: >>>>> - All apps running with single CPU fares almost the same with >>>>> OSv being sometimes a little faster >>>>> - Java and Rust apps performed only a little better (2-10%) on >>>>> Docker vs OSv >>>>> - Golang on OSv scaled well with number of CPUs but performed >>>>> much worse on OSv (20-30%) with 2 and 4 cpus >>>>> - There seems to be a bottleneck around 40-50K requests per >>>>> seconds somewhere. Looking at one result, the raw network rate >>>>> reported was >>>>> around 26-28MB per second. GIven that HTTP requests require sending >>>>> request >>>>> and response possibly that is what is the maximum the network - >>>>> combination >>>>> of ethernet switch and server and client machines - can handle? >>>>> >>>>> >>>>> Questions >>>>> >>>>> - Are there any flaws in this test setup? >>>>> - Why does OSv not scale in some scenarios - especially when >>>>> bumping from 2 to 4 cpus?? Networking bottleneck? Scheduler? Locks? >>>>> - Could we further optimize OSv running with single CPU (skip >>>>> global cross-CPU page allocator, etc)? >>>>> >>>>> >>>>> To get even more insight I also compared how OSv on QEMU would fare >>>>> against same app running in Docker with wrk running on the host and firing >>>>> requests locally. You can find the results under >>>>> https://github.com/wkozaczuk/unikernels-v-containers/tree/master/test_results/host >>>>> . >>>>> >>>>> OSv on QEMU >>>>> *Golang* >>>>> >>>>> *1 CPU* >>>>> Requests/sec: 25188.60 >>>>> Requests/sec: 24664.43 >>>>> Requests/sec: 23935.77 >>>>> *2 CPUs* >>>>> Requests/sec: 37118.95 >>>>> Requests/sec: 37108.96 >>>>> Requests/sec: 35997.58 >>>>> >>>>> *4 CPUs* >>>>> Requests/sec: 49987.20 >>>>> Requests/sec: 48710.74 >>>>> Requests/sec: 44789.96 >>>>> >>>>> >>>>> *Java* >>>>> *1 CPU* >>>>> Requests/sec: 43648.02 >>>>> Requests/sec: 45457.98 >>>>> Requests/sec: 41818.13 >>>>> >>>>> *2 CPUs* >>>>> Requests/sec: 76224.39 >>>>> Requests/sec: 75734.63 >>>>> Requests/sec: 70597.35 >>>>> >>>>> *4 CPUs* >>>>> Requests/sec: 80543.30 >>>>> Requests/sec: 75187.46 >>>>> Requests/sec: 72986.93 >>>>> >>>>> >>>>> *Rust* >>>>> *1 CPU* >>>>> Requests/sec: 42392.75 >>>>> Requests/sec: 39679.21 >>>>> Requests/sec: 37871.49 >>>>> >>>>> *2 CPUs* >>>>> Requests/sec: 82484.67 >>>>> Requests/sec: 83272.65 >>>>> Requests/sec: 71671.13 >>>>> >>>>> *4 CPUs* >>>>> Requests/sec: 95910.23 >>>>> Requests/sec: 86811.76 >>>>> Requests/sec: 83213.93 >>>>> >>>>> >>>>> Docker >>>>> >>>>> *Golang* >>>>> *1 CPU* >>>>> Requests/sec: 24191.63 >>>>> Requests/sec: 23574.89 >>>>> Requests/sec: 23716.33 >>>>> >>>>> *2 CPUs* >>>>> Requests/sec: 34889.01 >>>>> Requests/sec: 34487.01 >>>>> Requests/sec: 34468.03 >>>>> >>>>> *4 CPUs* >>>>> Requests/sec: 48850.24 >>>>> Requests/sec: 48690.09 >>>>> Requests/sec: 48356.66 >>>>> >>>>> >>>>> *Java* >>>>> *1 CPU* >>>>> Requests/sec: 32267.09 >>>>> Requests/sec: 34670.41 >>>>> Requests/sec: 34828.68 >>>>> >>>>> *2 CPUs* >>>>> Requests/sec: 47533.94 >>>>> Requests/sec: 50734.05 >>>>> Requests/sec: 50203.98 >>>>> >>>>> *4 CPUs* >>>>> Requests/sec: 69644.61 >>>>> Requests/sec: 72704.40 >>>>> Requests/sec: 70805.84 >>>>> >>>>> >>>>> *Rust* >>>>> *1 CPU* >>>>> Requests/sec: 37061.52 >>>>> Requests/sec: 36637.62 >>>>> Requests/sec: 33154.57 >>>>> >>>>> *2 CPUs* >>>>> Requests/sec: 51743.94 >>>>> Requests/sec: 51476.78 >>>>> Requests/sec: 50934.27 >>>>> >>>>> *4 CPUs* >>>>> Requests/sec: 75125.41 >>>>> Requests/sec: 74051.27 >>>>> Requests/sec: 74434.78 >>>>> >>>>> - Does this test even make sense? >>>>> - As you can see OSv outperforms docker in this scenario to >>>>> various degree by 5-20%. Can anybody explain why? Is it because in >>>>> this >>>>> case iboth wrk and apps are on the same machine and number of context >>>>> switches are fewer between kernel and user mode in favor of OSv? Does >>>>> it >>>>> mean that we could benefit from a setup with a load balancer (for >>>>> example >>>>> like haproxy or squid) that would be running on the same host in user >>>>> mode >>>>> and forwarding to single-CPU OSv instances vs single OSv with multiple >>>>> CPUs? >>>>> >>>>> Looking forward to hear what others think. >>>>> >>>>> Waldek >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "OSv Development" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "OSv Development" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to the Google Groups > "OSv Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
