On 20/04/15 01:36, Andrew Stuart wrote:
Incidentally there might be a hint of why this is happening in the time of
3648.3 show as a result of the xl list, which was done AFTER the benchmarks had
run. Assuming this is Xen reporting the something like the processing time of
each VM then it looks like rumprun is doing alot of processing relative to the
other configurations.
That might be a good catch. Last night I was tracking down some bug on
-baremetal, and noticed that threads which should be sleeping still get
scheduled. Then I got distracted by the Finnish parliament elections.
But I'll definitely look at it today. nb. /xen and /baremetal don't yet
share the same scheduler code, but given that the /baremetal bug I was
tracking was triggered when I was trying to make the scheduler code the
same so that I could merge it, it's a good bet that there's a similar
problem on /xen.
On 20 Apr 2015, at 11:06 am, Andrew Stuart <[email protected]>
wrote:
Anyone got any suggestions for things I could change/tune/fiddle with to bring
up the rumprun nginx transactions per second?
Not at the moment. You can try changing some parameters with sysctl
(via rumprun-posix and rumpremote.sh), but I don't think there's an
intentional "make connection forming as slow as possible".
(hmm, did the web server discussion jump threads?)
jumping back...
For extra clarity ;)
Oh, and just to be precise, that's assuming you're running on Xen. The baremetal NIC
drivers are in much better shape, since they use regular NetBSD PCI code (virtio is
"pci" too).
Not sure I understand - I am running rumprun on Xen. Is there a way to change
the configuration/drivers to use the baremtal NIC drivers to make it faster?
You can use PCI passthrough. If virtio is available on Xen, you can
also use that. But none of that is really supported in a very
documented way, so figuring out how exactly to do that might take some
playing around with.
Did you obtain that reference number by running the benchmarking tool and the
httpd in different domains? I'd expect things to still be a lot slower, but
not by a factor of 10.
I'm executing the benchmarking siege tool from the Xen host Dom0, not in the
same domain.
I have tried to configure 4 similar environments, each running nginx. It’s not
super scientific but they are similar configurations.
Thanks for the data, very nice to have!
Quoting my thesis supervisor: "everything does not have to be scientific
bullsh*t, we're trying to solve real problems".
