Jump to content
brice.wernet

Optimisations inutiles?

Recommended Posts

Bonjour,

Juste un post pour avoir un peu l'avis d'autres développeurs.

Il y a longtemps, je faisais attention à utiliser les bons types de variables (short/long/int/float). Maintenant, dans la plupart des programmes que je croise, à part le int lié à la plate-forme, tout est en long et les nombres en décimaux.

Avant, on faisait attention dans les bases de données au type de la clé, au "collation", au format char/varchar/nvarchar... Maintenant, je vois des tables indexées sur des nvarchar contenant un code 4 lettres sans string collation...

Même si ces optimisations n'ont pas un impact significatif sur les perfs au moment du dev, dans 4 ans, quand on va faire une requête avec un join sur un nvarchar sans collation, on va quand même mettre une pression sur le CPU et la RAM (déjà vécu avec un générateur de BDD qui générait un GUID mais le faisait stocker sur un char(36)).

Qu'en pensez-vous? Est-ce que vous vous dites "de la RAM, du CPU, de la BP disque et de la bière il y en aura toujours", ou "plus c'est optimisé, plus je peux en mettre sur le même serveur"?

De même, pour les échanges on utilise XML ou JSON, mais leur efficacité face à une sérialisation binaire est ridicule, ça mange de la BP réseau, de la RAM et du CPU pour le décodage en permanence. C'est anti-green IT tout cela, non?

Edited by brice.wernet
Pour couper court aux quand quand
  • Like 2

Share this post


Link to post
Share on other sites

Je suis un jeune développeur et je t'avoue que les optimisations dont tu parles, on ne me les a jamais inculquées ni demandé de faire attention. Notamment sur tes exemples de types en BDD. À part un "il est trop long ou trop court ton nvarchar", les optimisations se font rarement là dessus. Là seule erreur que j'ai vue c'est des entiers stockés en varchar et la conversion ralentissait tout.

Pour ce qui est du JSON ou XML, effectivement c'est moins efficace, mais je préfère que les données qui transitent restent humainement compréhensibles.

Share this post


Link to post
Share on other sites

Perso, je suis peut-être aussi de la vieille école, mais je fais attention au typage. Pas besoin de déclarer un long si je n'en ai pas besoin.

Après, en dehors du stockage BDD, il vaut parfois mieux utiliser un Int32 ou Int64 qu'un Byte car le traitement CPU est optimisé pour ce genre d'entiers.

Créer des index sur des chaînes, c'est rarement intelligent, mais normalement, ça ne pose pas de problème sur des chaînes courtes avec peu de valeurs différentes. Bref, ça va vraiment dépendre de ce que va contenir le champ.

Quand au XML et au JSON, pour le premier, c'est à bannir, beaucoup trop verbeux et peu lisible. Pour le second, je n'utilise que ça, c'est très rapide à traiter et si on veut le stocker ou le faire transiter sur un réseau, une compression LZ est rapide et efficace. De plus, des tas de bibliothèques sont optimisées pour le traiter et c'est facile à analyser pour déboguer.

  • Like 1

Share this post


Link to post
Share on other sites

Je n'ai toujours utilisé que 2 typages dans mes BDD (ça fait 35 ans) : varchar et decimal (un peu de Blob aussi).

Ces deux formats suffisent et sont correctement traités quelques soient les langages, et les connecteurs.

Pour les langages, j'en ai rencontré plusieurs qui n'avaient que 3 types : string, number, boolean Aussi bien des vieux (BASIC) que des récents (SQL-Windows), preuve qu'on a pas besoin des milliers de raffinements disponibles (MS est très for la-dessus).

Et on a des machines débordant de ressources a des prix dérisoires, alors l'optimisation je m'assois dessus tant que mes traitements répondent au quart de tour. Une bonne requete SQL y'a que çca de vrai.

Share this post


Link to post
Share on other sites

Tu ne dois pas bosser sur des grandes quantités de données alors 😉

Dans ma boîte actuelle (et pour la première fois), l'optimisation est le mot d'ordre. Que des requêtes simples avec des retours limités (celui qui fait un SELECT * meurt dans d'atroces souffrances !).

Ensuite, on traite en mémoire haute en évitant de charger la pile (utilisation d'interface plutôt que d'instanciation de classes), mise ne place de caches locaux pour n’appeler la base que si nécessaire, traitements en parallèle dès que possible (sans en abuser), etc.

Après, je bosse dans la paye, et faut brasser une très grande quantité de données et quand on voit les serveurs sous-dimensionnés des clients, l'optimisation est vitale !

Share this post


Link to post
Share on other sites
Il y a 11 heures, Bamaury a écrit :

 À part un "il est trop long ou trop court ton nvarchar", les optimisations se font rarement là dessus. Là seule erreur que j'ai vue c'est des entiers stockés en varchar et la conversion ralentissait tout.

La taille importe peu... Je connais bien SQL Server, en gros, tu peux faire un nvarchar(MAX) au moment d'enregistrer la donnée:

* Si la valeur est courte, elle passe dans la ligne de données sans même indiquer la taille (8 octets maxi donc 4 char). Sinon SQL server le met à la suite avec une indication de la taille. Si la ligne déborde (> 8ko), la valeur est stockée en tant que référence à une autre ligne de stockage long et la valeur est stockée hors d ela ligne (donc si tu fais un select * , il devra lire au moins 2 lignes qui ne sont pas stockées au même endroit -> perte de perfs).

Sous SQL server, tout est lu par défaut par tranche de 8ko: plus tu en mets en 8ko, et plus il lit de tranches de 8ko qui sont stockées à la suite sur le disque, plus ça vite.

Globalement, les moteurs se ressemblent sur ce point là.

Il y a 7 heures, Aloyse57 a écrit :

Je n'ai toujours utilisé que 2 typages dans mes BDD (ça fait 35 ans) : varchar et decimal (un peu de Blob aussi).

Le décimal a l'avantage d'être "naturellement compris" par le développeur, contrairement à la virgule flottante. Le varchar est maintenant souvent dépassé et nécessite un nvarchar. Je comprends le si ça marche suffisamment bien, pourquoi changer? Mais dans un cadre de mutualisation des ressources, suppression de serveur, réduction des licences donc des coeurs, j'ai un doute avec des applis dont les SELECt déclenchent systématiquement un table scan...

 

Il y a 7 heures, Edtech a écrit :

Que des requêtes simples avec des retours limités (celui qui fait un SELECT * meurt dans d'atroces souffrances !).

 quand on voit les serveurs sous-dimensionnés des clients, l'optimisation est vitale !

Normal de crucifier un SELECT *. Ceci dit, j'aimerais crucifier aussi les gars qui ont décidé que dans une clause SELECT, la liste des colonnes serait avant le FROM...

Quand aux serveurs, s'ils suffisent, ils ne sont pas sous-dimensionnés 🙂 

Bon, je compatis, je subis les logiciels de paye en tant qu'utilisateur, et tes oreilles doivent siffler 🙂 . La paye et la compta, ce sont les 2 domaines les plus gourmands dans mes expériences et ils sont tous les 2 critiques.

 

 

Au final donc, peu d'intérêt pour les optimisations sauf cas particulier. Et à ce moment, il faut sortir toute l'artillerie...

Merci! Je ne vais plus insister dessus dans mes "formations"

Share this post


Link to post
Share on other sites
Il y a 23 heures, Edtech a écrit :

Tu ne dois pas bosser sur des grandes quantités de données alors 😉

...
Après, je bosse dans la paye, et faut brasser une très grande quantité de données et quand on voit les serveurs sous-dimensionnés des clients, l'optimisation est vitale !

ERP de quelques centaines de tables qui ont 20ans de données dedans (certaines ont des millions de records) . Je sors aussi la paie de 1000 employés par semaine (on est payé à la semaine ici), donc 52x historique au lieu de 12x.

Et le tout est dans un SQL Server 2003, l'ERP sur un W2K (clients sur W10x64).

Je ne sais pas si tu trouves ça gros ou petit, mais je trouve ça pas mal comme BDD pour détecter les requêtes maladroites.😅

Share this post


Link to post
Share on other sites

Tiens, c'est pas courant à la semaine. 1000 payes, ça va, c'est encore léger. Et puis, tu utilises SQL Server, nous Interbase 😅 (pas de réflexions sur le sujet, merci 😁).

Après, ça dépend surtout du turnover. On a des clients qui renouvellent 75% du personnel par mois (énormément d'intérim et de CDD), avec donc pour un même salarié parfois 4 ou 5 contrats par mois ! Tu fais ça sur 5000 payes, ça rame sévère (on est à 1,2s la paye environ, on veut diviser ce temps par 10).

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×
×
  • Create New...