{"id":106152,"date":"2022-12-28T11:28:24","date_gmt":"2022-12-28T09:28:24","guid":{"rendered":"https:\/\/jfrog.com\/blog\/monitoring-and-optimizing-artifactory-performance\/"},"modified":"2022-12-28T11:28:24","modified_gmt":"2022-12-28T09:28:24","slug":"monitoring-and-optimizing-artifactory-performance","status":"publish","type":"post","link":"https:\/\/jfrog.com\/fr\/blog\/monitoring-and-optimizing-artifactory-performance\/","title":{"rendered":"Supervision et Optimisation des Performances d'Artifactory"},"content":{"rendered":"

\"JFrog<\/p>\n

\u00c0 mesure que l\u2019utilisation d\u2019Artifactory augmente, ses ressources peuvent progressivement s\u2019\u00e9puiser, provoquant des interruptions ou des probl\u00e8mes de performances. Lorsque l\u2019utilisation augmente, il est d'autant plus important de superviser votre syst\u00e8me et ses donn\u00e9es historiques. La supervision des sch\u00e9mas d\u2019utilisation est une premi\u00e8re \u00e9tape essentielle pour optimiser Artifactory et assurer sa stabilit\u00e9. Nous aimerions partager ici avec vous quelques directives et conseils sur la supervision et le r\u00e9glage d'Artifactory ainsi que de son environnement. Certaines ressources essentielles \u00e0 superviser (et \u00e9ventuellement r\u00e9gler) seront abord\u00e9es, notamment\u00a0: Tomcat, les connexions HTTP, la base de donn\u00e9es, la machine virtuelle Java (JVM) et le stockage.<\/span><\/p>\n

Tomcat<\/span><\/h2>\n

Artifactory s\u2019ex\u00e9cute sur <\/span>Tomcat<\/span><\/a> qui utilise le client HTTP Apache pour g\u00e9rer les requ\u00eates HTTP. Tomcat maintient un pool de threads et alloue un seul thread pour g\u00e9rer chaque demande entrante. Au fur et \u00e0 mesure que le pool de threads s\u2019\u00e9puise, Tomcat en cr\u00e9e d\u2019autres <\/span>(jusqu\u2019au maximum sp\u00e9cifi\u00e9 par l'attribut <\/span>maxThreads<\/b>)<\/span> pour g\u00e9rer les demandes suppl\u00e9mentaires entrantes. <\/span>Si le nombre de demandes d\u00e9passe la valeur maxThreads, les demandes seront mises en file d\u2019attente (jusqu\u2019au maximum sp\u00e9cifi\u00e9 par l\u2019attribut <\/span>acceptCount<\/b>). Si ce param\u00e8tre est trop \u00e9lev\u00e9, les demandes en attente d\u2019un thread libre peuvent rencontrer des retards jusqu\u2019\u00e0 ce que les threads deviennent disponibles pour les g\u00e9rer. Si la limite acceptCount est \u00e9galement atteinte, Tomcat l\u00e8vera des erreurs de \u00ab\u00a0connection refused\u00a0\u00bb pour toutes les demandes suppl\u00e9mentaires jusqu\u2019\u00e0 ce que les ressources requises soient finalement lib\u00e9r\u00e9es. Toute nouvelle demande, chargement, t\u00e9l\u00e9chargement, mise \u00e0 jour, etc., qui n\u2019a pas pu acqu\u00e9rir de thread \u00e9chouera. Pour \u00e9viter ces probl\u00e8mes de performances et ces erreurs, vous pouvez augmenter les valeurs de ces attributs dans le fichier <\/span>server.xml<\/span><\/i> de Tomcat. La valeur par d\u00e9faut de <\/span>maxThreads<\/b> est 200, tandis que <\/span>acceptCount<\/b> est d\u00e9fini sur 100. Le fichier d'exemple <\/span>server.xml<\/span><\/i> ci-dessous affiche des valeurs sup\u00e9rieures pour ces attributs.<\/span><\/p>\n

<<\/span>Connector port="8081" <\/span>acceptCount="200" <\/span>compression="off" <\/span>connectionLinger="-1" <\/span>connectionTimeout="60000"<\/span> maxThreads="600" <\/span>acceptorThreadCount="2" <\/span>enableLookups="false"<\/span>\/>\n<\/span><\/pre>\n
Supervision<\/span><\/h3>\n
Netstat<\/b>\u00a0: Si vous n\u2019avez pas d\u2019outils de supervision configur\u00e9s, vous pouvez facilement surveiller l\u2019utilisation de votre connexion HTTP en direct en ex\u00e9cutant la commande netstat<\/em> ci-dessous (remplacez TOMCAT_PORT par votre port tomcat dans Artifactory).<\/span><\/p>\n
while sleep 5; do printf "$(date) \u00a0HTTP Connections: $(netstat -latuen | grep TOMCAT_PORT<\/strong><\/em> | wc -l)"; echo; done<\/span><\/pre>\n
Vous pouvez \u00e9galement sp\u00e9cifier l\u2019\u00e9tat que vous souhaitez compter. Par exemple, vous pouvez compter le nombre d\u2019\u00e9tats ESTABLISHED en ex\u00e9cutant la commande suivante (remplacez TOMCAT_PORT par votre port Tomcat dans Artifactory)<\/span><\/p>\n
while sleep 5; do printf "$(date) \u00a0HTTP Connections : $(netstat -latuen | grep <\/span>TOMCAT_PORT<\/i><\/b> | <\/span>grep ESTABLISHED<\/b> | wc -l)"; echo; done<\/span><\/pre>\n
 <\/p>\n
MBean pour les connexions HTTP<\/b>\u00a0: \u00c0 partir de la version\u00a04.12, Artifactory a expos\u00e9 la connexion HTTP MBean afin que son utilisation puisse \u00eatre suivie. Ce MBean se trouve dans chaque d\u00e9p\u00f4t sous\u00a0:\u00a0<\/span><\/p>\n
org.jfrog.artifactory > Artifactory | HTTPConnectionPool > [Repo Name]: Attributs<\/em><\/p>\n
Pour en savoir plus, lisez notre billet de blog sur l'Int\u00e9gration d'Artifactory MBeans<\/a>.<\/span><\/p>\n
 <\/p>\n
Outils tiers\u00a0: <\/b>Un certain nombre d\u2019outils tiers peuvent \u00e9galement \u00eatre utilis\u00e9s pour superviser les connexions HTTP et diverses autres ressources. <\/span>La base de connaissances de JFrog<\/span><\/a> contient des instructions pour certains de ces outils, notamment <\/span>JConsole<\/span><\/a>, <\/span>JavaMelody<\/span><\/a> et <\/span>Nagios<\/span><\/a>. Pour le conteneur Docker Artifactory, il existe plusieurs <\/span>outils open source<\/span><\/a> q<\/span>u<\/span><\/a>i<\/span><\/span><\/a> peuvent \u00eatre utilis\u00e9s pour superviser les connexions HTTP, l\u2019utilisation de la machine virtuelle Java, etc. <\/span><\/p>\n
Le graphique ci-dessous a \u00e9t\u00e9 g\u00e9n\u00e9r\u00e9 avec un autre outil nomm\u00e9 <\/span>LogicMonitor<\/span><\/a>. Il montre clairement que le nombre maximal de threads disponibles dans Tomcat a \u00e9t\u00e9 atteint et est un bon indicateur montrant que vous devriez envisager d\u2019augmenter l\u2019attribut maxThreads<\/strong> dans le fichier server.xml<\/em> de Tomcat.<\/span><\/p>\n
\"Monitoring<\/p>\n
Connexions HTTP pour Artifactory<\/span><\/h3>\n
Par d\u00e9faut, le nombre de connexions HTTP autoris\u00e9es par d\u00e9p\u00f4t est d\u00e9fini sur 50. Si vous remarquez que le nombre de connexions utilis\u00e9es approche ou atteint syst\u00e9matiquement cette valeur, vous pouvez l\u2019augmenter \u00e0 l\u2019aide du param\u00e8tre suivant dans le fichier $ARTIFACTORY_HOME\/etc\/artifactory.system.properties<\/em>\u00a0: <\/span><\/p>\n
artifactory.http.client.max.total.connections = {value}<\/span><\/pre>\n
Connexions HTTP si vous utilisez S3 <\/span><\/h3>\n
Si vous utilisez le magasin d\u2019objets S3 pour g\u00e9rer votre filestore, vous devez savoir que le fournisseur binaire S3 d\u2019Artifactory est impl\u00e9ment\u00e9 \u00e0 l\u2019aide de la biblioth\u00e8que Jets3t qui d\u00e9finit le nombre maximal de connexions simultan\u00e9es, autoris\u00e9es \u00e0 100 par d\u00e9faut. Dans le cadre d\u2019une activit\u00e9 intensive avec le filestore qui n\u00e9cessite de nombreuses connexions au magasin d\u2019objets S3, vous pouvez constater que les demandes restent en attente pour une connexion \u00e0 partir du pool de connexions JetS3t. Pour \u00e9viter ce sc\u00e9nario, vous devez ajouter la propri\u00e9t\u00e9 <\/span>httpclient.max-connections<\/span><\/i> pour le fournisseur binaire S3 dans votre fichier <\/span>$ARTIFACTORY_HOME\/etc\/<\/span><\/i>binarystore.xml<\/span><\/i><\/a>. L\u2019extrait de code ci-dessous est un exemple de <\/span>mod\u00e8le Cleversafe<\/span><\/a> extrait du Guide Utilisateur Artifactory qui montre comment d\u00e9finir la propri\u00e9t\u00e9 <\/span>httpclient.max-connections<\/span><\/i>\u00a0:<\/span><\/p>\n
<config version="v1"><\/span>\n \u00a0\u00a0\u00a0<chain template="s3"\/><\/span>\n \u00a0\u00a0\u00a0<provider id="s3" type="s3"><\/span>\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<identity>XXXXXXXXX<\/identity><\/span>\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<credential>XXXXXXXX<\/credential> \u00a0\u00a0\u00a0<\/span>\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<endpoint>[My CleverSafe Server]<\/endpoint>\n<\/span>        <bucketName>[My CleverSafe Bucket]<\/bucketName><\/span>\n        <property name="httpclient.max-connections" value="300"\/><\/span>\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<httpsOnly>false<\/httpsOnly><\/span>\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<property name="s3service.disable-dns-buckets" value="true"><\/property> \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/span>\n \u00a0\u00a0\u00a0<\/provider><\/span>\n<\/config><\/span><\/pre>\n
Connexions HTTP pour le Reverse Proxy <\/span><\/h3>\n
Si vous utilisez un reverse proxy devant votre Artifactory, vous pouvez remarquer que le nombre de connexions HTTP atteint sa valeur maximale, emp\u00eachant ces connexions d\u2019atteindre Artifactory. Dans ce cas, vous devez envisager d\u2019allouer plus de connexions \u00e0 votre reverse proxy. Pour obtenir des instructions d\u00e9taill\u00e9es sur la proc\u00e9dure \u00e0 suivre, lisez la documentation du serveur reverse proxy que vous utilisez. Vous pouvez en savoir plus sur le <\/span>R\u00e9glage de NGINX pour favoriser les performances<\/span><\/a> sur le blog NGINX. Pour Apache, vous pouvez vous r\u00e9f\u00e9rer \u00e0 <\/span>Apache Performance Tuning<\/span><\/a> dans la documentation Apache.\u00a0<\/span>De m\u00eame, vous pouvez vous r\u00e9f\u00e9rer \u00e0 <\/span>cette documentation Apache<\/span><\/a> pour le reverse proxy Apache HTTPD.<\/span><\/p>\n
Base de donn\u00e9es<\/span><\/h2>\n
Le nombre de connexions de base de donn\u00e9es est une autre ressource essentielle qui doit \u00eatre supervis\u00e9e lors de l\u2019optimisation d\u2019Artifactory. Les administrateurs doivent \u00eatre en mesure de confirmer que le nombre de connexions de base de donn\u00e9es disponible est suffisant. Sinon, les utilisateurs peuvent rencontrer des demandes en attente de connexions libres. Le nombre de connexions de base de donn\u00e9es autoris\u00e9es doit \u00eatre r\u00e9gl\u00e9 en fonction de l\u2019utilisation actuelle, mais gardez \u00e0 l\u2019esprit que cette valeur ne doit jamais d\u00e9passer le nombre maximal de connexions de base de donn\u00e9es configur\u00e9es dans la base de donn\u00e9es elle-m\u00eame.<\/span><\/p>\n
Supervision<\/span><\/h3>\n
Artifactory expose \u00e9galement un MBean pour les Connexions de base de donn\u00e9es, afin que vous puissiez les superviser \u00e0 l\u2019aide de n\u2019importe quel outil <\/span>compatible JMX<\/span><\/a>. Si vous utilisez <\/span>JConsole<\/span><\/a>, ce MBean est disponible sous\u00a0: org.jfrog.artifactory > Artifactory > Storage: Data Source. Naturellement, il existe de nombreux autres outils que vous pouvez utiliser pour superviser vos connexions de base de donn\u00e9es. Par exemple, le graphique ci-dessous montre un pic d\u2019utilisation de la base de donn\u00e9es enregistr\u00e9 par l'outil de supervision AWS<\/a> de la base de donn\u00e9es RDS.<\/span><\/p>\n
\"Monitoring<\/p>\n
Netstat peut \u00e9galement \u00eatre utilis\u00e9 ici pour superviser les connexions de base de donn\u00e9es actives (remplacez DB_PORT par votre port de base de donn\u00e9es dans Artifactory)\u00a0:<\/span><\/p>\n
while sleep 5; do printf "$(date) \u00a0DB Connections: $(netstat -latuen | grep <\/span>DB_PORT<\/b> \u00a0| wc -l)"; echo; done<\/span><\/pre>\n
Vous pouvez \u00e9galement sp\u00e9cifier l\u2019\u00e9tat que vous souhaitez compter. Par exemple, vous pouvez compter le nombre d\u2019\u00e9tats LISTEN en ex\u00e9cutant la commande suivante (remplacez DB_PORT par votre port de base de donn\u00e9es dans Artifactory)\u00a0:<\/span><\/p>\n
while sleep 5; do printf "$(date) \u00a0DB Connections: $(netstat -latuen | grep <\/span>DB_PORT<\/b> \u00a0| <\/span>grep LISTEN<\/b>| wc -l)"; echo; done<\/span><\/pre>\n
Si vous constatez que vos connexions de base de donn\u00e9es sont constamment proches de la valeur maximale, vous devrez probablement augmenter celle-ci. Si le nombre de connexions de base de donn\u00e9es actives atteint la valeur maximale et que davantage de connexions de base de donn\u00e9es sont demand\u00e9es, le journal du serveur Artifactory ( $ARTIFACTORY_HOME\/logs\/artifactory.log<\/em>) g\u00e9n\u00e8re l\u2019exception suivante\u00a0:<\/span><\/p>\n
org.springframework.transaction.CannotCreateTransactionException: Could not open JDBC Connection for transaction; nested exception is org.apache.tomcat.jdbc.pool.PoolExhaustedException: [art-exec-672866] Timeout: <\/span>Pool empty. Unable to fetch a connection in 120 seconds, none available[size:100; busy:100; idle:0<\/b>; lastwait:120000].\n\n<\/span><\/pre>\n
Vous pouvez \u00e9galement constater une d\u00e9gradation des performances en raison du nombre accru de connexions de base de donn\u00e9es qui attendent d\u2019obtenir leur place dans la file d\u2019attente inactive (pool.max.idle<\/strong>, ce qui est expliqu\u00e9 dans la section suivante). Vous pouvez le confirmer en effectuant un thread dump<\/a> et en recherchant le nombre de threads qui sont mis de c\u00f4t\u00e9\u00a0: org.apache.tomcat.jdbc.pool.ConnectionPool.returnConnection.<\/em><\/p>\n
R\u00e9glage<\/h3>\n
Dans Artifactory\u00a0:\u00a0<\/b>les connexions \u00e0 la base de donn\u00e9es d\u2019Artifactory peuvent \u00eatre configur\u00e9es en d\u00e9finissant les param\u00e8tres suivants dans le fichier $ARTIFACTORY_HOME\/etc\/db.properties<\/em>\u00a0:<\/p>\n
Pour plus d\u2019informations sur le r\u00e9glage de Tomcat, Netflix offre des informations pr\u00e9cieuses sur son blog, <\/span>Tuning Tomcat For A High Throughput, Fail Fast System<\/span><\/a> .<\/span><\/p>\n