[vbox-dev] API method execution sometimes extremely slow

Discussion:

2013-12-10 13:44:50 UTC

Hi,

I am using VirtualBox 4.3.4 on MacOS Maverick. The VM is a Windows 7 64bit guest running on a Macbook Pro (8 cores, 16GB RAM). The issue I have is as described at https://forums.virtualbox.org/viewtopic.php?f=34&t=57685:

When using the API methods over Java using XPCOM, some method calls randomly take a huge amount of time. For instance, things that are typically done within 1-5ms sometimes take up to 2000ms! Even when these delays happen, the CPU usage is never even near 100% and their is sufficient free memory on the host available. I wonder if someone can give me insights into what might cause these kind of delays and if its maybe possible to communicate more quickly. For instance, if its caused by interprocess scheduling, is it possible to ?open a stream? and then just send the commands to it? Fwiw, if I perform the same stuff (e.g. Key clicks) manually within the VM, there are never delays like this observable.

Cheers,

Thorsten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.virtualbox.org/pipermail/vbox-dev/attachments/20131210/def07b23/attachment.html

Klaus Espenlaub

2013-12-11 12:14:04 UTC

Permalink

Hi Thorsten,

Post by email
Hi,
I am using VirtualBox 4.3.4 on MacOS Maverick. The VM is a Windows 7
64bit guest running on a Macbook Pro (8 cores, 16GB RAM). The issue I
have is as described at
When using the API methods over Java using XPCOM, some method calls
randomly take a huge amount of time. For instance, things that are
typically done within 1-5ms sometimes take up to 2000ms! Even when these
delays happen, the CPU usage is never even near 100% and their is
sufficient free memory on the host available. I wonder if someone can
give me insights into what might cause these kind of delays and if its
maybe possible to communicate more quickly. For instance, if its caused
by interprocess scheduling, is it possible to ?open a stream? and then
just send the commands to it? Fwiw, if I perform the same stuff (e.g.
Key clicks) manually within the VM, there are never delays like this
observable.

Never seen such problems, and as the Java/XPCOM combo in the end
interfaces to the C++ API which is used by every VirtualBox component
(the manager GUI and the VM processes) I doubt that there's a generic issue.

When does the big delay happen? Is it really for individual API calls,
or do you count in the setup time (getting the VirtualBox reference,
setting up a session)?

We don't write much Java code, and don't actively use this way of
talking to the API, but we're quite sure that more than only a few
people go this way.

Klaus

Post by email
Cheers,
Thorsten

2013-12-12 14:07:36 UTC

Permalink

Hi Klaus,

Unfortunately, I cannot see any real pattern in when the big delays
happen. What I?m doing is simulating user input to test software using the
Virtualbox API. So basically I?m sending a lot of key downs and key up
messages to the VM (I know its possible to send key press events, but for
testing reasons I need to send separate events). I?m always using the same
virtual machine and the load during tests is always low on the host.
Sometimes I get now issues at all and all events are send within a few
milliseconds each, but other times a single event can take more than a
second. Note that when this happens, I don?t see any changes in memory
consumption, nor the average CPU load on the host. Also, the times
measured are only the API calls, i.e., I get a reference to the
VM/console/keyboard at the beginning and then just send hundreds of events
using this reference. Also, it is typically that a couple of events are
strongly delayed, but a few seconds later it can go back to normal speed.
I imagine its hard to figure out the cause based on these information; is
there a possibility to create a performance log so one can see which part
of the API call processing code causes the delay? Or can I provide other
information to help figuring out the cause?

Thorsten

PS: Also tried to use the Web service API instead of XPCOM, but it was the
same issue.

Am 12/11/13, 9:14 AM schrieb "Klaus Espenlaub" unter

Post by Klaus Espenlaub
Hi Thorsten,

Never seen such problems, and as the Java/XPCOM combo in the end
interfaces to the C++ API which is used by every VirtualBox component
(the manager GUI and the VM processes) I doubt that there's a generic issue.
When does the big delay happen? Is it really for individual API calls,
or do you count in the setup time (getting the VirtualBox reference,
setting up a session)?
We don't write much Java code, and don't actively use this way of
talking to the API, but we're quite sure that more than only a few
people go this way.
Klaus

Post by email
Cheers,
Thorsten

_______________________________________________
vbox-dev mailing list
vbox-dev at virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev

Nikolay Igotti

2013-12-24 21:25:42 UTC

Permalink

Hi Thorsten,

Couldn't it be GC pauses in your JVM? Try appropriate JVM logging or
JConsole to see if
there's correlation between slow calls and GC.

Nikolay

Post by Klaus Espenlaub
Hi Thorsten,

Never seen such problems, and as the Java/XPCOM combo in the end
interfaces to the C++ API which is used by every VirtualBox component
(the manager GUI and the VM processes) I doubt that there's a generic issue.
When does the big delay happen? Is it really for individual API calls,
or do you count in the setup time (getting the VirtualBox reference,
setting up a session)?
We don't write much Java code, and don't actively use this way of
talking to the API, but we're quite sure that more than only a few
people go this way.
Klaus

Post by email
Cheers,
Thorsten

_______________________________________________
vbox-dev mailing list
vbox-dev at virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev

2013-12-26 17:16:31 UTC

Permalink

Hi,

I checked this but GC is not the cause: it happens even if no GC takes
place.
One thing which I observed and cannot explain is the following:
I wrote a tiny program that just creates 1000 keydown/keyup events
(http://pastebin.com/cqUuCfq6). If I
let it run in a VM where I minimize the VM window (no screen visible),
every click takes less than 3ms, which is the expected behavior. However,
if the window is not minimized and the keys are sent to a notepad window,
a lot of calls take way more time, up to 30 times as much. Furthermore, if
I run the code in a non-minimized window but don?t open notepad as a
consumer of the keys (hence, the keys get sent to the VM but they don?t
have any affect), it?s as fast as in the minimized case.
I suspect that the issue is as follows: I sent key events and those key
events affect the graphics, which causes an update in some other part of
the VM (in order to render an updated view). The latter may take longer
and is blocking the key sending through the API. Can anyone confirm that
this is what is going on within the implementation and is there any way to
get rid of the blocking?

Thorsten

Post by Klaus Espenlaub
Hi Thorsten,
Couldn't it be GC pauses in your JVM? Try appropriate JVM logging or
JConsole to see if
there's correlation between slow calls and GC.
Nikolay

Post by Klaus Espenlaub
Hi Thorsten,

Never seen such problems, and as the Java/XPCOM combo in the end
interfaces to the C++ API which is used by every VirtualBox component
(the manager GUI and the VM processes) I doubt that there's a generic issue.
When does the big delay happen? Is it really for individual API calls,
or do you count in the setup time (getting the VirtualBox reference,
setting up a session)?
We don't write much Java code, and don't actively use this way of
talking to the API, but we're quite sure that more than only a few
people go this way.
Klaus

Post by email
Cheers,
Thorsten

_______________________________________________
vbox-dev mailing list
vbox-dev at virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev

Nikolay Igotti

2013-12-31 08:16:29 UTC

Permalink

Explanation you suggest is pretty unlikely, as there's no direct
synchronization
between keypresses and screen updates (emulated keys are just added to the
keyboard queue and read by guest driver later). However, your issue
could be related to MacOS hacks
deprioritizing invisible applications (Windows does that for sure). To
check, you may try
different guest (such as Linux guest with simple TUI) and see if
minimized/normal
window makes a difference. You may also try see if some API call without
much side effects
has different timings. IPC calls in VBox go via pretty non-trivial path
(client -> xpcomd -> VM)
and thus are affected by scheduling decisions.

Also you may try to use USB, not PS2 keyboard, to see if problem is
specific to particular keyboard
hardware (which I doubt).

Nikolay

Post by email
Hi,
I checked this but GC is not the cause: it happens even if no GC takes
place.
I wrote a tiny program that just creates 1000 keydown/keyup events
(http://pastebin.com/cqUuCfq6). If I
let it run in a VM where I minimize the VM window (no screen visible),
every click takes less than 3ms, which is the expected behavior. However,
if the window is not minimized and the keys are sent to a notepad window,
a lot of calls take way more time, up to 30 times as much. Furthermore, if
I run the code in a non-minimized window but don?t open notepad as a
consumer of the keys (hence, the keys get sent to the VM but they don?t
have any affect), it?s as fast as in the minimized case.
I suspect that the issue is as follows: I sent key events and those key
events affect the graphics, which causes an update in some other part of
the VM (in order to render an updated view). The latter may take longer
and is blocking the key sending through the API. Can anyone confirm that
this is what is going on within the implementation and is there any way to
get rid of the blocking?
Thorsten

Post by Klaus Espenlaub
Hi Thorsten,
Couldn't it be GC pauses in your JVM? Try appropriate JVM logging or
JConsole to see if
there's correlation between slow calls and GC.
Nikolay

Post by Klaus Espenlaub
Hi Thorsten,

Never seen such problems, and as the Java/XPCOM combo in the end
interfaces to the C++ API which is used by every VirtualBox component
(the manager GUI and the VM processes) I doubt that there's a generic issue.
When does the big delay happen? Is it really for individual API calls,
or do you count in the setup time (getting the VirtualBox reference,
setting up a session)?
We don't write much Java code, and don't actively use this way of
talking to the API, but we're quite sure that more than only a few
people go this way.
Klaus

Post by email
Cheers,
Thorsten

_______________________________________________
vbox-dev mailing list
vbox-dev at virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev