Opérations CRUD réalisées simultanément par plusieurs utilisateurs sur une

même table de la base de données sauvegardée dans un nuage privé : Test n°4, énergie consommée par un ordinateur lors d’accès synchrone à la même

base de données par un deuxième ordinateur

Les opérations peuvent également être réalisées par plusieurs personnes de façon synchrone ou asynchrone sur un même document. De façon asynchrone, la liste de composantes électroniques est éditée (insert) par un utilisateur (u1) au temps un (t1) est sauvegardée sur le nuage privé de l’organisation. Suite à sa publication sur le réseau de l’entreprise, un employé (utilisateur u2) le consulte (select) à la période t2. Au temps t3, un membre du département de la gestion des opérations de l’entreprise (utilisateur u3) met à jour (update) les délais de commande pour quelques produits de la liste. Un autre gestionnaire (utilisateur u4) supprime (delete) les données périmées de la liste.

L’énergie des ordinateurs de chaque utilisateurs qui effectue ces tâches peut être calculée et correspond aux paramètres déjà mesurés aux tests n°1 et n°2. Toutefois, À l’inverse du cas précédent, au lieu d’être accomplies les unes après les autres, les opérations de CRUD peuvent être réalisées de façon simultanée dans le nuage privé. La portabilité de l’information est offerte par le nuage. Les utilisateurs peuvent collaborer via un navigateur Web pour travailler sur un document avec plus flexibilité. L’ensemble des opérations CRUD peuvent réalisées de façon collaborative et synchrone. Plusieurs co-auteurs peuvent éditer (requête insert) le document en même temps, de façon synchrone en ligne et en temps réel. L’ensemble des opérations sont traitées sur le nuage centralisé.

De façon synchrone, les utilisateurs u1, u2, u3 et u4 mentionnés précédemment peuvent effectuer les opérations de façons concurrentes. Il suffit d’avoir un mot de passe et un droit d’accès au document. Par exemple, en même temps (à la période t1) que l’utilisateur (u1) édite, u2 peut le consulter, u 3 peut mettre à jour des entrées de la liste u4 peut supprimer de

la liste la partie qui n’est plus à jour. Les utilisateurs effectuent les fonctions CRUD sur des ordinateurs ayant des caractéristiques et paramètres identiques. Dans le test n°4, il est admis que deux utilisateurs peuvent exécuter chacune des opérations CRUD. L’effet des opérations accomplies par deux utilisateurs (u1 et u2) qui exécutent simultanément chacun des opérations CRUD à un taux léger (1000 entrées), modéré (4000 entrées), élevé (7000 entrées) et très élevé (9000 entrées) et qui sont sauvegardées sur un nuage privé, est mesuré sur l’ordinateur de chacun des usagers.

Les pourcentages de traitement des processeurs des ordinateurs des utilisateurs u1 et u2 utilisés pour mesurer l’influence sur chaque ordinateur des opérations CRUD exécutées simultanément et sauvegardées dans un nuage privé sont indiqués au tableau 3.10.

Tableau 3.10 Pourcentage (%) sur 100 secondes d’utilisation du processeur au repos et lors du traitement des requêtes SQL (INSERT, SELECT, UPDATE, DELETE) exécutées simultanément par deux utilisateurs (u1, u2) mesurées par Java-MySQL lors des conditions

standards S3 et sauvegardées dans un nuage privé

Requêtes SQL synchronisées entre les ordinateurs des utilisateurs u1 et u2 (u1- u2) et sauvegardées dans le nuage privé Utilisateur u1 Utilisateur u2 PR0 Pria PR0 Pria INSERT–INSERT 2.391 3.469 2.258 3.894 SELECT–SELECT 2.463 2.369 UPDATE–UPDATE 4.593 5.431 DELETE–DELETE 2.990 3.514 INSERT–SELECT 3.485 4.817 INSERT–UPDATE 3.635 5.163 INSERT–DELETE 3.602 4.952 SELECT–INSERT 2.582 3.072 UPDATE–INSERT 4.947 5.734 DELETE–INSERT 3.041 3.692 SELECT–UPDATE 2.567 2.712 SELECT–DELETE 2.499 2.560 UPDATE–DELETE 4.768 5.612

Les ordinateurs des utilisateurs u1 et u2 ayant les mêmes caractéristiques, pour les mêmes requêtes, à savoir insert-insert, select-select, update-update et delete-delete, le nombre de requêtes et le temps d’exécution consommés par chacun sont similaires (tableau 3.11).

Tableau 3.11 Temps d’exécution total et énergie moyenne consommée par les requêtes SQL exécutées simultanément par deux utilisateurs (u1, u2), mesurées par System.nanotime lors

des conditions standards S3 et sauvegardées dans le nuage privé

Opérations SQL synchronisées des utilisateurs u1-u2 Utilisateur u1 Utilisateur u2 # Requêtes SQL exécutées Temps d’exécution total (en ns) Seconde /requête Énergie moyenne (en joule/requête) # Requêtes SQL exécutées Temps d’exécution total (en ns) Seconde /requête Énergie moyenne (en joule/requête) INSERT–INSERT 7379 599957777441 0.081306109 0.031553 7488 599504694655 0.0800621 0.0471534 SELECT–SELECT 79314 300224957446 0.003785271 0.000098 79515 305517335989 0.0038423 0.0001535 UPDATE–UPDATE 7315 599937647192 0.082014716 0.065015 7473 599226107329 0.0801855 0.0915943 DELETE–DELETE 7295 600027927910 0.082251944 0.017737 7302 599950156025 0.0821624 0.0371506 INSERT–SELECT 14789 599956226471 0.040567735 0.015977 93595 301779197933 0.0032243 0.0029704 INSERT–UPDATE 7340 599984387224 0.081741742 0.036607 7508 599272880357 0.0798179 0.0834736 INSERT–DELETE 6866 599945149468 0.087379136 0.038094 6974 599990998583 0.0860325 0.0834378 SELECT–INSERT 84922 301671785820 0.00355234 0.000244 14569 599374166771 0.0411404 0.0120558 UPDATE–INSERT 7344 599946969564 0.081692125 0.075170 7509 599336400589 0.0798157 0.0998782 DELETE–INSERT 7273 599975677473 0.082493562 0.019303 7441 599524059188 0.0805704 0.0415936 SELECT–UPDATE 88553 296438801516 0.003347586 0.000212 14331 599026246488 0.0417993 0.0068317 SELECT–DELETE 100524 301333433523 0.002997627 0.000117 13888 599949342156 0.0431991 0.0046966 UPDATE–DELETE 7679 599949358650 0.078128579 0.066856 7621 599991511540 0.0787287 0.0950602

Ces valeurs sont comparées à celles consommées individuellement pour chaque activité CRUD enregistrée dans l’infonuagique (tableau 3.12). Lors du test insert-insert, il y a 7379 requêtes qui sont exécutées par u1 et 7488 exécutées par u2. L’énergie moyenne consommée par chacune pour l’exécution simultanée de la requête insert est 3.1553x10-2 joule/entrée pour le premier usager et 4.65319x10-2 _{joule/entrée pour le second (tableau 3.11). Lorsque}

chaque utilisateur exécute individuellement la requête insert, l’énergie moyenne est moindre, soit 4.594x10-3 joule/entrée pour u1 et 3.1714 x 10-2 joule/entrée pour u2(tableau 3.12).

Il en est de même pour les requêtes update et delete où il est légèrement plus efficient pour l’ordinateur d’exécutée ces requêtes individuellement que lorsqu’elles sont traitées simultanément avec un autre ordinateur. La mesure du temps d’exécution par l’UCT est facilité par une commande monolithe car elle n’a pas besoin de le décomposer en différentes étapes, à la différence de l’atomicité qui donne l’illusion que ces requête SQL sont effectuées en même temps et prennent instantanément plus de temps pour être exécutées, donc plus d’énergie. Bien que la différence soit minime, il faut penser que l’exécution à répétition et/ou pour plusieurs valeurs de la liste de composantes électroniques peut générer une empreinte énergétique non négligeable. En théorie, même si deux opérations comme update-update

exécutées de façon synchrone n’entrent pas en conflit, dans la logique elles peuvent être conflictuelles. Par exemple, si les deux utilisateurs mettent à jour en même temps la même clé primaire de la liste de composantes électroniques, en temps réel elles seront exécutées une après l’autre. L’ordinateur qui effectue en deuxième la mise à jour aura un temps d’exécution plus long que le premier, et ce, en raison de sa position (deuxième) et du temps d’ajustement du système pour permettre le traitement de la seconde modification. Chaque ordinateur consomme moins d’énergie lorsqu’ils exécutent de façon synchrone la commande

select pour lire un document simultanément.

Tableau 3.12 Temps d’exécution total, pourcentage d’utilisation du processeur et énergie moyenne consommée individuellement par les requêtes SQL insert, select, delete et update,

mesurées par System.nanotime de l’ordinateur u1 et de l’ordinateur u2 selon le nombre d’entrées obtenu au tableau 3.11 et sauvegardées dans le nuage privé

Utilisateurs _{requêtes SQL} Types de # Requêtes % processeur actif

(%PRi) % processeur au repos (%PR0) Variation du processeur (%PRi –%PRi) Temps d’exécution total (en sec) Énergie moyenne (en joule/requête) u1 INSERT (C) 7379 0.01515 0.01221 0.00294 320.28 0.004594 SELECT (R) 79314 0.01914 0.00693 170.24 0.000535 UPDATE (U) 7315 0.01703 0.00482 302.34 0.007172 DELETE (D) 7295 0.01344 0.00123 328.66 0.001995 u2 INSERT (C) 7588 0.02898 0.00892 0.02006 333.23 0.031714 SELECT (R) 71515 0.1191 0.11018 203.35 0.011279 UPDATE (U) 7473 0.03327 0.02435 313.52 0.036777 DELETE (D) 7502 0.04434 0.03542 322.44 0.054805

Dans la même table (liste de composantes électroniques) de la base de données pendant qu’un utilisateur édite le contenu, l’autre utilisateur peut : lire les informations édites ou autres informations, soit l’opération insert-select; mettre à jour le contenu, soit l’opération

insert-update; supprimer une entrée, soit insert-delete. Contrairement aux opérations

identiques (insert-insert, select-select, update-update et delete-delete) qui sont exécutées sur la même entrée, il n’y a pas de compétition sur le nuage pour leur traitement. Leur temps de traitement est donc plus proche que le temps de traitement des requêtes insert, select, update et delete exécutée individuellement.

Il faut noter que les opérations select-update et delete-insert effectuées chacune par un seul utilisateur (u1 fait l’opération select et u2 fait l’opération update, ou u1 fait un update et u2

fait un insert) consomme moins énergie sur chaque ordinateur que si elles sont effectuées simultanément sur le même ordinateur (test n°3). Dans un environnement de mise à jour collaborative, le contenu de documents modifiés doit être téléchargé sur le serveur à intervalles de temps réguliers, le temps d’exécution est alors favorable à l’exécution des requêtes individuellement.

CHAPITRE 4