Discussion :

[ngaya]

Bonjour,
Je suis entrain de faire une étude comparative de performance sur une table de 3615000 lignes avant le cryptage et après le cryptage. dans ce cas , j'ai utilisé l'outil set statistics time io on, voici les resultats:

1) Avant le cryptage:
Execution Time 145.
SQL Server cpu time: 14500 ms. SQL Server elapsed time: 186583 ms.

(3615000 rows affected)
Parse and Compile Time 0.
SQL Server cpu time: 0 ms.

2) Après le crypatage des colonnes:

- Pour le cryptage à 128 bytes:
Execution Time 162.
SQL Server cpu time: 16200 ms. SQL Server elapsed time: 185293 ms.

(3615000 rows affected)
Parse and Compile Time 0.
SQL Server cpu time: 0 ms.

-Pour le cryptage à 192 bytes:

Execution Time 169.
SQL Server cpu time: 16900 ms. SQL Server elapsed time: 185633 ms.

(3615000 rows affected)
Parse and Compile Time 0.
SQL Server cpu time: 0 ms.


- Pour le cryptage à 256 bytes:

Execution Time 158.
SQL Server cpu time: 15800 ms. SQL Server elapsed time: 184316 ms.

(3615000 rows affected)
Parse and Compile Time 0.
SQL Server cpu time: 0 ms.


Comment puis-je interperter ces resultats et faire une comparaison sur ces resultats. j'ai l'impression que les resultats sont presque pareille.

Merci de vos commentaires.

Cordialement.

[mpeppler]

Premièrement, il faut bien vérifier que le SELECT fasse le décryptage correctement.
Si c'est le cas il semble que la surcharge de décryptage soit très faible, ce qui est un peu bizarre. Est-ce qu'il y a beaucoup de données cryptées par ligne ?

Un élément à prendre en compte dans ces mesures est le nombres d'IO physiques qui sont nécessaires. Peut-être que dans le premier SELECT il y avait passablement d'IO physiques alors que dans les suivants plus de données étaient en cache - dans ce cas les mesures de temps sont peut-être pas si significatifs.

En somme il nous faudrait plus d'information pour pouvoir déterminer la surcharge du cryptage.

Michael

[dngaya]

Merci de votre reponse.
Concernant le nombre de lignes crypté par ligne, ce qui est vrai, après verification,il y en a pas beaucoup, c'est à dire, voici ci-dessous la structure de la table où il y aura le cryptage de certaines colonnes:
CREATE TABLE dbo.PERSONNE
(
id_personne numeric(18,0) IDENTITY,
nom_personne varchar(50) NULL,
prenom_personne varchar(50) NULL,
telbureau_personne varchar(50) NULL,
teldomicile_personne varchar(50) NULL,
telmobile_personne varchar(50) NULL,
codepostal_personne varchar(50) NULL,
secure_id bit NOT NULL,
enregistrement_personne bit NOT NULL
)

les colonnes à crypter sont:teldomicile_personne ,telmobile_personne et codepostal_personne .

Voici le nombre total de données pour chaque colonne ayant la valeur not null:

1) pour teldomicile_personne=30000
2)pour telmobile_personne=30000
3)pour codepostal_personne=15000

ci-dessous, les statistiques pour les io:
--------------------------------------

1) avant cryptage:

Table: Mytable scan count 1, logical reads: (regular=87858 apf=0 total=87858),
physical reads: (regular=8 apf=85175 total=85183), apf IOs used=85175
Total writes for this command: 0

(3615000 rows affected)

2) après cryptage:

- pour 128 bytes:


Table: Mytable scan count 1, logical reads: (regular=88847 apf=0 total=88847),
physical reads: (regular=8 apf=86202 total=86210), apf IOs used=86202
Total writes for this command: 0

(3615000 rows affected)

- pour 192 bytes:


Table: Mytable scan count 1, logical reads: (regular=88847 apf=0 total=88847),
physical reads: (regular=113 apf=86095 total=86208), apf IOs used=86094
Total writes for this command: 0

(3615000 rows affected)

- pour 256 bytes:


Table: Mytable scan count 1, logical reads: (regular=88847 apf=0 total=88847),
physical reads: (regular=8 apf=88840 total=88848), apf IOs used=88839
Total writes for this command: 0


La commande de select est: select * from PERSONNE

Merci de vos conseils.

[mpeppler]

Le nombre d'IO physiques est sensiblement le même entre les différentes exécutions, donc cet élément ne viens pas pérturber l'analyse.

Si on revient au premier message, on voit qu'un exécution sans cryptage prend environs 14.5 secondes, et avec cryptage entre 15.8 et 16.9 secondes, soit une surcharge d'env. 10%.

Si les champs cryptés ne font pas partie d'indexes alors tu peux peut-être t'arrêter là. Par contre, si ces champs sont indexés alors il faudra faire des tests de requêtes avec l'utilisation des indexes (clause WHERE, jointure, etc) pour analyser l'effet du cryptage sur la performance.

Michael