[avahi] Resolving many ( > 200 ) items seems to lead to apparent congestion in the dbus
lennart at poettering.net
Mon Jun 29 16:26:48 PDT 2009
On Mon, 29.06.09 11:05, Daniel Wynne (daniel.wynne at mobotix.com) wrote:
> Hi Trent!
> These are great news for us! :-)
> We were seriously concerned about the issue, that the Avahi mDNS
> implementation prevented us from developing Linux camera management
> applications for huge setups.
> In the following I provide a short calculation to give you a hint of
> what we need:
> - Right now we have setups with deployments of up to 800 devices We
> do not think that deployments with even more devices in one network make
> sense, as this already can be considered as a individual feasibility
> study. But lets calculate with this worst case scenario and for the sake
> of convenience we even round it up to N = 1000 devices per network.
> - Since every device typically comes up with 2-3 ip addresses, we
> have to reserve cache entries for N*( 3 A's, 1 PTR, 1 SRV, 1 TXT. ) =>
> AVAHI_CACHE_ENTRIES_MAX >= 6*N = 6000 entries.
> - As the dbus limitations are concerned the maximum number of dbus
> objects per client will have to be increased, too. Since we have to
> create N*3 AddressRecordBrowsers, N*1 ServiceResolver, 1 Client, 2
> ServiceBrowsers => OBJECTS_PER_CLIENT_MAX >= 4*N + 3 = 4003 ~ 4000 entries
> As I do not have that much insight into the Avahi-code there might be
> even more limits that might have to be adapted to achieve a coherent
> If you need any additional information, let me know.
> Thank you Guys for the great support so far!
Hmm, with allowing more simulatenous clients the memory usage of the
cache will increase too. I wonder how bad that actually wuld
be. I.e. Daniel, how does the VSZ of the avahi daemon change when
connected to a en empty network vs. one of your fully equipped ones?
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the avahi