Regarding Performance of DBUS library

[rajnikant jachak]

Thanks Simon for detailed explanation. My use case is similar to what you
have explained NetworkManager (signal when something interesting happens
:)).

We are in the process of developing one playback system. One of the
sub-system within this will function as media player UI. Through this media
player UI, user can give many commands like play, stop etc. to player,
Player in turn updates UI about command execution status and clip status
(playing/time details etc). Also, the media player UI might get signals
from other sub-systems (eg. USB device connected). UI need to interact
authorization module to autherise operator/contents etc. The monitor module
should also able to listen all events happening within system. All these
components will sit on same machine. So we are planning to use DBUS for
interaction between these sub-systems. DBUS gives advantage here as some of
sub-systems are written in python scripts and by using DBUS we can
concentrate more on main application requirements rather than caring about
interprocess communication.

Apologize for late reply as I was on vacation :).

On Wed, Aug 29, 2012 at 7:56 PM, Simon McVittie <
simon.mcvittie at collabora.co.uk> wrote:

> On 29/08/12 14:05, rajnikant jachak wrote:
> > As I said, my client emits 'req' signal and server processes it. In my
> > system, there would be multiple clients emitting same signal 'req',
> > which server in turn needs to process.
>
> That's fine. Multiple client processes are fine, multiple threads within
> one process are more problematic (because they share an address space,
> so they need mutexes and very careful programming practices).
>
> > Would such type of many to one association, overload DBUS?
>
> Many-to-one communication is fine - it's a large part of why D-Bus
> exists. But you're asking about performance without giving any
> indication of what you're actually doing, so I should give you the usual
> performance advice.
>
> The standard D-Bus system and session buses are really designed to be
> used for "signalling" - individual messages or short bursts of messages
> when something interesting happens - rather than for continuous bulk
> traffic. For instance, it's ideal for something like NetworkManager.
> When the user takes action or "interesting" things happen in the real
> world (network cable plugged in, wireless network detected, etc.),
> relatively many messages are sent, but that's a temporary situation.
> When the computer is idle, NetworkManager only needs to send a message
> to the UI every few seconds (or even every few minutes) to say "signal
> strength has changed to 42%" or similar.
>
> Similarly, the Telepathy IM framework sends D-Bus messages when you send
> or receive messages, start or receive calls, or when your friends'
> presence statuses change, but in between "interesting" events, it's
> idle. That's the sort of thing D-Bus is meant for.
>
> My usual rule of thumb is that if you have to worry about D-Bus'
> performance or what percentage of CPU time it will take up, you should
> consider whether D-Bus is actually the right thing for you. You can
> always use the system bus to do the "handshaking" for a private Unix
> socket or something, then do your bulk data transfer over that.
>
> If you tell this mailing list what your use case is, we're more likely
> to be able to say whether D-Bus is appropriate. Otherwise, the only
> answer you're likely to get is "it depends".
>
> If yes, would
> > such problem get resolved if every client emits different signal (ex.
> > client1 emits req1, client2 emits req2 etc) for server?
>
> No, renaming messages does not alter the amount of CPU time they'll
> require.
>
>     S
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>



-- 
Regards,
Rajnikant Jachak.

The pessimist sees difficulty in every opportunity. The optimist sees the
opportunity in every difficulty.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20120905/65bfffa4/attachment-0001.html>