Performances des processeurs monocœur et multicœurs pour différentes charges de travail Mis à jour le 3 mars 2026 par Sam Page 4 Minutes, 36 Secondes pour lire La fiche technique indique 16 cœurs. Votre application est lente. Ces deux faits ne sont pas toujours sans rapport, contrairement à ce que vous pourriez penser. La plupart des charges de travail Web n'utilisent pas tous leurs cœurs en même temps. Certaines n'utilisent jamais plus d'un cœur à la fois pour l'opération qui constitue le véritable goulot d'étranglement. Avant de choisir un... Table des matières La différence fondamentale Charges de travail qui aiment la vitesse d'un seul cœur PHP et sites CMS dynamiques Exécution de requêtes à thread unique MySQL Code d'application hérité Charges de travail qui aiment les processeurs multicœurs Gestion des requêtes simultanées par le serveur Web Architectures conteneurisées et microservices Systèmes de compilation et de construction Inférence par apprentissage automatique Traitement vidéo et encodage multimédia Comment AMD EPYC 4545P arrive à équilibrer les deux aspects Cadre décisionnel pratique La différence fondamentale Un processeur avec une vitesse d'horloge monocœur élevée traite chaque tâche plus vite. Un processeur avec plus de cœurs gère plus de tâches en même temps. C'est différent, et lequel est le plus important dépend vraiment de si ton logiciel peut être parallélisé. Une seule requête PHP-FPM pour afficher une WordPress est en gros à un seul thread. Elle se fait de manière séquentielle : analyser la requête, interroger la base de données, exécuter la logique du modèle PHP, renvoyer le code HTML. Une vitesse d'horloge plus rapide permet de finir plus vite chacune de ces étapes. Plus de cœurs te permettent de gérer plus de requêtes en même temps, mais ça ne rend pas chaque requête plus rapide. Comparez ça à un job de transcodage vidéo, que FFmpeg fait en parallèle sur autant de cœurs que vous lui donnez. Un serveur à 16 cœurs encodera une vidéo environ 10 à 12 fois plus vite qu'un serveur à 2 cœurs avec la même vitesse d'horloge, en supposant qu'il y ait assez de bande passante mémoire. Charges de travail qui aiment la vitesse d'un seul cœur PHP et sites CMS dynamiques WordPress, Drupal et Magento les pages surtout sur un seul thread. PHP-FPM lance des processus de travail séparés pour gérer les visiteurs en même temps, mais chaque processus tourne de son côté. En gros, un serveur avec moins de cœurs, mais plus rapides, gère mieux le trafic PHP simultané qu'un serveur avec plein de cœurs, mais plus lents. PHP 8.x a lancé la compilation JIT, qui est super pour les performances sur un seul cœur. C'est dans les requêtes de base de données pendant l'exécution PHP que le fait d'être mono-thread ressort le plus. Chaque requête doit être finie avant que la ligne PHP suivante puisse être exécutée. Exécution de requêtes à thread unique MySQL Les requêtes SQL individuelles s'exécutent sur un seul thread. Les requêtes complexes, surtout celles qui impliquent des analyses de tables, des tris ou des jointures multi-tables, ne s'exécutent qu'à la vitesse permise par un seul cœur. Plus de cœurs aident MySQL à gérer plus de requêtes simultanées provenant de plusieurs connexions ; ils n'accélèrent pas l'exécution d'une requête individuelle. C'est pour ça que les serveurs de bases de données qui ont beaucoup de requêtes à traiter préfèrent avoir une bonne vitesse d'horloge plutôt que plein de cœurs — et c'est aussi pourquoi bien indexer tes tables est souvent plus important que tout ça. Code d'application hérité Les applications héritées à thread unique écrites avant que le multicœur ne devienne la norme. Beaucoup de systèmes de comptabilité d'entreprise, d'ERP et de CRM entrent dans cette catégorie et ne peuvent tout simplement pas utiliser de cœurs supplémentaires pour leur chemin d'exécution principal. Les exécuter sur un serveur à 32 cœurs revient à gaspiller 31 cœurs, ce qui représente un budget important. Charges de travail qui aiment les processeurs multicœurs Gestion des requêtes simultanées par le serveur Web Nginx Apache gèrent les connexions simultanées avec des processus ou des threads distincts. Un serveur à 16 cœurs peut vraiment traiter 16 requêtes en même temps. À grande échelle, le nombre de cœurs détermine directement la capacité maximale simultanée avant que la mise en file d'attente des requêtes ne commence. Le processeur AMD EPYC 4545P qui alimente le serveur dédié Extreme d'InMotion offre 16 cœurs avec 32 threads grâce au multithreading simultané. Pour les services web à forte concurrence, cette architecture permet à un serveur à socket unique d'exécuter 32 contextes simultanés, ce qui est suffisant pour gérer des volumes de trafic importants avant qu'une mise à l'échelle verticale ne devienne nécessaire. Architectures conteneurisées et microservices Les conteneurs Docker et les pods Kubernetes ont chacun des limites de CPU dans la couche d'orchestration. Un serveur à 16 cœurs qui fait tourner 8 conteneurs, chacun avec 2 limites de CPU, utilise les cœurs de manière efficace. Les mêmes applications sur un serveur à 4 cœurs seraient soit limitées en ressources, soit en concurrence pour le temps CPU. Systèmes de compilation et de construction Les pipelines de compilation CI/CD, surtout ceux qui compilent du C++, du Go ou du Rust pendant la phase de compilation, tirent vraiment leur épingle du jeu grâce au nombre de cœurs. make -j16 sur un serveur à 16 cœurs compile 16 unités de traduction en même temps. Les temps de compilation qui prennent 20 minutes sur 4 cœurs passent souvent à 5-7 minutes sur 16 cœurs. Inférence par apprentissage automatique Les frameworks ML Python, comme PyTorch et TensorFlow, répartissent par défaut les charges de travail d'inférence entre les cœurs de processeur disponibles. Pour les charges de travail d'inférence liées au processeur (sans compter l'inférence GPU), plus il y a de cœurs, plus le débit augmente. Traitement vidéo et encodage multimédia Le drapeau -threads de FFmpeg est réglé par défaut sur le nombre de cœurs de processeur disponibles. Le transcodage en temps réel pour les plateformes vidéo, les pipelines de traitement de podcasts ou les systèmes de gestion multimédia évolue de manière presque linéaire avec le nombre de cœurs, jusqu'à ce que d'autres goulots d'étranglement (E/S, bande passante mémoire) interviennent. Comment AMD EPYC 4545P arrive à équilibrer les deux aspects L'AMD EPYC 4545P est un processeur à architecture Zen 5. Sa conception montre bien que AMD veut trouver le bon équilibre entre la vitesse d'horloge mono-thread et le nombre de cœurs pour les charges de travail réelles des serveurs. Les fréquences d'horloge boostées du 4545P permettent à chaque cœur de tourner à fond quand il n'y a que quelques threads actifs, ce qui est super utile pour les scénarios PHP et MySQL à thread unique dont on a parlé plus haut. Quand il y a plein de threads, tous les cœurs se mettent en route. Cette architecture évite le problème des « nombreux cœurs lents » qui embêtait les anciens processeurs de serveurs avec plein de cœurs. La bande passante mémoire DDR5 est aussi super importante ici. La bande passante mémoire, c'est souvent une contrainte qu'on oublie dans les charges de travail multithread : les cœurs ne peuvent bosser qu'à la vitesse à laquelle les données arrivent de la RAM. La bande passante plus élevée par canal de la DDR5 veut dire que la RAM ECC DDR5 de 192 Go, c'est pas juste une question de capacité, c'est aussi une question de débit. Cadre décisionnel pratique Avant de choisir un serveur dédié pour la configuration du processeur, répondez à ces questions : Le problème, c'est plutôt le nombre de requêtes en même temps ou la vitesse de chaque requête ? Si tu gères 10 000 utilisateurs en même temps avec des requêtes simples, la concurrence est la contrainte principale : les cœurs sont plus importants. Si tu gères 100 utilisateurs qui font des opérations complexes, la vitesse de chaque opération est plus importante : la vitesse d'horloge est prioritaire. Est-ce que le code de mon application est multithread ? Regarde la documentation. PHP n'est pas multithread au niveau des requêtes. Node.js a une boucle d'événements qui gère la concurrence, mais ne peut utiliser plusieurs cœurs que via le clustering ou les threads de travail. Les goroutines Go sont vraiment parallèles entre les cœurs. Qu'est-ce que mon profilage CPU réel montre ? Si tu as déjà des charges de travail en production quelque part, le classement par CPU te montrera si un seul processus est bloqué à environ 100 % (goulot d'étranglement à thread unique) ou si plusieurs processus consomment chacun une partie importante du CPU (utilisation multicœur). La plupart des applications web de production profitent en fait des deux : des performances monocœur rapides pour exécuter les requêtes de base de données et le rendu PHP, et un nombre de cœurs suffisant pour gérer les visiteurs en même temps. L'architecture de l'AMD EPYC 4545P offre cet équilibre, c'est pourquoi il convient mieux aux charges de travail générales que les processeurs optimisés pour une dimension au détriment de l'autre. Partager cet article Articles connexes Les serveurs écologiques InMotion Hosting: ce qu'apporte réellement le matériel d'entreprise reconditionné RAM DDR4 vs DDR5 : Une comparaison approfondie AMD EPYC vs Intel Xeon : ce que les acheteurs d'hébergement doivent vraiment savoir Hébergement sur serveur dédié Moodle : pourquoi le partage des ressources nuit aux performances des plateformes d'apprentissage en ligne Guide de décision pour les agences qui évaluent les infrastructures d'hébergement Serveurs dédiés bare metal : qu'est-ce que c'est et comment évaluer les fournisseurs Comment choisir une offre de serveur dédié : un cadre basé sur la charge de travail Qu'est-ce que l'IPMI et pourquoi est-ce important pour la gestion des serveurs dédiés ? Traitement de données à haute fréquence sur des serveurs dédiés Analyse du coût total de possession : possession d'un serveur dédié sur 3 ans vs 5 ans