O'Reilly Japan \ -Java Performance Résumé du chapitre 2 de ce livre
Chapitre 1 Introduction \ -Qiita ← Article précédent Chapitre 2 Approche des tests de performance - Qiita ← Cet article Chapitre 3 Java Performance Toolbox \ -Qiita ← Article suivant Chapitre 4 Mécanisme du compilateur JIT \ -Qiita Chapitre 5 Principes de base du nettoyage de la mémoire \ -Qiita
Il existe 3 types de tests
Comme son nom l'indique, il teste en petites unités.
Utilisé pour comparer de petites différences d'implémentation. Des précautions doivent être prises lors de l'écriture du code de test, et à moins que le code n'utilise les résultats du traitement, le traitement du calcul sera supprimé par l'optimisation du compilateur.
Que le microbench soit multithread ou mono-thread, il est important d'ajouter volatile (non optimisé, également utilisé lorsque vous ne voulez pas mettre en cache).
Dans les micro-benchmarks, la synchronisation, qui est rarement un problème en fonctionnement réel, devient souvent un goulot d'étranglement et il faut du temps pour le résoudre.
↓ Matériel de référence sur les matières volatiles Declaring a Variable Volatile (Writing Device Drivers)
Dans le benchmark, lors de l'appel de la méthode synchronized à partir de plusieurs threads, la synchronisation devient un goulot d'étranglement, il convient donc de noter qu'il ne s'agit pas d'un benchmark mais d'une mesure du temps nécessaire à la JVM pour résoudre le conflit.
En préparant la valeur d'entrée à l'avance et en la transmettant, n'ajoutez pas de traitement supplémentaire au code de référence.
Le test doit être basé sur les valeurs d'entrée correctes. Par exemple, nous ne mesurons pas avec des nombres extrêmement grands qui ne peuvent pas être effectués en fonctionnement réel.
Comme expliqué dans le chapitre 4, Java devient plus rapide à mesure que le code est exécuté à plusieurs reprises, donc un préchauffage doit être effectué.
La meilleure façon de tester les performances de votre application est de combiner les ressources externes utilisées. Un tel test est appelé un macro benchmark.
C'est un vrai processus, mais il n'utilise pas une application complète, mais c'est un test plus fin qu'un micro-banc. Par exemple, une mesure de la vitesse de réponse d'un serveur Web (je n'ai pas essayé les fonctionnalités de session ou de connexion). Le benchmark meso convient également aux tests automatisés.
Il mesure du début à la fin d'une application. Efficace si cela n'a pas d'importance dans son ensemble. Au contraire, si cela devient un problème lorsqu'il est en retard avant l'échauffement, une autre méthode de mesure est nécessaire. Dans le cas de Java, un préchauffage est nécessaire, donc ce n'est pas facile.
Mesure de la quantité de traitement pouvant être effectuée dans un certain laps de temps. Dans le cas de type client-serveur, il faut mesurer sans temps de réflexion (temps d'attente sans rien faire). Le nombre de requêtes par seconde est souvent utilisé. TPS (transactions par seconde), RPS (requêtes par seconde), OPS (opérations par seconde), etc.
Il existe deux façons de calculer le temps de réponse. L'un est la valeur moyenne. La seconde est la valeur du centile. Par exemple, lorsque la valeur du 90e centile est de 1,5 seconde, le temps de réponse de 90% des demandes est de 1,5 seconde ou moins et les 10% restants sont de 1,5 seconde ou plus.
Dans ce livre, le générateur de charge de ↓ a été présenté About Faban
Le test change avec le temps. Un bon benchmark utilise des données avec des aléas différents pour chaque exécution proche du monde réel. Lors de la comparaison des résultats des tests, il est difficile de déterminer s'il y a un problème avec le code ou s'il s'agit d'une coïncidence.
| Ligne de base | Spécimen | |
|---|---|---|
| Première fois | 1.0 seconde | 0.5 secondes |
| Deuxième fois | 0.8 secondes | 1.25 secondes |
| Troisième fois | 1.2 secondes | 0.5 secondes |
| Valeur moyenne | 1.0 seconde | 0.75 secondes |
Dans le cas du résultat du test, le test t de l'élève a 43% de chances que la performance soit la même.
Cependant, en raison de l'incertitude des données, aucun jugement catégorique ne peut être émis, quelle que soit la quantité d'analyse effectuée.
Il est important de tester fréquemment, mais il est nécessaire de l'équilibre avec la situation actuelle.
Des tests précoces et fréquents sont extrêmement bénéfiques si ce qui suit est vrai: Parce qu'il est facile d'obtenir des conseils pour des solutions.
Recommended Posts