<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
Hello<br>
<br>
Duncan Grisby wrote:<br>
<blockquote type="cite"
cite="mid200307181052.h6IAqug13435@grisby.dyndns.org">
<pre wrap="">On Monday 14 July, Serguei Kolos wrote:
[...]
</pre>
<blockquote type="cite">
<pre wrap="">2. The asynchronous (oneway) round-trip time is from 3 to 10 times worse
with the omniORB.
</pre>
</blockquote>
<pre wrap=""><!---->
Before I address the specific points, can I just ask what your
application is doing? Does it reflect what this benchmark is doing?</pre>
</blockquote>
To some extent yes. My application is a kind of Information Service. It is
a single CORBA server<br>
to which many other applications (~1000) publish their information. There
are also several tens<br>
receiver applications, which subscribed to some information in this server.
When the info in the server<br>
is changed, an appropriate subscriber is notified. The notification is a
oneway message, which fits <br>
well to the IS model: the server does not really care if subscriber is working
or dead, but it has to<br>
do notification efficiently in order not to allow slow subscribers to affect
the faster ones. In the<br>
real configuration some receivers may get several thousands messages per
second. Of course<br>
these messages are not empty, but they are normally short (few tens of bytes).<br>
<blockquote type="cite"
cite="mid200307181052.h6IAqug13435@grisby.dyndns.org">
<pre wrap="">
As you say in a later email...
[...]
</pre>
<blockquote type="cite">
<pre wrap=""> But, unfortunately there is a serious performance
drawback in one particular case - when a bunch of oneway
messages is sent to the server over single connection. In this case
the server reads many of them with a single recv operation
(which is very good!!!), but then it put each message into a separate
buffer by copying it with the memcpy function (giopStream::inputMessage
function in file giopStream.cc).
This seriously downgrades the performance in such cases and
noticeably (by a factor of 4) increases CPU consumption.
Can this code be re-worked to eliminate memory copying?
</pre>
</blockquote>
<pre wrap=""><!---->
It would be possible to avoid the copying, but to be honest I don't
think it's worth the effort. The large amount of copying only happens
in a very restricted set of circumstances, i.e. that a client is
sending requests so fast that TCP batches them into single packets,
_and_ that each request has very few arguments, so many requests fit
in a single ORB buffer. Furthermore, the overhead of copying is only
relevant to the overall invocation time if the operation
implementation does so little work that the time to do a memory
allocation and a memcpy is significant. </pre>
</blockquote>
You are right about the memcpy operation. I'm sorry - I overestimated it's
impact.<br>
<br>
The good thing is that the impact of splitting a bunch of oneway calls is
really negligible :-)<br>
<br>
But the bad thing is that the problem with oneway calls still exist somewhere
:-( (I hope not only in my mind)<br>
<br>
I repeated my tests putting a delay on client side between remote calls.
Now client sends only 50 <br>
messages per second. The server always receive one message in time and does
not do any splitting. <br>
But ... the thread, which processes oneway calls, consumes 8 times more CPU
(user time) then the thread, <br>
which processes identical two-way calls. The system CPU consumption is almost
identical. <br>
Do you have any idea why it is so?<br>
<br>
Thanks,<br>
Sergei<br>
<br>
</body>
</html>