Travailler directement sur système physique, sans virtualisation, pour diminuer le nombre de couches système et faciliter le suivi de l'activité matérielle.
Si vraiment on a besoin de virtualisation, privilégier les conteneurs sur hôte Linux. Docker sous macOS/Windows est pire qu'une VM Linux, puisque son implémentation utilise une VM et cumule donc deux couches de virtualisation qui peuvent chacune affecter les performances et la reproductibilité.
Réduire l'activité système autre que le benchmark au strict minimum
Désactiver les démons et cronjobs non essentiels.
Se passer d'interface graphique (ex: noeud dédié en SSH) quand c'est possible.
Fermer un maximum d'applications de premier plan.
N'interagir d'aucune façon avec la machine pendant l'exécution du benchmark.
Privilégier les ordinateurs fixes aux ordinateurs portables
En effet, on rencontre beaucoup plus de problèmes de reproductibilité liés à la surchauffe et aux systèmes d'économie d'énergie sur ordinateur portable.
Désactiver un maximum de fonctionnalités d'économie d'énergie et d'augmentation de performance non soutenable ("Turbo") pendant les mesures...
...mais faire un test avant/après pour s'assurer qu'ils n'affectent pas significativement la performance du benchmark au préalable. Si c'est le cas, il faut trouver une autre solution (ex: périodes de repos ou de chauffe entre exécutions mesurées du benchmark) sous peine de trop perdre en réalisme.
Inhiber au maximum le mécanisme de swap, voire le désactiver sur les machines ayant beaucoup de RAM.
Les décisions système conduisant à déplacer des données de la RAM à la swap sont complexes et nuisent donc au déterminisme et à la reproductibilité des exécutions. Des données peuvent être mises en swap même si le système ne manque pas de RAM, pour peu que l'OS estime qu'elles sont moins importantes que le cache disque par exemple. On peut inhiber ce comportement de "swapping préventif" en mettant le paramètre vm.swappiness du noyau Linux à 0.
Désactiver la swap élimine le problème totalement, mais au prix d'autres désagréments. Les versions actuelles du noyau Linux ne savent pas gérer l'épuisement de la RAM sans utiliser la swap, et le système se bloquera donc purement et simplement sans possibilité de récupération de la session en cours quand ça se produit. L'alternative de tuer des processus quand les allocations mémoires sont égales à la quantité de mémoire physique ne marche pas bien non plus, elle est trop pessimiste et empêche l'utilisation de l'intégralité de la RAM.