Why are XFRs to Secondaries equally fast?
Hello! Yesterday I made some tests transferring a zone with 50mio RRs to 35 Secondaries. I measured the time between: - Primary logs "zone test/IN: sending notifies" - Primary logs "client : transfer of 'test/IN': AXFR-style IXFR ended" What makes we wonder is, that for several secondaries the XFR duration is equally fast although these secondaries are globally distributed with different RTTs and different VMs: 173 seconds 173 seconds 404 seconds 405 seconds 609 seconds 620 seconds 622 seconds 638 seconds 838 seconds 838 seconds 839 seconds 839 seconds 843 seconds 848 seconds 859 seconds 1031 seconds 1032 seconds 1032 seconds 1035 seconds 1037 seconds 1038 seconds 1038 seconds 1038 seconds 1043 seconds 1702 seconds 2359 seconds 2361 seconds 2361 seconds 2361 seconds 2361 seconds 2361 seconds 2361 seconds 2361 seconds 2361 seconds 2362 seconds For example, there are 8 secondaries (Mumbai, LosAngeles, Melbourne, Atlante, SaoPaulo...) to which the XFR took 2361 seconds. Are there some mechanisms in Bind that put multiple XFRs together into a common stream? Or do you have any other ideas how it come that several XFRs are equally fast? Thanks Klaus -- Klaus Darilion, Head of Operations nic.at GmbH, Jakob-Haringer-Straße 8/V 5020 Salzburg, Austria -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Why are XFRs to Secondaries equally fast?
On 27. 07. 23 11:17, Klaus Darilion via bind-users wrote: Hello! Yesterday I made some tests transferring a zone with 50mio RRs to 35 Secondaries. I measured the time between: -Primary logs "zone test/IN: sending notifies" -Primary logs "client : transfer of 'test/IN': AXFR-style IXFR ended" What makes we wonder is, that for several secondaries the XFR duration is equally fast although these secondaries are globally distributed with different RTTs and different VMs: ... For example, there are 8 secondaries (Mumbai, LosAngeles, Melbourne, Atlante, SaoPaulo...) to which the XFR took 2361 seconds. Are there some mechanisms in Bind that put multiple XFRs together into a common stream? Or do you have any other ideas how it come that several XFRs are equally fast? Are you sure all these transfers were _actually_ running in parallel? I suspect it will boil down to some sort of configured limit like transfers-out transfers-in transfers-per-ns serial-query-rate which cause some transfers to serialize and reduce parallelism. See https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-serial-query-rate https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-transfers-in options for tuning. Consumption speed might be hampered by slow storage (zone journaling does lots and lots of fsync()s, at least when you test IXFR). -- Petr Špaček Internet Systems Consortium -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
AW: Why are XFRs to Secondaries equally fast?
Hi Petr! > > For example, there are 8 secondaries (Mumbai, LosAngeles, Melbourne, > > Atlante, SaoPaulo...) to which the XFR took 2361 seconds. > > > > Are there some mechanisms in Bind that put multiple XFRs together into > a > > common stream? Or do you have any other ideas how it come that several > > XFRs are equally fast? > > Are you sure all these transfers were _actually_ running in parallel? Yes. I checked the logs on the secondaries too and also these logs say that the XFR were finished at the same second. > I suspect it will boil down to some sort of configured limit like > transfers-out > transfers-in > transfers-per-ns > serial-query-rate > which cause some transfers to serialize and reduce parallelism. $ egrep 'serial-query-rate|transfers' * named.conf.options:serial-query-rate 500; named.conf.options:transfers-in 50;// number of total concurrent zone transfers from the masters to me named.conf.options:transfers-per-ns 50;// number of concurrent zone transfers per master from the masters to me named.conf.options:transfers-out 200; // number of concurrent zone transfers from me to my slaves regards Klaus -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
