On 10/19/2017 04:28 PM, Jake Zack wrote: > Can ods-signerd sign more than a single zone concurrently, or does the > job scheduler ensure that there is only one signing happening at a time?
The signer will sign as many zones as specified by WorkingThreads in the conf.xml at the same time. These "threads" are distributing the work of the actual signing over SignerThreads. If you specify 1 signerthreads and 4 workerthreads (a stupid configuration, but for clarification), 4 zones will be signed simultaneously, but it it will generate a signature from each of these zones alternating (roughly, it isn't absolutely fair). > If it can only sign one at a time, what happens if it gets 20 AXFR’s in > using the axfr adapter? Just queued? AXFRs are done by another thread outside of this pool. Of course its performance might get affected if the other threads very busy. There is just one thread for transfers, it will use asynchronous I/O to serve all requests. However when a zone is getting signed, there is a period in which it cannot simultanously serve the zone as well. This is being worked on for the next release of OpenDNSSEC. > If it can sign more than one at a time, is this based on number of > cores/threads? Any special considerations anyone can think of assuming > mysql backend? The SQL backend is at the moment only used for the enforcer, so there are no considerations for your signer here. The number of Worker/ Signer threads to use depends on how you do the actual signing. The signing process is heavily dependent on the speed and concurrency of creating the signatures. If you have an HSM, you should look in the documentation there on the optimum number of concurrent operations it can handle. Experimenting works quite well. If you are using a software based solution, like SoftHSM that uses the same processor as the signer daemon uses, in general you get the best performance setting the number of SignerThreads to the number of cores. In case of hyperthreading or likewise technology the number of virtual cores. Setting it one above the actual number of cores in fact makes the actual throughput even better, but at the expense of a general less responsive system, therefor I'd recommend the number of cores to use. \Berry > > > > Thanks, > > -Jacob Zack > > DNS Architect – CIRA (.CA TLD) > > > > _______________________________________________ > Opendnssec-user mailing list > [email protected] > https://lists.opendnssec.org/mailman/listinfo/opendnssec-user > _______________________________________________ Opendnssec-user mailing list [email protected] https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
