Soumettre l’optimisation au test

test.
A noter que chaque résultat de test est
une représentation type de cinq à  six
échantillons du même test. J’ai effectué
tous les tests pendant les heures
creuses, entre 10 heures du soir et 6 heures du matin, pour éviter toute
charge intempestive des autres applications.

Comme la procédure stockée
sp_start_job démarre un job et revient
immédiatement sans attendre qu’il se
termine, c’est une procédure stockée
asynchrone (c’est-à -dire que l’exécution
et le retour de cette procédure
stockée ne signifient nullement la fin
du job qu’elle a démarré). L’étape start
distributors dans un job Snapshot
Agent (démarre donc essentiellement
tous les jobs Distribution Agent simultanément.
Pour réaliser des distributions
en série (dans les tests 2 et 4), sélectionnez
d’abord n’importe quelle
option schedule-type pour tous les
jobs Distribution Agent excepté Start
automatically when SQL Server Agent
starts, puis désactivez les programmes
(schedules). Le choix d’une option
schedule-type empêche l’étape Run
agent (c’est-à -dire la commande distrib.
exe) de s’exécuter de façon continue.
Deuxièmement, ne démarrez
qu’un job Distribution Agent à  l’étape
start distributors du job Snapshot
Agent, puis insérez une autre étape
start distributors avant la dernière
étape du premier job Distribution
Agent démarré. Cette séquence démarre
un autre job Distribution Agent,
et ainsi de suite, séquentiellement. Le
tableau 1 résume les résultats de ces
tests.

La différence de performance la
plus significative entre les distributions
optimisées de type simultané et séquentiel
(c’est-à -dire entre le test 1 et le test 2) se manifeste aux étapes drop
et recreate. Les raisons sont claires : les
étapes drop et recreate ont lieu sur
chaque abonné indépendamment,
sans intervention du distributeur. Pour
des distributions simultanées, une
seule étape drop et une seule étape recreate
semblent avoir lieu – une complexité
de O(c) (complexité de temps
constant) indépendamment du
nombre d’abonnés – tandis que pour
les distributions séquentielles à  n
abonnés, n étapes drop et recreate auront
lieu – une complexité de O(n)
(complexité de temps linéaire).
Pour plus d’informations sur le chiffrage mathématique
du temps d’exécution, voir
l’article « Ouvrez la voie à  la réplication
snapshot à  grande échelle ».
L’étape bcp intervient entre un distributeur et n abonnés. Au-delà  d’un
certain seuil t, le nombre de processus
bcp simultanés commence à  surcharger
le distributeur et à  perdre l’avantage
de la simultanéité. Pour optimiser
encore davantage, une personnalisation
plus élaborée exécuterait t commandes
sp_start_job sur t jobs
Distribution Agent en même temps
que l’étape start distributors du job
Snapshot Agent. En supposant que ces
jobs se termineront à  peu près à  la
même heure, choisissez un job
Distribution Agent arbitraire et insérez
une autre étape start distributors avant
l’étape recreate pour démarrer un
autre lot de jobs Distribution Agent. Il
en résulte des lots séquentiels (serial
batches) de t distributions simultanées.
Comme l’étape start distributors
est asynchrone, elle se chevauche avec son étape suivante, recreate. En réalité,
votre job aurait n/t lots d’étapes drop
et bcp, mais une seule étape recreate
(celle du dernier lot).