1. #1
    Membre éprouvé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2003
    Messages
    605
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2003
    Messages : 605
    Points : 1 289
    Points
    1 289
    Billets dans le blog
    5

    Par défaut Activation du trace flag 1118, et impact sur la taille des fichiers de données (?)

    Bonjour,

    J'envisage d'appliquer le Trace Flag 1118, celui qui permet d'éliminer définitivement les contentions sur les pages SGAM, en n'utilisant plus les extensions mixtes, ...

    En fait, je me pose la question par rapport à l'impact de ce Trace Flag 1118 sur la taille des bases de données existantes. En effet, sauf erreur d'interprétation de ma part, le fait de ne plus utiliser les extensions mixtes, et de n'utiliser, en lieu et place, uniquement les extensions uniformes, aura fatalement un impact sur la tailles de l'espace réellement utilisé dans les fichiers de données.
    Ma question ou plutôt ma préoccupation est sur ce dernier point :
    Quel est selon vous l'ordre de grandeur de l'augmentation de la taille de l'espace réellement utilisé dans les fichiers (?) : infinitésimal, 5%, 10%, 30% ou voire plus (?)
    Et plus généralement, quelles sont vos recommandations et vos retours d'expérience quant à l'activation de ce Trace Flag 1118, notamment par rapport l'augmentation éventuelle, plus ou moins importante (?), de la taille de l'espace réellement utilisé dans les fichiers de données.

    Merci d'avance,

    A+
    "Une idée mal écrite est une idée fausse !"
    http://hamid-mira.blogspot.com

  2. #2
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 333
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 333
    Points : 40 139
    Points
    40 139
    Billets dans le blog
    1

    Par défaut

    Infinitésimal et pas une bonne idée...

    En effet SQL Server utilise une extensions MIXTE pour la page racine de tout objet et pour les pages suivantes une extension UNIFORME...
    En utilisant le TF 1118 vous ne faite que dire que les premières pages, y compris la racine seront dans une seule et même extension... Cela ne change donc pas grand chose.
    Le TF 1118 a été créé spécialement pour la base tempdb du fait des accès concurrents et c'est là ou le bât blesse. En effet, les différentes tables créée par différents utilisateurs verront toutes leurs page racine dans une même extension à concurrence de 8 ce qui pose des problèmes effectif de contention d'accès concurrentiels dans les pages systèmes...

    La raison pour laquelle SQL Server mets les pages de différents petits objets dans une seule et même extension (à concurrence de 8 objets différents au maximum) est liée à l'optimisation. En effet, si une des premières page n'est pas en cache alors l'extension contenant cette page racine est montée en mémoire ramenant ainsi les pages demandée et 1 à 7 autres pages, faisant ainsi des lectures anticipées... Comme les pages racines sont les plus utilisées, et qu'il y a fort à parier qu'il y en aura beaucoup dans le lot, alors, en peu de temps, toutes les pages racines d'une BD sont rapidement présentes dans le cache... C'est plutôt avantageux !

    Depuis la version 2016, le TF 1118 est systématique (on ne peut pas le "retirer") et appliqué à toutes les bases et en corrélation, pour la base tempdb à la création de multiples fichiers de données.

    Mais pour les bases de production, il ne s'agit pas toujours d'une bonne idée, d'où la possibilité de revenir au mode classique (extension mixte pour les premières pages) à l'aide de la commande :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    ALTER DATABASE CURRENT SET MIXED_PAGE_ALLOCATION ON;
    Enfin il serait intéressant de noter dans quelle mesure ceci affecte les performances dans LINUX envers les différents file systems...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  3. #3
    Membre éprouvé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2003
    Messages
    605
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2003
    Messages : 605
    Points : 1 289
    Points
    1 289
    Billets dans le blog
    5

    Par défaut

    Bonjour,

    Merci beaucoup SQLPro pour ces explications très claires et très instructives.

    Donc, le problème n'est pas du tout celui que j'appréhendais, et qui serait relatif à une possible augmentation de la taille de l'espace utilisé, mais comme tu viens de l'expliquer, le problème ou le danger se situe ailleurs !

    ET comme tu dis le "Le TF 1118 a été créé spécialement pour la base tempdb", mais, le problème c'est qu'il s'applique, sans exception, à toutes les bases de données sur les version SQL Server 2008 R2, 2012 et 2014.

    Tes explications, et tes mises en gardes concernant l'utilisation du cache ("toutes les pages racines d'une BD sont rapidement présentes dans le cache") font que je vais finalement reconsidérer ma décision. Je ne vais plus activer le TF 1118, d'autant plus que le Serveur en question héberge plusieurs bases de données, et donc, si j'active le TF 1118, je risque fort de me retrouver avec une saturation du cache par les pages racines et extensions de tous les objets émanant de ces nombreuses et différentes bases !

    Peut-être que l'activation du TF 1118 serait envisageable sur un Serveur dédié à un seul client, hébergeant au plus une ou deux bases de données de production.

    Je vais donc devoir attendre la mise à jour vers SQL Server 2016 pour au moins régler le problème de la base tempdb.

    Encore une fois, merci beaucoup SQLPro pour tes explications.

    A+
    "Une idée mal écrite est une idée fausse !"
    http://hamid-mira.blogspot.com

  4. #4
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 333
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 333
    Points : 40 139
    Points
    40 139
    Billets dans le blog
    1

    Par défaut

    Comme toujours, faire des essais et mesurer...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  5. #5
    Modérateur
    Avatar de elsuket
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    janvier 2005
    Messages
    5 808
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2005
    Messages : 5 808
    Points : 11 930
    Points
    11 930

    Par défaut

    Bonjour,

    Si la base est relativement statitique en termes de tables, c'est à dire qu'on n'en crée pas une palanquée qu'on supprime peu après, mais plutôt qu'on en crée et qu'on les écrit, avec quelques CREATE TABLE et DROP TABLE de temps en temps, cela ne pose aucun problème. La grande majorité des bases que j'administre à l'heure actuelle sont sous SQL Server 2014, et toutes les instances ont ce trace flag activé : je n'ai pas observé de problème particulier.
    C'est d'autant plus vrai si le serveur dispose d'une quantité de RAM décente, ce qui est certainement souvent le cas maintenant, notamment du fait du faible coût de celle-ci par rapport aux gains qu'elle procure.

    C'est intéressant pour TempDB pour limiter la contention d'accès aux pages SGAM, puisque cette base de données supporte les variables de type TABLE, les tables temporaires, et tout un tas d'autres objets internes.
    C'est donc une charge de travail particulière, qui mérite effectivement que les étendues partagées soient défavorisées au bénéfice des étendues uniformes.

    @++

  6. #6
    Membre éprouvé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2003
    Messages
    605
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2003
    Messages : 605
    Points : 1 289
    Points
    1 289
    Billets dans le blog
    5

    Par défaut

    Bonjour Elsuket,

    Et Merci pour ces précisions complémentaires.
    Les bases de données clients (donc hors bases systèmes, tempdb ..) sont "statiques" , dans le sens où il n'y a pas de CREATE TABLE et de DROP TABLE à la volée dans les bases de données utilisateurs.
    Oui, nous sommes tous d'accord que c'est intéressant pour la base système tempdb. Sur ce point, on peut presque dire qu'il n'y a plus débat.
    Mais, comme le TF 1118, jusqu'à la version SQL Server 2014 comprises, s'applique, sans exception, à toutes les bases de données, on se posait la question de son impact lié aux autres bases de données utilisateurs.
    Alors, qu'en est-il des questions ou les remarques ci-dessus soulevées par SQLPro, et relatives aux lectures anticipées ramenant 1 à 7 autres pages lorsque l'objet lu est doté d'une extension uniforme. Est-ce cela ne risque pas d'avoir un impact sur l'utilisation du Buffer Cache des données, notamment lorsque l'Instance SQL Serverr est mutualisée et héberge plusieurs dizaines de bases de données ? En effet, les 1 à 7 pages supplémentaires lues de chaque objet ne seront peut-être pas toujours utiles !

    C'est une des raisons, si j'ai bien compris les propos et les explications de SQLPro, pour lesquelles SQLPro n'exclue pas complètement, le cas échéant, de revenir au mode extension mixte pour les bases de données utilisateur (SET MIXED_PAGE_ALLOCATION ON).

    C'est pour cela, que d'après moi, pour une instance dédiée à un client avec quelques bases de données (disons de 1 à 5) hors bases système, je n'aurais pas d'hésitation, à activer le TF 1118, en revanche dans d'autres circonstance ce ne sera peut-être pas une bonne idée (?).
    Bien évidemment, des mesures doivent être effectuées avant et après chaque activation de TF.

    Merci.

    A+
    "Une idée mal écrite est une idée fausse !"
    http://hamid-mira.blogspot.com

  7. #7
    Modérateur
    Avatar de elsuket
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    janvier 2005
    Messages
    5 808
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2005
    Messages : 5 808
    Points : 11 930
    Points
    11 930

    Par défaut

    Est-ce cela ne risque pas d'avoir un impact sur l'utilisation du Buffer Cache des données, notamment lorsque l'Instance SQL Serverr est mutualisée et héberge plusieurs dizaines de bases de données ?
    J'ai les deux cas :
    • des instances dédiées, avec une seule base de données utilisateur; le serveur n'héberge qu'une seule instance SQL Server
    • des instances mutualisées, avec une grosse dizaine de base de données chacune, hébergeant une ou deux instances SQL Server; quand il y en a deux, l'une des deux est assez peu utilisée, et sont systématiquement sous des versions différentes de SQL Server


    Revenons à la raison pour laquelle la distinction entre le SGAM et les GAM a été implémentée. Le moteur lit toujours une extension, c'est à dire 8 pages, donc 64Ko.
    Au siècle dernier (), le stockage était plutôt (très, voire très très) cher, et comme nous le savons, cela a bien changé depuis, que ce soit les pour les disques ou la RAM.
    Le but est bien sûr d'utiliser l'espace de stockage le plus efficacement possible, d'autant que son prix était très élevé.

    Pour cette raison, les 8 premières pages d'une nouvelles tables ou index étaient systématiquement allouées dans des étendues partagées, donc tracées dans les SGAM.
    De cette manière, les tables et index ne croissent en taille que par incréments de 8Ko (la taille d'une page), et les tables et index les plus petits occupent un minimum d'espace.
    Dès le moment où la table ou l'index nécessitent une neuvième page, alors celle-ci est allouée dans une étendue uniforme, donc tracée dans les GAM.

    Les points soulevés par SQLPro sont tout à fait pertinents, surtout lorsque la quantité de RAM est un faible pourcentage de la taille totale des bases de données.
    En effet dans ce cas, il est tout à fait possible que l'on réalise de nombreuses IO disques, donc il est très avantageux d'avoir les pages racines des tables et index en une seule opération IO.
    Si l'on a déjà accédé à des pages d'une table, il y a fort à parier que, pour servir d'autres transactions, on va accéder à des pages "proches" de celle dont on a eu besoin à un instant donné.

    Dans le cas inverse, la quantité de RAM est proprement dimensionnée par rapport à la fenêtre de données utile de la base de données. Je suppose que, de nos jours, c'est le cas sur la plupart des instances SQL Server.
    L'effet d'optimisation obtenu par les SGAM est alors minimisé, sauf pour le cas où on crée et supprime beaucoup de tables dans lesquelles on stocke moins de 64Ko.

    @++

  8. #8
    Membre éprouvé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2003
    Messages
    605
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2003
    Messages : 605
    Points : 1 289
    Points
    1 289
    Billets dans le blog
    5

    Par défaut

    Bonjour Elsuket,

    Et Merci beaucoup pour ces explications complémentaires ô combien éclairantes sur le fonctionnement interne des allocations de pages en lien avec le paramétrage du TF 1118. On comprend beaucoup mieux le pourquoi du comment.

    Ton idée de radio entre la mémoire disponible pour SQL Server et la taille totale réellement utilisée dans les fichiers de données de l’ensemble des bases de données de l’instance me parait intéressante comme "baseline", sachant toutefois que dans une base de données, il peut y avoir une partie "active, en cours", c.à.d. régulièrement consultée et modifiée, et une autre partie "historique" faisant l’objet de très peu de lectures et/ou écritures. Mais bon, l’idée me parait très intéressante.

    Je vais donc suivre tes recommandations tout en tenant compte des remarques pertinentes soulevées par SQLPro. Je vais activer le TF 1118 et faire des mesures avant et après, et si je constate une nette amélioration, je garde le TF 1118, dans le cas contraire (pression mémoire, fortes activités ou latences I/O etc..), je reviendrais en arrière et je désactiverais le TF 1118.

    Encore une fois, Merci beaucoup pour tes explications.

    A+
    "Une idée mal écrite est une idée fausse !"
    http://hamid-mira.blogspot.com

  9. #9
    Membre expérimenté
    Homme Profil pro
    DBA SQL Server
    Inscrit en
    octobre 2012
    Messages
    597
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : DBA SQL Server
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : octobre 2012
    Messages : 597
    Points : 1 395
    Points
    1 395

    Par défaut

    Citation Envoyé par hmira Voir le message
    Je vais activer le TF 1118 et faire des mesures avant et après
    Hamid,

    Pourrais-tu stp me dire comment tu vas mesurer cela?
    Ce que nous avons fait pour nous-même meurt avec nous, ce que nous avons fait pour les autres et le monde est immortel. Albert Pike

    http://www.datacrossroad.be

  10. #10
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    août 2005
    Messages
    5 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : août 2005
    Messages : 5 001
    Points : 11 523
    Points
    11 523

    Par défaut

    Personnellement je mets ce traceflag par défaut depuis un moment sur les instances de mes clients. Je n'ai pas vu de montée spectaculaire du stockage après coup.

    En effet l'impact sur le stockage est négligeable sur la plupart des environnements vu que ce traceflag ne touche de toute façon que les premières 8 pages d'une structure (table / indexes). A moins d'avoir des milliers de petites tables dans une base généralement l'impact est mineur (et encore il faudrait mesurer sur les environnements actuels qu'on peut voir ...).

    Il y a bien entendu toujours un prix à payer mais je trouve qu'il reste négligeable (surtout sur les environnements actuels) par rapport au gain apporté. C'est d'ailleurs un des arguments de Microsoft pour l'avoir porté par défaut sur 2016.

    Après comme dit par SQLPro a toujours la possibilité de revenir en arrière si jamais ... SQL 2016 est plutôt bien pour ca car le changement est au niveau de la bases de données

    ++

  11. #11
    Membre éprouvé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2003
    Messages
    605
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2003
    Messages : 605
    Points : 1 289
    Points
    1 289
    Billets dans le blog
    5

    Par défaut

    Citation Envoyé par janlouk Voir le message
    Hamid,

    Pourrais-tu stp me dire comment tu vas mesurer cela?
    Bonjour janlouk,

    Il y a beaucoup à dire sur les mesures, compteurs et les "baseline" ! Il y a une multitude de compteurs à surveiller et à corréler, etc. Cela peut faire l'objet d'un livre. Et à propos de livre, je te conseille, si tu ne l'as pas déjà, de lire l'excellent livre de Rudi Bruchez.
    Optimiser SQL Server - Dimensionnement, supervision, performances du moteur et du code SQL
    https://www.amazon.fr/Optimiser-SQL-.../dp/2100518631
    Rudi Bruchez consacre plusieurs chapitres aux compteurs essentiels, compteurs tempdb, etc..

    PS : J'aurais souhaité que Rudi Bruchez publie une nouvelle édition de ce livre intégrant les nouveautés et les spécificités des toutes dernières versions de SQL Server. Ceci dit, le livre , ci-dessus mentionné de Bruchez, est vraiment remarquable et reste toujours d'actualité.

    A+
    "Une idée mal écrite est une idée fausse !"
    http://hamid-mira.blogspot.com

  12. #12
    Membre éprouvé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2003
    Messages
    605
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2003
    Messages : 605
    Points : 1 289
    Points
    1 289
    Billets dans le blog
    5

    Par défaut

    Merci beaucoup mikedavem pour ton témoignage et tes retours d'expériences quant à l'utilisation de ce TF 1118.
    Et effectivement, tu raison de rappeler qu'il y a toujours un prix à payer.. et que SQL Server 2016 permet, le cas échéant, même si, semble t-il, ce scénario reste rare, de revenir aux extensions mixtes.

    A+
    "Une idée mal écrite est une idée fausse !"
    http://hamid-mira.blogspot.com

  13. #13
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    août 2005
    Messages
    5 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : août 2005
    Messages : 5 001
    Points : 11 523
    Points
    11 523

    Par défaut

    Hello hmira,

    Juste un exemple concret pour illustrer mon propos.

    Un de mes derniers clients en date chez qui j'avais conseillé de mettre les trace flags 1117/1118 car beaucoup d'objets temporaires utilisés par son application et un peu de contention au niveau tempdb (PAGELATCH_xxx).

    Nombre de tables pouvant être impactées: 1325
    Nombre d'index pouvant être impactés: 2478

    Taille de la base avant mise en place du traceflag: 1.18TB

    J'ai pris un relevé il y a peu près 2 semaines (soit globalement un an après) pour une toute autre raison et nous en sommes à 1.29TB
    On avait fait l'étude de l'augmentation moyenne de la base de données par mois pendant l'audit (avant le traceflag) et on en avait déduit un taux de croissance à 7GB/mois. Entre temps il y a eu de nombreuses reconstructions d'index (je dirai une bonne moitié d'entre eux .. pas forcément simple d'avoir l'information de façon certaine). Si on regarde ce que ca donne depuis un an : 1.29TB - 1.18TB / 12 = 9.3GB/moins. Même si le calcul est peu grossier, je pense pouvoir dire que l'ajout du TF1118 est plutôt noyé dans la masse d'ajout des données par mois et ainsi que les modifications de schémas (quelques ajouts de colonnes) + ajout d'index depuis un an ...

    Comme dit de manière générale je n'ai pas vu de hausse spécatulaire chez d'autres clients (ou je n'ai jamais eu de clients qui m'ont appelé pour me dire qu'ils avaient vu leur taille de base de données grossir de manière significative après activation du TF ... )

    ++

  14. #14
    Membre éprouvé

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2003
    Messages
    605
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2003
    Messages : 605
    Points : 1 289
    Points
    1 289
    Billets dans le blog
    5

    Par défaut

    Merci beaucoup mikedavem pour ce témoignage très concret, basé sur un cas réel significatif, puisqu’établi sur une durée d’un an.
    Cela nous conforte dans l’idée que d’une manière générale, le TF 1118 peut être bénéfique pour les performances, même si, et on ne le répétera jamais assez, il faut toujours faire des mesures et comparer, voire même recueillir le ressenti des utilisateurs finaux des applications après de tels changements.

    Merci,

    A+
    "Une idée mal écrite est une idée fausse !"
    http://hamid-mira.blogspot.com

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 1
    Dernier message: 16/07/2009, 10h38
  2. Réponses: 0
    Dernier message: 16/07/2009, 08h15
  3. VirtualBox, un effet sur la taille des fichiers?
    Par zaboug dans le forum VirtualBox
    Réponses: 6
    Dernier message: 27/05/2009, 13h15
  4. Problème de test sur la taille des fichiers
    Par gregal dans le forum Fichiers
    Réponses: 7
    Dernier message: 12/12/2006, 21h57
  5. Probleme sur le Fields des fichiers Xmlgram
    Par Sandrine75 dans le forum XMLRAD
    Réponses: 4
    Dernier message: 20/03/2003, 18h09

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo