Les jobs CI peuvent être très consomateurs en IOPS, notamment lors des phases de téléchargement des artifacts (maven :) ou docker par exemple...) ou lors du build. Une CI déployée sur des instances EC2 avec des volumes EBS standards (gp2) peut connaitre des temps de réponse particulièrement dégradés lorsqu'elle à dépassé sa capacité de burst et qu'elle est limité en IOPS.
Il est interessant dans ce contexte de monitorer l'EBS Burst Balance sur ces volumes.
En cas de performance limitée par les IOPS EBS, il y a 3 solutions:
- augmenter la taille des EBS pour bénéficier de d'un nombre d'IOPS plus important (nb IOPS = 3 x nb GB)
- passer sur des EBS de type io1 pour bénéficier d'un nombre d'IOPS garanti (souvent moins intéressant en terme de coûts)
- utiliser des instances disposant de SSD internes à la place des EBS (ex: c5d ou m5d instances)
Une description plus détaillé de la métrique Memory Pressure.
Le Memory Pressure est une des principales métriques pour vérifier le sizing de son cluster ES sur Elastic Cloud.
- Tant que la Memory Pressure est en dessous de 75%, le cluster est bien dimensionnée au niveau mémoire.
- Entre 75% et 85%, le cluster va consommer de plus en plus de CPU pour faire des GC. Tant que les perfs et la conso CPU sont acceptables, pas de soucis, le cas échéant il faut upgrader le cluster.
- Au dessus de 85%, Le temps passé à faire des GC et le risque d'OOM sera trop important. Il faut absolument upgrader le cluster.
Pour aller plus loin: Understanding the Memory Pressure Indicator
Description des métriques de performance pour Elastic Cloud (la solution SAAS Elastic Search officielle)
A partir de Java8, la Metaspace qui remplace la PermGen n'est plus dans la Heap Java mais dans la mémoire native de l'OS.
Par défaut le HeapDump ne fournit donc plus d'infos sur la Metaspace.
Solution:
jmap -clstats PID to dump class loader statistics;
jcmd PID GC.class_stats to print the detailed information about memory usage of each loaded class. The latter requires -XX:+UnlockDiagnosticVMOptions.Tuning du nombre de threads tomcat
Bees crée des instances EC2 à la volée et lance des tests de charge distribués
Ce guide explique le fonctionnement interne de la JVM et des différents Garbage Collectors et donne des piste de troubleshooting et de profiling avec VisualVM et autres outils d'analyse de dump.
A performance budget is just what it sounds like: you set a “budget” on your page and do not allow the page to exceed that. This may be a specific load time, but it is usually an easier conversation to have when you break the budget down into the number of requests or size of the page.
(...)
Once those goals are set, you stick to them. Anytime you want to add something to a page, you need to ensure it stays within budget. Steve Souders talked about the three options you have if something does not fit within the budget:
- Optimize an existing feature or asset on the page.
- Remove an existing feature or asset from the page.
- Don’t add the new feature or asset.
Le budget performance correspond à la valeur max autorisée pour une métrique de performance (temps de chargement, nombre de requêtes ou poids de la page). On peut ensuite tester le "budget" au cours de l'intégration continue avec un outils comme SiteSpeed.io et remonter une alerte en cas de dépassement.
Les métriques à mesurer pendant un test de performance:
- Errors over load (“results valid?”)
- Bandwidth throughput over load (“system bottleneck?”)
- Response time over load (“how does system scale?”)
- Business process end-to-end
- Page level (min-avg-max-SD-90th percentile)
- System resources (“how’s the infrastructure capacity?”)
- Server cpu over load
- JVM heap memory/GC
- DB lock contention, I/O Latency
Pour analyser la performance d'un site web. Pas mal de fonctionnalités intéressantes:
- Dashboard Graphite/Grafana (procédure avec Docker incluse)
- Check Performance Budget
- Intégration WebPageTest et Google PageSpeed Insights
- Intégration CI avec Jenkins & Travis
Description des Headers HTTP utilisés pour mettre en cache du contenu
Optimisation et Troubleshooting de JVM pour Java mises à jour pour Java8
Une explication des paramètres sendfile, tcp_nodelay et tcp_nopush avec Nginx, à activer pour servir des fichiers statiques ou faire du micro caching
Comment utiliser Apache JMeter pour créer des tests de charge
Introduction au Real User Monitoring pour récupérer les métriques (temps de chargement des pages...) coté navigateur web des utilisateurs
Une très bonne et très complète explication du concept et des enjeux des CDN
Une conf sur les bonnes pratiques de dev pour optimiser une applis PHP. Une bonne partie des points sont valables aussi pour les applis web utilisant d'autres langages.
Entre autre:
- stocker uniquement le code dans le filesystem
- stocker les sessions en database (clé/valeur ou sql)
- gérer les logs avec syslog
- séparer les assets (fichiers statiques) du code en utilisant un système dédié (ex: S3) et un nom de domaine séparé
- ne jamais faire de hot fix directement sur le serveur
- utiliser git pour déployer
- utiliser un système de build (ex: composer pour php ou npm/grunt/browserify pour js)
- ne jamais commiter les dépendances avec le code
- l'application doit fonctionner sans les droits d'écriture sur le serveur
- utiliser les fast-cgi et php-fpm, ne plus utiliser mod_php
- utiliser les variables d'environnements pour la conf (ex: db host, ...)
- utiliser les uuid au lieu d'auto increment pour les id utilisateurs
Comment servir jusqu'à 400x plus de requêtes par secondes sur un site wordpress en positionnant un serveur nginx cache en front paramétré pour garder en cache le contenu dynamique pour une durée d'une seconde
Un tuto pour utiliser Jmeter pour lancer des tests de charges