Je suis en train de mettre en œuvre des tests de performance avec Gatling. Un des principaux outils libres de tests de performance.
J’ai eu récemment à résoudre un « petit » soucis : je souhaitai partager des variables entre plusieurs scénarios. Il existe pas mal de solutions sur stackoverflow. J’ai condensé certaines d’entre elles pour les adapter à mon besoin. Ces variables sont issues de exécution d’une seule requête et sont automatiquement injectées dans les scénarios suivants. Ce mécanisme permet par exemple de récupérer un jeton d’un serveur d’identification et de l’injecter pour le scénario que l’on souhaite tester.
Pour ce faire, il faut ajouter une variable de type LinkedBlockingDeque et injecter le contenu choisi via la session
val holder = new LinkedBlockingDeque[String]()
...
val firstScenario = scenario("First Simulation")
.exec(http("first scenario")
.post("/base/url1")
.check(jsonPath("$.my_variable").find.saveAs("variable")))
.exec(session => {
holder.offerLast(session("variable").as[String])
session}
);
Maintenant on peut l’utiliser dans un autre scénario comme feeder:
val secondScenario = scenario("Second Simulation")
.feed(sharedDataFeeder)
Voici l’exemple complet
En espérant que cela puisse aider à certain.e.s d’entre vous 🙂
Une fois n’est pas coutume, voici un article qui reprend des basiques de la programmation. J’aborde une stack JAVA, mais c’est applicable à d’autres langages.
Il existe une fonctionnalité très intéressante dans Spring (et dans J(akarta)EE) que l’on oublie assez souvent : l’AOP ou encore la programmation par aspect. Cette manière de programmer permet notamment de séparer le code fonctionnel et technique. Si vous faites du JAVA, vous utilisez déjà l’AOP. En effet, quand vous faites une insertion en base via JPA dans un EJB ou un bean annoté @Transactional, une transaction est initiée au début de la méthode et fermée à la fin.
Dans la configuration ci-dessous, je prendrai comme exemple le logging des méthodes ( un log en début de méthode et un log en fin ).
La définition des aspects se fait dans des classes annotées par @Configuration.
@Configuration
@Aspect
@ConditionalOnProperty(name = "debug.enabled", havingValue = "true")
public class DebuggingConfiguration {
private static final Logger LOGGER = LoggerFactory.getLogger(DebuggingConfiguration.class);
private static final String WITHIN_MY_PACKAGE = "within(my.package..*)";
/**
* Log before execution
*
* @param joinPoint the current method
*/
@Before(WITHIN_MY_PACKAGE)
public void logBeforeExecution(JoinPoint joinPoint) {
if (LOGGER.isTraceEnabled()) {
LOGGER.trace("Beginning of method : [{}]", joinPoint.getSignature().getName());
}
}
/**
* Log after execution
*
* @param joinPoint the current method
*/
@After(WITHIN_MY_PACKAGE)
public void logAfterExecution(JoinPoint joinPoint) {
if (LOGGER.isTraceEnabled()) {
LOGGER.trace("End of method : [{}]", joinPoint.getSignature().getName());
}
}
}
L’utilisation de l’ annotation @ConditionalOnProperty me permet d’activer cette classe de configuration seulement si la propriété debug.enabled est initialisée à true.
Les annotations @Before et @After indiquent à Spring AOP quand exécuter ces méthodes ou sur quelles méthodes. Dans mon cas, quand les méthodes appelées sont définies dans les classes d’un package défini.
Pour plus de détails sur la syntaxe et les possibilités, vous pouvez vous référer à la documentation.
Et indiquez que vous voulez signer tous vos commits
git config --local commit.gpgsign true
Si vous ne faites pas cette dernière commande, vous devrez ajouter l’option -S à chaque exécution de la commande git commit.
Exemple:
git -a -S -m "Ajout javadoc"
Configuration GITHUB
Sur Github ( il y a la même chose sur gitlab), vous pouvez dans vos paramètres ajouter cette clé . De cette manière, vos prochains commits envoyés seront vérifiés.
Si vous provisionnez vos VM VirtualBox avec Vagrant, vous avez sans doute eu l’idée d’automatiser le provisionning des machines virtuelles. Dans mon cas une VM GNU/Linux basée sur Debian 9.
Pour cela, soit vous faite tout manuellement et après les mises à jour deviennent fastidieuses, soit vous appliquez un script shell au démarrage de vagrant, soit vous utilisez Ansible.
Ansible est un outil opensource permettant d’automatiser le provisionning et la mise à jour des environnements à distance (via SSH). L’avantage par rapport à des outils tels que Puppet, est qu’il ne nécessite pas l’installation d’agent.
Je vais essayer de vous montrer comment mettre en place le provisionning via Ansible pour VirtualBox.
Configuration de Vagrant
Dans le fichier Vagrantfile, on active le provisionning via Ansible:
config.vm.provision "ansible_local" do |ansible| ansible.playbook = "site.yml" ansible.install_mode = "pip" ansible.version = "2.7.10" end
Cette configuration fait référence à un fichier « playbook » site.yml. C’est la configuration qui sera appliqué lors du provisionning . Que ça soit à la création ou pour les mises à jour.
Voici un exemple de contenu:
- name: VirtualBox hosts: all become: yes become_user: "root" become_method: "sudo" roles: - common vars_files: - vars/environment.yml
Ce fichier est la racine de notre configuration Ansible. On y référence les rôles appliqués et les fichiers d’ environnement. Voici un exemple de rôle:
- name: "Remove useless packages from the cache" apt: autoclean: yes force_apt_get: yes
- name: "Remove dependencies that are no longer required" apt: autoremove: yes force_apt_get: yes
- name: "Update and upgrade apt packages (may take a while)" become: true apt: upgrade: dist update_cache: yes force_apt_get: yes
Les variables d’environnement permettent de variabiliser certains champs de vos rôles. On peut trouver par exemple les versions de certains outils déployés
Il y a une quantité impressionnante de modules Ansible que l’on peut utiliser. Que ça soit pour lancer des commandes shell ou lancer des services. Contrairement à la création d’un script shell qui pourrait faire les mêmes actions à la création, on peut facilement gérer la mise à jour de la VM car Ansible détecte les modifications lors de son exécution.
Configuration spécifique pour VirtualBox
Pour VirtualBox, j’ai ajouté deux fichiers de configuration supplémentaires à la racine:
ansible.cfg
[defaults] hostfile = hosts
hosts
[local] localhost ansible_connection=local
Provisionning
A la création
le provisionning peut se faire au lancement de vagrant via la commande:
vagrant up
Pour faire une mise à jour
Directement dans la box, vous pouvez lancer les commandes suivantes :
sudo mount -t vboxsf vagrant /vagrant
Puis, vous pouvez lancer les commandes suivantes dans la box:
su - cd /vagrant export ANSIBLE_CONFIG=/vagrant ansible-playbook site.yml
En attendant de prendre mon train, j’essaye de me remettre de cette nouvelle édition. Cette année JAVA est revenu au premier plan. Que ça soit via la spécification microprofile, quarkus , graalvm ou encore par les problématiques de migration JDK 8 -> 11. On a pas mal vu des architectures micro services à base de service mesh (istio) et kubernetes.
A coté des sujets techniques, un des sujets majeurs était le bien être et la bienveillance au travail.
Je pense qu’il y a encore bien d’autres conférences qui ont été très intéressantes. J’ ai quelques heures de visionnage à prévoir dans mon agenda 🙂 . Quoi qu’il en soit, merci aux organisateurs pour cette édition. C’était top!
Après avoir mis à jour mon mot de passe Spotify ( oui, il faut modifier régulièrement ses mots de passe ) , j’ai eu un petit soucis sur MoodeAudio ( version 4.4) et notamment sur la connexion avec Spotify.
Après quelques recherches sur le forum de moodeaudio, j’ai trouvé la correction qui allait bien.
Voici comment faire :
D’abord on se connecte via SSH sur le raspberry pi
Dans la série j’équipe ma maison en Raspberry PI, j’ai décidé de me doter d’une station radio connectée qui me permettrait de « moderniser » un peu ma chaîne HI-FI.
Mes besoins sont:
Connexion en analogique à une chaîne HI-FI
Jouer des MP3/FLAC stockés dans un NAS
Jouer des web radios (ex. FIP, TSF JAZZ)
Connexion SPOTIFY
Une interface web sympa
Après quelques recherches, j’ai donc opté pour une solution basée sur un DAC JustBoom, un Raspberry PI et la distribution MoodeAudio.
Voici le DAC que l’on branche directement sur le port GPIO du Raspberry PI:
L’installation et la configuration du DAC se sont très bien passées. L’installation se fait comme avec des LEGOs.
Que la lumière soit
Pour la configuration, j’ai testé dans un premier temps Volumio puis MoodeAudio. Pour l’instant, je reste sur cette dernière. Toutes les fonctionnalités que je souhaite sont en standard. Pas besoin de plugins tiers.
Toutes les étapes d’ installation et de configuration pour que le DAC soit reconnu sont décrites ici. Les gens de chez JustBoom ont bien documenté la configuration pour les principales distributions.
Le seul reproche que je trouve à MoodeAudio est l’ergonomie. Sur un téléphone, ce n’est pas top. Surtout sur l’accès aux menus d’administration. J’ai du également ajouter des radios manuellement alors que dans Volumio, avec le plugin TuneIn, ça pouvait se faire automatiquement. Je me suis basé sur les informations fournies par ce site.
Quoi qu’il en soit, tout ce que je souhaitais fonctionne super bien! Spotify Connect, l’écoute de TSF JAZZ, la lecture des morceaux de ma bibliothèque fonctionnent nickel !
Il y a quelques jours, je cherchais comment tracer rapidement et simplement les entrées sorties d’une API REST en appliquant quelques formatages, des filtres, et des insertions en base si besoin.
Travaillant sur une stack SpringBoot, vous allez me dire : oui tu peux faire des filtres. Pour être franc, j’ai essayé d’ appliquer des interceptor et filtres mais dans mon contexte, ça ne collait pas.
Me voilà donc à la recherche d’une solution faisant le taff et qui soit peu intrusive dans mon contexte.
J’ai trouvé par hasard au fil de mes lectures sur Stackoverflow le framework logbook réalisé par … Zalando ( et oui, ils ne font pas que des chaussures) en licence MIT. Ce composant ne fait qu’une seule chose, mais il le fait bien !
Il permet entre autres de s’intégrer dans une stack JAVA ( JAX-RS ou SpringMVC), de filtrer, récupérer les différentes informations des requêtes et réponses et enfin de formatter selon l’envie (ex. JSON).
Voici un exemple de mise en œuvre dans un projet SpringBoot:
Dans le fichier pom.xml, ajouter cette dépendance:
Dans une de vos classes Configuration, définir la factory de Logbook
@Bean public Logbook createLogBook() { // too easy : return Logbook.create(); return Logbook.builder() .condition(Conditions.requestTo("/helloworld")) .formatter(new JsonHttpLogFormatter()) .build(); }
Dans mon cas j’ai fait un filtre en n’incluant que l’ API /helloworld et j’ai formatté en JSON. On peut également modifier le processus d’écriture pour ne pas écrire dans un fichier mais en base par ex.
Ensuite, j’ai ajouté la configuration du logger dans le fichier application.properties
logging.level.org.zalando.logbook:TRACE
Et voila !
Dans la console, lors d’un appel ou d’une réponse à mon API, j’ai le message suivant :
Vous remarquerez que les requêtes / réponses peuvent désormais être associés grâce à un identifiant de corrélation. On peut facilement déterminer le temps de traitement d’une requête ou encore faciliter les recherches.
