MilamberSpace

Pour ceux qui ne connaissent pas YUM, ce dernier est un utilitaire bien pratique dans les distributions Linux utilisant les packages RPM, tel que RedHat ou CentOS.

YUM permet en effet de faire la gestion des packages sur ces types de distributions, en gérant les dépendances entre les packages, c’est-à-dire que si vous voulez installer par exemple PHP sur votre serveur Linux RedHat, il suffit de faire « yum install php » et hop, tous les packages nécessaires à PHP vont être installés (entre autres le serveur Apache HTTP :-)).

Mais pour cela, YUM a besoin d’une connexion à Internet pour 1/ localiser le package désiré, 2/ télécharger son entête pour voir ses dépendances, 3/ télécharger les entêtes de ses dépendances et générer également les dépendances de ses dépendances, 4/ puis quand il n’y a plus de dépendances à gérer, procéder au téléchargement et à l’installation.

Le problème est que parfois, la connexion à Internet n’est pas disponible pour faire des installations ou des mises à jour sur des serveurs dans des salles blanches sécurisées. Pas de problème, YUM avec un peu de configuration sait aussi travailler en « local », à partir du média d’origine ou d’une version de mise à jour. Lire le reste de cet article »

Un tour de nostalagie avec mon premier ordinateur portable, il s’agit d’un Toshiba T2150CDS datant de l’été 1996. Le processeur est un 486 DX, cadencé à 75 Mhz ! La belle époque.

Il fonctionne à ce jour (août 2008) avec Windows 95, la batterie est morte par contre (c’est bien normal). Evidemment ce n’est pas une bête de course, et avec ses 500 Mo de disque dur, je ne vais pas aller loin maintenant.

Lire le reste de cet article »

Vous utilisez JMeter pour faire un tir de charges (ou autres), et vous devez avoir une requête qui s’exécute à un intervalle fixe quelque soit le temps de réponse de la requête.

Par exemple, vous devez exécuter une requête chaque 20 secondes, le temps de réponse de la dite requête est 4,5 sec. Donc si on démarre à T0, on a T0+4,5 sec la requête, puis on demande à JMeter de faire une pause pendant (20 sec – 4,5 sec = 15,5 sec), puis une nouvelle requête, etc.

Voici comme le faire avec JMeter. Lire le reste de cet article »

Pour les « grands » tirs de charges dont l’objectif est de tester une nouvelle application J2EE (ou JEE) avant sa mise en production, et afin d’éviter les crashs le jour du lancement, on mobilise en général une équipe des différents « corps de métier » informatiques.

On aura ainsi :

• les « tireurs » ceux qui vont faire le tir de charges avec un outil dédié,
• les fonctionnels qui assistent les tireurs pour la scénarisation du tir,
• les préparateurs de données qui sont chargés de fournir des données aux injecteurs pour le tir,
• les gens du réseau pour la surveillance du trafic et de la bande passante,
• les DBA pour la surveillance de l’activité de la base de données,
• les superviseurs des serveurs d’applications pour monitorer l’activité de l’application,
• l’équipe de développement de l’application qui croisent les doigts,
• et bien sur les chefs du fonctionnel et les chefs de la technique

Tout cela fait beaucoup de monde, on ajoutera en général un responsable général, chargé entre autre de synchroniser toutes les actions, et donner le GO du lancement.

Une fois que le tir lancé et terminé, l’expérience montre que c’est en général du coté du serveur d’applications J2EE que les problèmes sont visibles. Où s’ils ne sont pas visibles, on pense à lui en premier car c’est lui qui supporte l’application. Alors quand c’est vous le responsable de la supervision du cluster de serveurs d’applications, tout ce beau monde se retourne vers vous pour avoir l’explication, le comment du pourquoi, afin de comprendre la raison du non succès du tir de charge…

Pourtant vous avez fait une configuration des serveurs d’applications clustérisés aux petits oignons :

• configuration de la taille minimum et maximum idéale pour ce type d’application
• modification des paramètres de JVM pour avoir notamment un fonctionnement du Garbage Collector en (quasi) parallèle (Concurrent Mark Sweep)
• réglage des unités d’exécution min et max, temps d’inactivité
• réglage du pool de connexions à la base de données, avec activation du cache des requêtes SQL préparées
• réglage du gestionnaire de sessions
• activation du monitoring,
• et d’autres petits réglages de derrière les fagots : taille des files d’attente TCP, nombre des requêtes keep-alive, etc

Alors avec ce tunning de folie, difficile de comprendre pourquoi le serveur d’applications souffre lors du tir de charges… Lire le reste de cet article »