Test des performances du serveur multithread 1s. Test de charge standard. Que signifient les résultats des tests

Les résultats du test de charge TPC-1 performance 1C selon Gilev pour une configuration avec une base de données de fichiers :

Les performances du serveur ne sont pas mesurées par la charge et les files d'attente vers le processeur, mais par la capacité à effectuer un certain nombre d'opérations par unité de temps.
La concurrence pour des ressources telles que le processeur réduit la vitesse des opérations lorsque le temps de réponse est déterminé par :

• moment de l'opération
• temps d'attente du matériel
• temps d'attente logiques comme les serrures

Dans ce cas, la caractéristique clé est la rapidité de l'opération.

Noter. Pour un processeur, la caractéristique la plus importante est la fréquence du processeur et non la charge de travail. Vous trouverez ci-dessous une capture d'écran des résultats des tests (pour agrandir l'image, cliquez dessus).

La rapidité du système et la planification des ressources informatiques nécessaires à sa mise en œuvre est une opération obligatoire pour toute implémentation ou modification d'un système informatique existant.

La plupart des méthodes d'évaluation des performances existantes sont basées sur l'un ou l'autre type de test.

Il existe deux principaux types de tests : composants et intégraux.

Avec les tests de composants, les composants individuels de la solution sont testés, allant des performances des processeurs ou des sous-systèmes de stockage d'informations au test des performances du serveur dans son ensemble, mais sans la charge utile sous la forme d'une application métier particulière.

L'approche intégrale se caractérise par une évaluation des performances de la solution dans son ensemble, tant ses parties logicielles que matérielles. Dans ce cas, une application métier qui sera utilisée dans la solution finale et certaines applications modèles qui émulent certains processus métier et charges de travail standard peuvent être utilisées.

Dans notre test, une telle approche est utilisée.

Nous avons obtenu un indice de performance (vitesse) en conséquence. C'est le résultat de la plateforme dans son ensemble sur notre matériel. Dans le cas de la version client-serveur, c'est le résultat d'une chaîne complexe de requêtes passant par différentes sections. Vous obtenez le résultat réel global, qui est déterminé par le goulot d'étranglement du système. Les paramètres du SGBD et les paramètres du système d'exploitation et du matériel affectent le résultat global des performances du système.

Le test évalue la quantité de travail par unité de temps dans un thread et convient pour évaluer la vitesse des charges de travail monothread, y compris la vitesse de rendu de l'interface, l'impact du coût de maintenance d'un environnement virtuel et, le cas échéant, rediffusion des documents, clôture du mois, paie, etc.

Version actuelle : 2.0.011. Historique des versions ici : versions.php

Vous pouvez le télécharger ici : http://infostart.ru/public/173394/ ou ici : perfomanceTest.cf

Le test permet de mesurer les performances de la liaison serveur 1c - serveur SGBD dans différentes versions en fonctionnement multi-thread. Le test dure 20 à 30 minutes.

N'exécutez pas le test sur le serveur sur lequel les utilisateurs travaillent actuellement, sinon ils seront tristes ! Le test donne une très grosse charge !

Les résultats du test peuvent être visualisés sous forme de rapport dans la configuration.

Test de charge TPC-1C Gilev

Il est également possible de partager les résultats avec d'autres personnes ayant terminé le test à l'aide du traitement Partager les résultats. Après l'échange, il sera possible de comparer vos résultats avec les résultats d'autres personnes.

Des instructions plus détaillées, ainsi qu'une discussion sur le test, sont disponibles sur http://infostart.ru/public/173394/.

Il y a 751 résultats dans la base de données, dernière mise à jour le 2018-06-15 06:33:26. Les résultats peuvent être consultés en téléchargeant le test et en exécutant l'échange de résultats, ou (sous une forme simplifiée) ici : résultats.php

Statistiques

Résultats de la version 1.x : index_old.php

La création de graphiques utilise c3js et d3js (c3js en dépend).

Mettez de l'ordre dans votre travail en utilisant la configuration 1C "IT Department Management 8"

ATTENTION! Ctrl-F5 ou ctrl-r

2000 Humain.

Contexte

Une opération obligatoire pour toute implémentation ou modification d'un système d'information existant est d'évaluer la rapidité requise du système et de prévoir les ressources informatiques nécessaires à sa mise en œuvre. A l'heure actuelle, il n'existe pas de solution exacte à ce problème sous une forme générale, et si, malgré
sa complexité et son coût, un tel algorithme sera proposé par certains fabricants, alors même de petits changements dans le matériel, la version du logiciel, la configuration du système, ou le nombre ou le comportement standard des utilisateurs conduiront à des erreurs importantes.
Cependant, il existe de nombreuses façons d'évaluer la configuration logicielle et matérielle requise pour obtenir les performances souhaitées. Toutes ces méthodes peuvent être utilisées dans le processus de sélection, mais le consommateur doit comprendre leur portée et leurs limites.

La plupart des méthodes d'évaluation des performances existantes sont basées sur
ou tout autre type de test.

Il existe deux principaux types de tests :
composante et intégrale.

Les tests de composants sont effectués
test des composants individuels de la solution, en commençant par les performances
processeurs ou sous-systèmes de stockage avant de tester
performances du serveur dans son ensemble, mais sans la charge utile sous la forme de l'un ou l'autre
Applications commerciales.

Tests de résistance

L'approche intégrale se caractérise par l'évaluation
performance de la solution dans son ensemble, à la fois ses parties logicielles et matérielles.
Dans ce cas, il peut être utilisé comme une application métier qui sera utilisée
dans la solution finale, ainsi que quelques applications modèles qui émulent
certains processus métier et charges de travail standard.

Essais PTC et autres tests universels permettent de choisir les plateformes les plus prometteuses et de comparer les offres de différents constructeurs, mais ce ne sont que des informations de référence qui ne tiennent pas compte des spécificités de votre activité. Des tests spécialisés vous permettent de sélectionner plus précisément un modèle de serveur spécifique et sa configuration. Cependant, les décisions les plus éclairées ne sont prises que sur la base des résultats des tests de charge. Eux seuls vous permettent de configurer de manière optimale les
plate-forme de serveur et ajustez-la pour des performances maximales.

Que s'est il passé PTC-1C-GILV

Il s'agit d'une série de tests indépendants conçus pour évaluer les performances de la plate-forme 1C:Enterprise 8.1 sur votre ou vos ordinateurs.

Bien sûr, un test "indépendant" signifie qu'il n'est pas sponsorisé par 1C.

Le test est actuellement disponible PTC-Débit A-local/ PTC-1C-GILV-A" (dernière mise à jour août 2008 version 1.0.3)

idée de test PTC-Débit A-local/ PTC-1C-GILV-A

Vous téléchargez le fichier de téléchargement de configuration (~400 Ko) à partir de ce site et le téléchargez sur votre site. Si vous déployez la configuration dans les options de fichier, le test testera dans une large mesure le lien "CPU de votre ordinateur - Disque dur où se trouve la base".

Si vous étendez la configuration dans une variante client-serveur, le CPU du serveur d'application - le CPU du serveur du subd - HDD - du serveur du subd sera principalement soumis à la charge.

Le test écrit intensivement 5 000 documents. Il n'y a pas de sens profond dans la logique métier du code, c'est simplement la performance du document X choisi conditionnellement comme standard qui est évaluée.

La principale beauté du test est que vous n'avez pas besoin de connaître les détails techniques. Le test est auto-exécutable et donne un score. De plus, vous n'êtes pas obligé de dire le résultat à qui non plus 🙂

Vous pouvez comparer les performances de plusieurs serveurs ou d'un serveur avec différentes caractéristiques de sous-système de disque.

En effectuant un test depuis le serveur d'applications et depuis le client sur le réseau, vous pouvez comprendre l'impact du réseau du client sur le serveur.

Comment lancer un test

Faire un test est très simple. Faut appuyer sur le bouton

et attendez que l'indicateur de test (à droite du bouton) atteigne 100 %.

Le test dure généralement environ 8 minutes.

Que signifient les résultats des tests

Le résultat du test est présenté comme le "taux d'écriture" des données de test. L'erreur du test est de 2 unités. Pour une évaluation précise, vous pouvez répéter le test 3 fois.

Une fois que l'indicateur de test atteint 100 %, vous verrez des graphiques comme celui-ci :

Ci-dessous les graphiques sont quelques tests similaires précédents.

La couleur du graphique indique la qualité actuelle de la performance "totale" pour le travail sans tenir compte des verrous.

La couleur verte du graphique, associée à certains indicateurs à droite, choisis conditionnellement comme repères, nous permet de faire une évaluation généralisée multiplateforme des "bonnes" performances 🙂

Comment apprécier les résultats des tests

En conséquence, vous avez reçu un certain indice de performance (considérez la vitesse). Peu importe que le résultat soit bon ou mauvais, c'est le résultat de la PLATEFORME qui s'exécute sur votre matériel. Dans le cas de la version client-serveur, c'est le résultat d'une chaîne complexe de requêtes passant par différentes sections. Vous obtenez le résultat réel global, qui est déterminé par le POINT INFÉRIEUR du système. LE LIEU DES BOUTEILLES EST TOUJOURS !

En d'autres termes, les paramètres du SGBD, les paramètres du système d'exploitation et l'équipement affectent le résultat global de l'équipe 🙂

Quel serveur est le meilleur

Ce test, effectué sur un serveur spécifique, donne un résultat sur une combinaison de paramètres matériels, système d'exploitation, subd, etc. Cependant, un score élevé sur un matériel serveur particulier signifie que, dans des conditions normales, le même résultat sera obtenu sur un matériel serveur identique. Ce test est une aide gratuite dans la capacité de comparer l'installation de 1C:Enterprise sous Windows et Linux, trois SGBD différents supportés par la plateforme 1C:Enterprise 8.1.

Sécurité des essais

Le test est absolument sûr. Il n'entraîne pas de "chute" du serveur (il n'y a pas d'algorithme de "stress") et ne nécessite pas de mesures préalables même sur un serveur "combat". Les données confidentielles ne sont pas non plus enregistrées dans les résultats des tests. Collecte des informations sur les paramètres du CPU, de la RAM, du disque dur. Les numéros de série des appareils ne sont pas collectés. Tout cela peut être facilement vérifié - le code de test est ouvert à 100 %. Aucun transfert d'informations à votre insu n'est possible.

Comment publier les résultats des tests

Si vous souhaitez aider à développer le test, vous pouvez exécuter un certain nombre de tests sur vos serveurs. Laissez ensuite la liste générale des tests effectués uniquement ceux que vous souhaitez publier et envoyez le dt-upload avec les résultats.

Les données seront vérifiées manuellement (qu'elles ne soient pas erronées), le destinataire des tests est ajouté à la colonne "auteur" des tests et ajouté à l'upload, disponible en téléchargement pour tout le monde.

Classification PTC-Débit A-local/ PTC-1C-GILV-A

Le test appartient à la section des tests multiplateformes intégraux universels. De plus, il s'applique aux variantes fichier et client-serveur du fonctionnement 1C:Enterprise. Le test fonctionne pour tous les SGBD pris en charge par 1C.

L'universalité vous permet d'effectuer une évaluation généralisée des performances sans être lié à une configuration de plate-forme typique spécifique.

D'autre part, cela signifie que pour des calculs précis d'un projet personnalisé, le test vous permet de faire une évaluation préliminaire avant des tests de charge spécialisés (par exemple, en utilisant 1C : Testcenter).

Noter. Tester la modification " UNE" signifie "gestion automatique des serrures". Après la sortie des versions officielles des solutions standards de 1C, il est prévu de modifier le test pour fonctionner en mode "serrures gérées" et de le désigner par la lettre " M".

Télécharger l'essai

Ce test n'est pas commercial et est disponible en téléchargement gratuit.

Résultats de test

Top - 3 meilleures installations client-serveur 1C sur MS SQL Server. Vous aussi, vous pouvez entrer dans ce tableau. Vous pouvez voir les résultats plus en détail en téléchargeant le test.

Détails techniques

Que se passe-t-il lors du test dans le "un" cycle de l'opération ?

Un exemple d'exécution de commandes SQL peut être trouvé dans le fichier joint.

Comment mesurer la charge de travail du fer

Il convient de noter que le test lui-même effectue déjà partiellement la mesure. Pour une image plus détaillée, je recommande d'utiliser l'utilitaire Process Explorer de Mark Rusinovich.

La figure montre un exemple de mesure pour la version du fichier.

Coordonnées pour PTC-1C-GILV

http://gilev.ru/1c/ tpc

résultats des tests, suggestions de développement

et envoyez vos commentaires par e-mail : [courriel protégé]

Accéder aux autres matériaux du site

TurboConf 5 - étendre les capacités du configurateur 1C

ATTENTION!

Si vous avez perdu la zone de saisie du message, cliquez sur Ctrl-F5 ou ctrl-r ou le bouton Actualiser du navigateur.

Le sujet n'a pas été mis à jour depuis longtemps et a été marqué comme archivé. L'ajout de messages n'est pas possible.
Mais vous pouvez créer un nouveau fil et vous obtiendrez certainement une réponse !
Chaque heure, il y a plus de 2000 Humain.

Photo par Alena Tulyakova, IA Clerk.Ru

L'article indique les principales erreurs commises par les administrateurs novices 1C et montre comment les résoudre à l'aide de l'exemple du test Gilev.

Le but principal de la rédaction de l'article n'est pas de répéter les nuances évidentes aux administrateurs (et programmeurs) qui n'ont pas encore acquis d'expérience avec 1C.

Un objectif secondaire, si j'ai des lacunes, Infostart me le signalera au plus vite.

Le test de V. Gilev est déjà devenu une sorte de norme "de facto". L'auteur sur son site Web a donné des recommandations tout à fait compréhensibles, mais je vais simplement donner quelques résultats et commenter les erreurs les plus probables. Naturellement, les résultats des tests sur votre équipement peuvent différer, ce n'est qu'une ligne directrice, ce qui devrait être et ce que vous pouvez rechercher. Je tiens à noter tout de suite que les modifications doivent être apportées étape par étape et, après chaque étape, vérifiez le résultat obtenu.

Il existe des articles similaires sur Infostart, dans les sections concernées, je mettrai des liens vers eux (si quelque chose me manque, dites-le-moi dans les commentaires, je l'ajouterai). Donc, supposons que vous ralentissiez 1C. Comment diagnostiquer le problème, et comment comprendre qui est à blâmer, l'administrateur ou le programmeur ?

Donnée initiale:

Ordinateur testé, cobaye principal : HP DL180G6, 2*Xeon 5650, 32 Go, Intel 362i, Win 2008 r2. À titre de comparaison, des résultats comparables dans un test monothread sont affichés par le Core i3-2100. L'équipement a été spécialement pris pas le plus récent, sur l'équipement moderne, les résultats sont nettement meilleurs.

Pour tester les serveurs 1C et SQL distants, serveur SQL : IBM System 3650 x4, 2*Xeon E5-2630, 32 Go, Intel 350, Win 2008 r2.

Pour tester le réseau 10 Gbit, des adaptateurs Intel 520-DA2 ont été utilisés.

Version du fichier. (la base se trouve sur le serveur dans le dossier partagé, les clients sont connectés en réseau, le protocole CIFS/SMB). Algorithme pas à pas :

0. Ajoutez la base de données de test Gilev au serveur de fichiers dans le même dossier que les bases de données principales. Nous nous connectons à partir de l'ordinateur client, exécutons le test. On se souvient du résultat.

On suppose que même pour les anciens ordinateurs de 10 ans (Pentium sur socket 775), le temps entre le clic sur le raccourci 1C:Enterprise et l'apparition de la fenêtre de la base de données doit être inférieur à une minute. (Celeron = travail lent).

Si votre ordinateur est pire qu'un pentium socket 775 avec 1 Go de RAM, alors je sympathise avec vous, et il vous sera difficile de réaliser un travail confortable sur 1C 8.2 dans la version fichier. Envisagez une mise à niveau (attendue depuis longtemps) ou le passage à un serveur de terminal (ou Web, dans le cas des clients légers et des formulaires gérés).

Si l'ordinateur n'est pas pire, vous pouvez expulser l'administrateur. Au minimum, vérifiez le fonctionnement du réseau, de l'antivirus et du pilote de protection HASP.

Si le test de Gilev à ce stade a montré 30 "perroquets" et plus, mais que la base de travail 1C fonctionne toujours lentement - les questions sont déjà pour le programmeur.

1. À titre indicatif, dans quelle mesure un ordinateur client peut "s'extraire", nous vérifions le fonctionnement de cet ordinateur uniquement, sans réseau. Nous mettons la base de test sur l'ordinateur local (sur un disque très rapide). Si l'ordinateur client n'a pas de SSD normal, un disque virtuel est créé. Jusqu'à présent, le plus simple et le plus gratuit est l'entreprise Ramdisk.

Pour tester la version 8.2, 256 Mo de ramdisk suffisent, et ! La chose la plus importante. Après avoir redémarré l'ordinateur avec un disque virtuel en état de marche, il devrait disposer de 100 à 200 Mo d'espace libre. En conséquence, sans disque virtuel, pour un fonctionnement normal de la mémoire libre, il devrait y avoir 300 à 400 Mo.

Pour tester la version 8.3, un disque RAM de 256 Mo suffit, mais il faut plus de RAM libre.

Lors des tests, vous devez examiner la charge du processeur. Dans un cas proche de l'idéal (ramdisk), le fichier local 1c charge 1 cœur de processeur pendant le fonctionnement. Par conséquent, si pendant les tests, le cœur de votre processeur n'est pas complètement chargé, recherchez les faiblesses. Un peu émotive, mais globalement correcte, l'influence du processeur sur le fonctionnement de 1C est décrite. Juste pour référence, même sur les Core i3 modernes avec une fréquence élevée, les nombres 70-80 sont bien réels.

Les erreurs les plus courantes à ce stade.

• Antivirus mal configuré. Il existe de nombreux antivirus, les paramètres de chacun sont différents, je peux seulement dire qu'avec une configuration appropriée, ni le Web ni Kaspersky 1C n'interfèrent. Avec les paramètres "par défaut", environ 3 à 5 perroquets (10 à 15 %) peuvent être enlevés.
• mode Performance. Pour une raison quelconque, peu de gens y prêtent attention, et l'effet est le plus significatif. Si vous avez besoin de vitesse, vous devez le faire, à la fois sur les ordinateurs clients et serveurs. (Gilev a une bonne description. La seule mise en garde est que sur certaines cartes mères, si Intel SpeedStep est désactivé, alors TurboBoost ne peut pas être activé).

Vous pouvez (et de préférence) activer le mode performance à deux endroits :

• via le BIOS. Désactivez les modes C1, C1E, Intel C-state (C2, C3, C4). Dans différents bios, ils sont appelés différemment, mais la signification est la même. Cherchez longtemps, un redémarrage est nécessaire, mais si vous l'avez fait une fois, vous pouvez oublier. Si tout est fait correctement dans le BIOS, la vitesse sera ajoutée. Sur certaines cartes mères, les paramètres du BIOS peuvent être définis de manière à ce que le mode de performance Windows ne joue aucun rôle. (Exemples de configuration du BIOS par Gilev). Ces paramètres concernent principalement les processeurs de serveur ou le BIOS "avancé", si vous ne l'avez pas trouvé dans votre système et que vous n'avez pas de Xeon - ça va.

• Panneau de contrôle - Alimentation - Haute performance. Moins - si l'ordinateur n'a pas été entretenu depuis longtemps, il bourdonnera plus fort avec un ventilateur, il chauffera plus et consommera plus d'énergie. C'est le prix de la performance.

Ce sont les paramètres par défaut. BIOS C-state activé, mode de puissance équilibré
BIOS C-state activé, mode hautes performances Pour Pentium et Core, vous pouvez vous arrêter là, vous pouvez toujours faire sortir des "perroquets" de Xeon
Dans le BIOS, les états C sont désactivés, mode haute performance. Si vous n'utilisez pas Turbo boost - voici à quoi cela devrait ressembler serveur optimisé pour la performance

Et maintenant les chiffres. Laissez-moi vous rappeler : Intel Xeon 5650, disque virtuel. Dans le premier cas, le test indique 23,26, dans le second - 49,5. La différence est presque double. Les chiffres peuvent varier, mais le ratio reste à peu près le même pour l'Intel Core.

Chers administrateurs, vous pouvez gronder 1C comme bon vous semble, mais si les utilisateurs finaux ont besoin de vitesse, vous devez activer le mode haute performance.

c) Turbo Boost. Vous devez d'abord comprendre si votre processeur prend en charge cette fonction, par exemple. Si c'est le cas, vous pouvez toujours obtenir en toute légalité des performances. (Je ne veux pas aborder les problèmes d'overclocking, en particulier les serveurs, faites-le à vos risques et périls. Mais je suis d'accord que l'augmentation de la vitesse du bus de 133 à 166 donne une augmentation très notable de la vitesse et de la dissipation thermique)

Comment activer le turbo boost est écrit, par exemple,. Mais! Pour 1C, il y a quelques nuances (pas les plus évidentes). La difficulté est que l'effet maximal du turbo boost se manifeste lorsque le C-state est activé. Et il s'avère quelque chose comme cette image:

Veuillez noter que le multiplicateur est le maximum, la vitesse du cœur est la plus belle, les performances sont élevées. Mais que se passera-t-il à la suite de 1 s ?

Et au final, il s'avère que selon les tests de performances du processeur, la variante avec un multiplicateur de 23 est en avance, selon les tests de Gilev dans la version du fichier - les performances avec un multiplicateur de 22 et 23 sont les mêmes, mais dans le client -version serveur - la variante avec un multiplicateur de 23 horreur horreur horreur (même si C -state réglé au niveau 7, il est toujours plus lent qu'avec C-state désactivé). Par conséquent, la recommandation, vérifiez les deux options par vous-même et choisissez la meilleure parmi elles. En tout cas, la différence entre 49,5 et 53 perroquets est assez importante, d'autant plus que c'est sans trop d'effort.

Conclusion - le turbo boost doit être inclus. Permettez-moi de vous rappeler qu'il ne suffit pas d'activer l'élément Turbo boost dans le BIOS, vous devez également regarder d'autres paramètres (BIOS : QPI L0s, L1 - désactiver, demander le nettoyage - désactiver, Intel SpeedStep - activer, Turbo boost - Activer Panneau de configuration - Alimentation - Haute performance) . Et je m'arrêterais toujours (même pour la version du fichier) à l'option où c-state est désactivé, même si le multiplicateur est inférieur. Obtenez quelque chose comme ça...

Un point plutôt controversé est la fréquence de la mémoire. Par exemple, la fréquence mémoire est montrée comme très influente. Mes tests n'ont pas révélé une telle dépendance. Je ne comparerai pas DDR 2/3/4, je montrerai les résultats du changement de fréquence dans la même ligne. La mémoire est la même, mais dans le BIOS, nous forçons des fréquences plus basses.

Et les résultats des tests. 1C 8.2.19.83, pour la version de fichier disque virtuel local, pour client-serveur 1C et SQL sur un ordinateur, mémoire partagée. Le turbo boost est désactivé dans les deux options. 8.3 montre des résultats comparables.

La différence est dans l'erreur de mesure. J'ai spécifiquement extrait les captures d'écran CPU-Z pour montrer que d'autres paramètres changent avec le changement de fréquence, la même latence CAS et le même délai RAS vers CAS, qui nivelle le changement de fréquence. La différence se fera lorsque les modules de mémoire changeront physiquement, du plus lent au plus rapide, mais même là, les chiffres ne sont pas très significatifs.

2. Lorsque nous avons déterminé le processeur et la mémoire de l'ordinateur client, nous passons au prochain endroit très important - le réseau. De nombreux volumes de livres ont été écrits sur le réglage du réseau, il y a des articles sur Infostart (et autres), ici je ne me concentrerai pas sur ce sujet. Avant de commencer à tester 1C, assurez-vous que iperf entre deux ordinateurs montre toute la bande (pour les cartes 1 Gbit - enfin, au moins 850 Mbit, mais mieux 950-980), que les conseils de Gilev sont suivis. Ensuite - le test de travail le plus simple sera, curieusement, de copier un gros fichier (5-10 gigaoctets) sur le réseau. Un signe indirect de fonctionnement normal sur un réseau de 1 Gbps sera une vitesse de copie moyenne de 100 Mb / s, bon travail - 120 Mb / s. Je tiens à attirer votre attention sur le fait que la charge processeur peut aussi être un point faible (y compris). Le protocole SMB sous Linux est plutôt mal parallélisé et, pendant son fonctionnement, il peut assez facilement "manger" un cœur de processeur et ne plus le consommer.

Et plus loin. Avec les paramètres par défaut, le client Windows fonctionne mieux avec le serveur Windows (ou même le poste de travail Windows) et le protocole SMB / CIFS, le client Linux (debian, ubuntu n'a pas regardé le reste) fonctionne mieux avec Linux et NFS (il fonctionne aussi avec SMB, mais sur les perroquets NFS ci-dessus). Le fait que lors de la copie linéaire d'un serveur win-linux vers nfs soit copié plus rapidement dans un flux, ne veut rien dire. Le réglage de Debian pour 1C est un sujet pour un article séparé, je ne suis pas encore prêt pour cela, même si je peux dire que dans la version du fichier, j'ai même obtenu des performances un peu meilleures que la version Win sur le même équipement, mais avec postgres avec utilisateurs de plus de 50 ans, j'ai toujours tout très mauvais.

La chose la plus importante est ce que les administrateurs "brûlés" savent, mais les débutants n'en tiennent pas compte. Il existe de nombreuses façons de définir le chemin d'accès à la base de données 1c. Vous pouvez créer un partage de serveur, vous pouvez 192.168.0.1share, vous pouvez utiliser net z : 192.168.0.1share (et dans certains cas, cette méthode fonctionnera également, mais pas toujours), puis spécifier le lecteur Z. Il semble que tous ces chemins pointent à la même chose au même endroit, mais pour 1C il n'y a qu'un seul moyen qui donne une performance assez stable. Voici donc ce que vous devez faire correctement :

Sur la ligne de commande (ou dans les politiques, ou tout ce qui vous convient) - utilisez net DriveLetter: servershare. Exemple : net use m:serverbases. J'insiste spécifiquement, PAS sur l'adresse IP, mais sur le nom du serveur. Si le serveur n'est pas visible par son nom, ajoutez-le au DNS sur le serveur ou localement au fichier hosts. Mais l'appel doit être nominatif. En conséquence, sur le chemin de la base de données, accédez à ce disque (voir l'image).

Et maintenant, je vais montrer en chiffres pourquoi un tel conseil. Données initiales : cartes Intel X520-DA2, Intel 362, Intel 350, Realtek 8169. OS Win 2008 R2, Win 7, Debian 8. Derniers pilotes, mises à jour appliquées. Avant de tester, je me suis assuré qu'Iperf donne toute la bande passante (sauf pour les cartes 10 Gbit, il s'est avéré n'extraire que 7,2 Gbit, plus tard je verrai pourquoi, le serveur de test n'est pas encore configuré correctement). Les disques sont différents, mais partout est un SSD (spécialement inséré un seul disque pour les tests, rien d'autre n'est chargé) ou un raid à partir d'un SSD. La vitesse de 100 Mbit a été obtenue en limitant les paramètres de l'adaptateur Intel 362. Il n'y avait pas de différence entre 1 Gbit cuivre Intel 350 et 1 Gbit optique Intel X520-DA2 (obtenu en limitant la vitesse de l'adaptateur). Performances maximales, le turbo boost est désactivé (juste pour la comparabilité des résultats, le turbo boost ajoute un peu moins de 10% pour les bons résultats, pour les mauvais résultats, cela peut ne pas affecter du tout). Versions 1C 8.2.19.86, 8.3.6.2076. Je ne donne pas tous les chiffres, mais seulement les plus intéressants, pour qu'il y ait de quoi comparer.

Conclusions (à partir du tableau et de l'expérience personnelle. S'applique uniquement à la version fichier):

• Sur le réseau, vous pouvez obtenir des nombres tout à fait normaux pour le travail si ce réseau est normalement configuré et que le chemin est correctement écrit en 1C. Même les premiers Core i3 peuvent bien donner plus de 40 perroquets, ce qui est plutôt bien, et ce ne sont pas seulement des perroquets, dans le vrai travail, la différence est également perceptible. Mais! la limitation lorsque l'on travaille avec plusieurs (plus de 10) utilisateurs ne sera plus le réseau, ici 1 Gbit est encore suffisant, mais bloquant lors d'un travail multi-utilisateur (Gilev).
• la plate-forme 1C 8.3 est beaucoup plus exigeante pour une configuration réseau compétente. Paramètres de base - voir Gilev, mais gardez à l'esprit que tout peut influencer. J'ai vu une accélération du fait qu'ils ont désinstallé (et pas seulement désactivé) l'antivirus, de la suppression de protocoles comme FCoE, du changement de pilotes vers une version plus ancienne, mais certifiée Microsoft (en particulier pour les cartes bon marché comme asus et longs), de la suppression du deuxième carte réseau du serveur . Beaucoup d'options, configurez le réseau de manière réfléchie. Il peut bien y avoir une situation où la plate-forme 8.2 donne des nombres acceptables, et 8.3 - deux fois ou même plus moins. Essayez de jouer avec les versions 8.3 de la plate-forme, parfois vous obtenez un très gros effet.
• 1C 8.3.6.2076 (peut-être plus tard, je n'ai pas encore cherché la version exacte) sur le réseau est toujours plus facile à configurer que 8.3.7.2008. À partir du 8.3.7.2008, pour obtenir un fonctionnement normal du réseau (chez des perroquets comparables), il ne s'est avéré que quelques fois, je ne pouvais pas le répéter pour un cas plus général. Je n'ai pas compris grand-chose, mais à en juger par les footclothes de Process Explorer, l'enregistrement n'y va pas comme il le fait dans 8.3.6.
• Malgré le fait que lorsque l'on travaille sur un réseau 100Mbps, son planning de charge est faible (on peut dire que le réseau est gratuit), la vitesse de travail est encore bien inférieure à celle sur 1 Gbps. La raison en est la latence du réseau.
• Ceteris paribus (réseau qui fonctionne bien) pour 1C 8.2, la connexion Intel-Realtek est 10 % plus lente qu'Intel-Intel. Mais realtek-realtek peut généralement donner un affaissement net à l'improviste. Par conséquent, s'il y a de l'argent, il vaut mieux garder les cartes réseau Intel partout, s'il n'y a pas d'argent, alors mettez Intel uniquement sur le serveur (votre KO). Oui, et il y a beaucoup plus d'instructions pour régler les cartes réseau Intel.
• Les paramètres antivirus par défaut (par exemple, la version drweb 10) éliminent environ 8 à 10 % des perroquets. Si vous le configurez correctement (permettez au processus 1cv8 de tout faire, même s'il n'est pas sûr) - la vitesse est la même que sans antivirus.
• Ne lisez PAS les gourous de Linux. Un serveur avec samba est génial et gratuit, mais si vous mettez Win XP ou Win7 sur le serveur (ou mieux encore - système d'exploitation du serveur), alors dans la version de fichier 1c fonctionnera plus rapidement. Oui, samba et la pile de protocoles et les paramètres réseau et bien plus encore dans debian / ubuntu sont bien réglés, mais cela est recommandé aux spécialistes. Cela n'a aucun sens d'installer Linux avec les paramètres par défaut et de dire ensuite qu'il est lent.
• C'est une bonne idée de tester les disques connectés via net use avec fio . Au moins, il sera clair s'il s'agit de problèmes avec la plate-forme 1C ou avec le réseau / disque.
• Pour une variante mono-utilisateur, je ne peux pas penser à des tests (ou à une situation) où la différence entre 1 Go et 10 Go serait visible. Le seul endroit où 10 Gbps pour la version de fichier a donné de meilleurs résultats était la connexion de disques via iSCSI, mais c'est un sujet pour un article séparé. Pourtant, je pense que les cartes 1 Gbit suffisent pour la version fichier.
• Pourquoi, avec un réseau de 100 Mbit, 8.3 fonctionne sensiblement plus rapidement que 8.2 - je ne comprends pas, mais le fait a eu lieu. Tous les autres équipements, tous les autres paramètres sont exactement les mêmes, juste dans un cas, 8.2 est testé et dans l'autre - 8.3.
• Non réglé NFS win - win ou win-lin donne 6 perroquets, ne l'a pas inclus dans le tableau. Après réglage, j'ai reçu 25, mais il est instable (la montée en puissance des mesures est supérieure à 2 unités). Jusqu'à présent, je ne peux pas donner de recommandations sur l'utilisation de Windows et du protocole NFS.

serveur Principal. (la base est sur le serveur, les clients sont connectés sur un réseau, le protocole RDP). Algorithme pas à pas :

• Nous ajoutons la base de données de test Gilev au serveur dans le même dossier que les bases de données principales. Nous nous connectons à partir du même serveur et exécutons le test. On se souvient du résultat.
• De la même manière que dans la version fichier, nous configurons le processeur. Dans le cas d'un serveur terminal, le processeur joue généralement le rôle principal (il est entendu qu'il n'y a pas de faiblesses évidentes, comme un manque de mémoire ou une quantité énorme de logiciels inutiles).
• La mise en place de cartes réseau dans le cas d'un serveur de terminal n'a pratiquement aucune incidence sur le fonctionnement de 1s. Pour apporter un confort "spécial", si votre serveur délivre plus de 50 perroquets, vous pouvez jouer avec les nouvelles versions du protocole RDP, rien que pour le confort des utilisateurs, une réponse et un défilement plus rapides.
• Avec le travail actif d'un grand nombre d'utilisateurs (et ici, vous pouvez déjà essayer de connecter 30 personnes à une base, si vous essayez), il est très souhaitable d'installer un lecteur SSD. Pour une raison quelconque, on pense que le disque n'affecte pas particulièrement le fonctionnement de 1C, mais tous les tests sont effectués avec le cache du contrôleur activé pour l'écriture, ce qui est faux. La base de test est petite, elle tient dans le cache, d'où les chiffres élevés. Sur de vraies (grandes) bases de données, tout sera complètement différent, donc le cache est désactivé pour les tests.

• Le cache inclus du contrôleur RAID élimine toute la différence entre les disques, les chiffres sont les mêmes pour sat et sas. Tester avec une petite quantité de données est inutile et n'est pas un indicateur.
• Pour la plate-forme 8.2, la différence de performances entre les options SATA et SSD est plus que doublée. Ce n'est pas une faute de frappe. Si vous regardez le moniteur de performances lors du test sur les disques SATA. alors il est clairement visible "Temps de disque actif (en%)" 80-95. Oui, si vous activez le cache en écriture des disques eux-mêmes, la vitesse passera à 35, si vous activez le cache du contrôleur RAID - jusqu'à 49 (quels que soient les disques testés en ce moment). Mais ce sont des perroquets synthétiques du cache, dans un travail réel avec de grandes bases de données, il n'y aura jamais un taux d'accès au cache en écriture de 100 %.
• La vitesse des SSD même bon marché (j'ai testé sur Agility 3) est suffisante pour que la version du fichier fonctionne. La ressource d'écriture est une autre affaire, ici il faut regarder dans chaque cas précis, il est clair que l'Intel 3700 aura un ordre de grandeur supérieur, mais là le prix est correspondant. Et oui, je comprends que lors du test d'un lecteur SSD, je teste également le cache de ce lecteur dans une plus grande mesure, les vrais résultats seront moindres.
• La solution la plus correcte (de mon point de vue) serait d'allouer 2 disques SSD à un raid miroir pour la base de fichiers (ou plusieurs bases de fichiers), et de ne rien y mettre d'autre. Oui, avec un miroir, les SSD s'usent de la même manière, et c'est un inconvénient, mais au moins ils sont en quelque sorte assurés contre les erreurs dans l'électronique du contrôleur.
• Les principaux avantages des disques SSD pour la version fichier apparaîtront lorsqu'il y aura de nombreuses bases de données, et chacune avec plusieurs utilisateurs. S'il y a 1 à 2 bases et des utilisateurs de l'ordre de 10, les disques SAS suffiront. (mais dans tous les cas - regardez le chargement de ces disques, au moins via perfmon).
• Les principaux avantages d'un serveur de terminaux sont qu'il peut avoir des clients très faibles et que les paramètres réseau affectent beaucoup moins le serveur de terminaux (votre KO encore une fois).

Si le test Gilev montre de petits nombres et que vous avez à la fois un processeur avec une fréquence élevée et des disques rapides, alors ici l'administrateur doit prendre au moins perfmon et enregistrer tous les résultats quelque part, et regarder, observer, tirer des conclusions. Il n'y aura pas de conseil définitif.

Option client-serveur.

Les tests ont été effectués uniquement sur 8.2, tk. Sur la 8.3, tout dépend assez sérieusement de la version.

Pour les tests, j'ai choisi différentes options de serveur et réseaux entre eux pour montrer les principales tendances.

Il semble que j'ai envisagé toutes les options intéressantes, si vous êtes intéressé par autre chose - écrivez dans les commentaires, je vais essayer de le faire.

• SAS sur le stockage est plus lent que les SSD locaux, même si le stockage a de grandes tailles de cache. Les SSD et les systèmes locaux et de stockage pour le test Gilev fonctionnent à des vitesses comparables. Je ne connais aucun test multithread standard (pas seulement les enregistrements, mais tous les équipements) à l'exception de la charge 1C du MCC.
• Changer le serveur 1C de 5520 à 5650 a presque doublé les performances. Oui, les configurations de serveur ne correspondent pas complètement, mais cela montre une tendance (rien d'étonnant).
• L'augmentation de la fréquence sur le serveur SQL, bien sûr, donne un effet, mais pas le même que sur le serveur 1C, MS SQL Server est parfaitement capable (si vous le demandez) d'utiliser de la mémoire multicœur et libre.
• Changer le réseau entre 1C et SQL de 1 Gbps à 10 Gbps donne environ 10% de perroquets. Attendu plus.
• L'activation de la mémoire partagée donne toujours l'effet, mais pas 15%, comme décrit dans l'article. Assurez-vous de le faire, c'est rapide et facile. Si quelqu'un a donné une instance nommée au serveur SQL lors de l'installation, alors pour que 1C fonctionne, le nom du serveur doit être spécifié non pas par FQDN (tcp / ip fonctionnera), pas via localhost ou simplement ServerName, mais via ServerNameInstanceName, par exemple zz -testzztest. (Sinon, une erreur de SGBD se produira : Microsoft SQL Server Native Client 10.0 : Fournisseur de mémoire partagée : La bibliothèque de mémoire partagée utilisée pour se connecter à SQL Server 2000 est introuvable. HRESULT=80004005, HRESULT=80004005, HRESULT=80004005, SQLSrvr : SQLSTATE =08001, état=1, Gravité=10, natif=126, ligne=0).
• pour les utilisateurs de moins de 100, le seul point de séparation en deux serveurs distincts est une licence pour Win 2008 Std (et versions antérieures), qui ne prend en charge que 32 Go de RAM. Dans tous les autres cas, 1C et SQL doivent absolument être installés sur le même serveur et disposer de plus de mémoire (au moins 64 Go). Donner à MS SQL moins de 24-28 Go de RAM est une cupidité injustifiée (si vous pensez que vous avez assez de mémoire pour cela et que tout fonctionne bien, peut-être que la version du fichier 1C vous suffirait ?)
• À quel point un groupe de 1C et de SQL fonctionne-t-il pire dans une machine virtuelle fait l'objet d'un article séparé (indice - nettement pire). Même dans Hyper-V, les choses ne sont pas si claires...
• Le mode de performance équilibré est mauvais. Les résultats sont en bon accord avec la version du fichier.
• De nombreuses sources disent que le mode débogage (ragent.exe -debug) donne une forte baisse des performances. Eh bien, ça diminue, oui, mais je n'appellerais pas 2-3% un effet significatif.

Pour les rôles de serveur 1C, serveur SGBD MS SQL 2008 pour 50 utilisateurs.

Selon l'expert serveur, nous collectons du matériel :

Choisissez une plateforme : IBM x3650 M3
Choisissez un processeur : Intel Xeon E5506 - 1 pc.
Choisissez la RAM : 4 sticks de 4 Go
Choisissez un disque dur : 3 SAS 146 Go RAID5

Logiciel utilisé :

SE MS Windows 2008 x64
SGBD MS SQL 2008 x64
Serveur 1C 8.2 x64

Environnement de test : pour les tests de charge, la configuration 1C 8.2 : « Test de charge standard » a été utilisée.

Avancement des tests :

Sur le serveur local, une session client 1C a été lancée en mode agent et en mode test.
Dans la configuration de test, le nombre initial d'utilisateurs émulés standard 1C qui créent et suppriment des documents et des rapports a été défini sur 20. L'étape d'augmentation du nombre d'utilisateurs après les tests a été définie sur 20 utilisateurs.

Initialement (sans connexions utilisateurs), le SGBD occupe 569 Mo de RAM (2 bases de données sont créées : configuration 1C 8.2 : configuration SCP et test), la mémoire occupée par le système est de 2,56 Go.
Pendant les tests (jusqu'à 110 utilisateurs), jusqu'à 12 Go de mémoire sont alloués au SGBD, une session de test 1C prend 55 Mo (55 Mo x 200 = 11 Go). À titre de comparaison, une session utilisateur réelle (application client 1C) prend environ 300 à 500 Mo. La quantité de mémoire allouée à l'application client 1C est indiquée pour un utilisateur travaillant dans la configuration standard 1C : Commerce ou 1C : SCP. Le service serveur 1C (rphost) n'utilise pratiquement pas OP, car il ne fait que traduire les requêtes du côté client vers le SGBD (selon la norme, les ports TCP 1541 et TCP 475 sont utilisés pour le serveur de protection 1C).

L'utilisation du processeur était partagée entre le service serveur 1C (rphost) et le service SGBD (sqlservr). Avec une charge de 40 utilisateurs, rphost a pris 37 % de la puissance CPU, sqlservr a pris 30 %. Avec une charge de 60 utilisateurs, rphost a pris 47% du CPU, sqlservr a pris 29%.

Lors de la suppression des documents générés, le service sqlsrvr a accédé au sous-système de disque pour des écritures à des vitesses allant jusqu'à 6,5 Mo/s (environ 52 Mo/s).

La charge réseau entre le serveur 1C et le SGBD (sur les interfaces lookback locales) était de 10 Mb/s.
Le résultat du test émis par la configuration de test 1C :

Paramètres : Exécuter le test 000000006 du 24/05/2012 12:44:16 PM
Test de charge standard Version 2.0.4.11
Début des tests le 23.05.2012 12:36:39. Durée d'exécution : 57,1 minutes.
Conditions d'essai
"Serveur 1C : Entreprises : test
Nom de l'infobase : testcenter_82
Utilisateurs virtuels : TEST,»

Conclusion :

Vous devez assouplir la configuration du serveur car l'actuel est 100% redondant pour 50 utilisateurs.
Il est nécessaire d'effectuer des tests à l'aide d'un deuxième serveur pour exécuter des utilisateurs émulés et vérifier la charge du réseau, la charge attendue est de 10 Mb / s.
L'architecture 1C se compose de 4 blocs : serveur 1C, SGBD, serveur de protection 1C et client 1C. Dans ce test, toutes ces fonctions ont été exécutées sur le même serveur.

Avec une charge importante sur le serveur 1C, il existe les recommandations suivantes :

Séparez les rôles du serveur 1C, du serveur SGBD, du serveur de protection 1C et des applications clientes 1C (pour de meilleures performances, il est préférable d'exécuter les applications clientes 1C sur un serveur terminal).
Le serveur SGBD doit utiliser la structure suivante pour les systèmes de stockage : le système d'exploitation doit être situé sur RAID 1, les fichiers de données SGBD (.mdf, .ndf) sur un RAID 0 distinct, les fichiers journaux (.ldf) sur un RAID 0 distinct, les fichiers temporaires et le fichier d'échange sur un disque séparé.

Chaque spécialiste du support a de l'expérience dans la réception de plaintes abstraites d'utilisateurs. Tout le monde connaît la formulation : « elle réfléchit depuis très longtemps », « J'ai une fenêtre rouge », « le système fonctionne d'une manière ou d'une autre de travers », et aussi « cela ne s'est pas produit depuis longtemps, et le revoilà ”.

Dans une telle situation, il est très difficile de déterminer immédiatement où se situe l'erreur et quoi faire en premier lieu. Dans cet article, nous examinerons de quoi dépendent les performances de 1C, c'est-à-dire systèmes à charge élevée créés sur la base de 1C:Enterprise, dans des situations où les symptômes ne sont pas entièrement compris et où il est impossible de poser un diagnostic spécifique.

Les principales raisons affectant les performances de 1C

Dans plus de 60% des cas, les raisons des mauvaises performances sont :

• Requêtes et code de configuration sous-optimaux (26 % des cas) ;
• Indexation sous-optimale des tables d'objets (19 % des cas) ;
• Charge sous-optimale sur le sous-système de disque (16 % des cas).

Les principaux développeurs Microsoft sont solidaires avec cela.

Ainsi, pour obtenir une amélioration significative des performances d'une application de base de données, vous pouvez optimiser la zone d'accès aux données, y compris la conception logique et physique des bases de données (dans la mesure du possible en 1C), ainsi qu'en créant les bonnes requêtes et en utilisant indexation optimale. Une partie des problèmes de performance de la base de données peut être résolue en augmentant la capacité matérielle, mais pas toujours : la mauvaise conception de la solution appliquée ne peut être compensée par un serveur plus puissant. Il n'est pas rare que les entreprises utilisatrices dépensent beaucoup en achetant de nouveaux équipements sans comprendre les causes d'un problème de performance, et le problème reste non résolu.

Des diagnostics de haute qualité des performances 1C utilisant toute la gamme d'outils existants sont la clé d'une résolution de problèmes réussie et d'une optimisation des coûts

La première étape pour identifier et résoudre les problèmes de performances médiocres devrait consister à compiler une liste complète des principales opérations problématiques, en indiquant la vitesse exacte de leur exécution à l'heure actuelle et la vitesse prévue de leur exécution à l'avenir.

Exemple:

Incorrect : le programme se fige lors de la génération d'un rapport. Je veux qu'il se construise plus vite.

A droite : La formation du rapport "Relevé de dette" prend 5 minutes 10 secondes. La vitesse prévue de génération de ce rapport n'est pas supérieure à 20 secondes.

Une fois la liste des problèmes compilée et numérisée, il est nécessaire d'analyser les causes, en commençant par la recherche du code problématique, le cas échéant (par exemple, requêtes "lourdes", longues attentes sur les verrous, interblocages, etc.).

Outils pour identifier le code problématique

• 1C:Performance Management Center (un module inclus dans la boîte à outils 1C:Corporate fabriquée par 1C);
• Services cloud de Gilev ;
• Outils réguliers intégrés au SGBD des principaux fournisseurs.

L'efficacité de l'utilisation de ces outils est garantie par la qualification du développeur "1C : Expert Technologique", ce qui implique sa participation à des implémentations à grande échelle de 1C. Dans le même temps, différents experts, en fonction de leur expérience individuelle, peuvent privilégier l'un ou l'autre outil/méthode.

Parallèlement à l'utilisation d'un des outils présentés, des outils standards de suivi de la charge des équipements sont également utilisés (compteurs « Performance monitors »).

Sur la base des mesures obtenues, la classe de la cause est révélée :

• Le problème est dans le code;
• Et/ou un problème dans le matériel ;
• Le problème réside dans d'autres programmes gourmands en ressources utilisés sur les serveurs de production.

Test de charge 1C - une méthodologie d'évaluation du matériel de serveur

Comme déjà mentionné, parmi les facteurs pouvant affecter les performances de 1C, à la fois positivement et négativement, le matériel serveur et sa configuration occupent une place importante. Considérez les options pour mesurer, évaluer la charge et tester les performances du système dans les conditions suivantes :

• Le serveur 1C est disponible et situé :
• Avec le SGBD ;
• Sur un serveur séparé.

Pour évaluer la conformité des paramètres du matériel serveur existant avec les exigences du système, il est nécessaire de collecter des données sur la charge du matériel, y compris le processeur, c'est-à-dire test de charge 1C. Pour cela, "Performance Monitor" est utilisé - un outil qui vous permet de mesurer l'équipement sur le circuit de travail et de supprimer les compteurs de performance.

Voici un ensemble de compteurs de base que vous devez configurer pour surveiller les performances matérielles dans Windows. La collecte est effectuée à partir de tous les serveurs sur lesquels des serveurs 1C sont installés.

Si le compteur de pourcentage de processeur pour la vue "Processeur" est élevé, vous devez identifier les processus qui peuvent être arrêtés sans affecter le fonctionnement du serveur, et également transférés vers d'autres serveurs.

La vue "Processus" vous permettra de configurer la surveillance de chaque processus individuel, ainsi que de déterminer lequel des processus prend le plus de temps CPU. Si seul le serveur 1C est installé sur le serveur, pour comprendre quelle charge il donne au matériel, vous devez configurer la collection des compteurs suivants :

Si le système actuel est dans un état insatisfaisant, alors sur la base des mesures collectées, en utilisant une relation linéaire, il est nécessaire de calculer les paramètres de l'équipement pour installer le système cible.

Si l'acquisition de matériel serveur n'est prévue, ses paramètres peuvent être calculés en émulant le fonctionnement du système prévu, mais à plus petite échelle, sur les équipements existants. Pour cela, "1C: Test Center" est utilisé, qui est inclus dans le 1C Corporate Toolkit. Sur la base des mesures obtenues, à l'aide des méthodes de calcul, les paramètres du système prévu et, par conséquent, les exigences relatives à l'équipement sont déterminés. Ce test peut être utilisé à plusieurs reprises pour différentes mesures, après avoir ajouté et étendu la fonctionnalité. Cette technique a une grande précision et une facilité de calcul.