Hai sa mai facem un pic de matematica.
Sa consideram ca un update se executa intr-un timp T, sa zicem intr-o suta de milisecunde. Cind faci un update pe S1, batch-ul executa update apoi asteapta executia trigger-ului. Pe S2 se executa din nou in T, apoi S2 asteapta se se execute pe S3 s.a.m.d. Pe Sn dureaza 100 ms apoi se intoarce. Deci Sn a asteptat 100ms, Sn-1 200ms, pe Sn-2 300 ms s.a.m.d. Timpul total de consumat in sistem de executarea update-ului este suma acestor timpuri, deci N(N+1)/2 * T. A nu se confunda cu durata de executie al update-ului, care este evident T*N.
In SQL Server exista o resursa foarte bine definita, anume numarul de 'worker threads'. Fiecare worker thread poate executa la un moment dat un singur batch (=request). Un worker nu poate abandona un batch pina ce nu il termina. Un bath care asteapta un raspuns de la un linked server este blocat, nu terminat, si consuma un worker. Numarul de worker threads este limitat. Hai sa consideram numarul implicit, 256 de worker threads. Cu acest numar putem determina limita absoluta, ideala, care ne spune cite write-uri putem face in sistem.
Cu 3 noduri ai la dispozitie 3*256 workere, care pot executa 7680 de taskuri de cite 100 ms fiecare. Un update in topologia 'inel' consuma 6 astfel de quate de cite 100 ms (1 pe S3, 2 pe S2 si 3 pe S1). Deci in conditzii ideale potzi sa obtzii 7680/6 = 1280 update-uri in sistem intr-o secunda. Cu 5 noduri, ai la dispozitzie 12800 de 'quante' si fiecare update consuma 15, deci potzi spera la 853 de scrieri pe secunda. Cu 20 de noduri ai nevoie de 210 'quante' pentru un update, rezultind un throughput de ~244 operatii pe secunda.
Hai sa consideram topologia mesh, fiecare se conecteaza la fiecare. Un update in aceasta topologie consuma T pe S1, apoi S1 updateaza S2 (=T), apoi updateaza S3 (=T) s.am.d. Timpul total consumat pe toate nodurile este 2N-1 (S1 consuma T*N pentru ca sta sa updateze S2...SN si la asta se adauga N-1 pentru fiecare timp T consumat de S2...S3). Pe 3 noduri un update consuma 5 'quante' (3 pe S1, 1 pe S2, 1 pe S3). Deci potzi scrie 7680/5=1536 operatii, o imbunatarire cu 120% fata de topologia 'inel'. Cu 5 noduri ai nevoie de 9 'quante' si obtii 1422 operatii pe secunda, cu 166% mai bine decit in inel. Cu 20 de noduri ai nevoie de 39 de 'quante' si potzi obtzine un throughput 1313 operatii, care este cu doar 538% mai bine decit in topologia 'inel'.
Se vede de fapt ca numarul de 'worker' threads ales si durata unui update (T) sint irelevante, diferenta vine din formula de timp linear pentru mesh (2N-1) fata de timp patratic ( N(N+1)/2 ) pentru 'inel'. Asta in ciuda faptului ca timpul de 'raspuns' al fiecarui update este identic in ambele topologii (T*N). Dar intr-una din topologii (mesh) exista un singur nod care astepta pe celelate, in timp ce in 'inel' toate nodurile astepta nodurile 'de la dreapta', cu exceptia ultimului.
Asa ca revin la intrebarea originala: care exact sint avantajele toplogiei in inel?
http://rusanu.com