1 
1 
Université de la 
Performance
2 
2 
Présentation de 
l’équipe 
Tél : +41 21 312 94 15 
www.octo.com 
© OCTO 2014 
Avenue du théâtre 7 
CH-1005 Lausanne ...
3 
3 
Jean-Philippe Briend 
! Software Architect 
! Référent technique Pôle 
Performance 
! PerfUG Paris co-leader 
! Open...
4 
4 
Philippe Kernévez 
! Directeur Technique 
! Référent technique pôle 
performance 
! OSSGTP Member 
! JUGLausanne co-...
5 
5 
Agenda 
Tél : +41 21 312 94 15 
www.octo.com 
© OCTO 2014 
Test de 
performance 
unitaire 
Avenue du théâtre 7 
CH-1...
6 
6 
Applicatif Système
7 
7 
Développement Production
8 
8 
Méthodologie
9 
9 
DÉMO
101 
0 
DÉMO
111 
1 
Les performances d’un 
système sont une 
spécification 
fonctionnelle implicite 
du système 
Notre vision ? 
Sourc...
121 
2 
La mesure de performance 
doit être au coeur du 
processus de 
développement 
informatique 
Notre vision ? 
Source...
LES 4 DIFFÉRENTS TYPES DE TEST 
131 
3 
• Objectif : mesurer la performance unitaire 
• Ex : le use case de souscription e...
141 
4 
La démarche de test que nous utilisons 
Global vers Local puis Local vers Global 
TESTS DE CHARGE 
TESTS DE PERFOR...
151 
5 
La démarche de test que nous utilisons 
TESTS DE CHARGE 
TESTS DE PERFORMANCE 
UNITAIRE 
Mesurer Optimiser 
Scénar...
161 
6 
Définition du plan et des 
cas de test 
Méthodologie d’un test de charge 
Plan de test Cas de test 
Création des s...
171 
7 
Les outils utilisés aujourd’hui 
GÉNÉRER LES DONNÉES 
! Migrer les données depuis la production mais 
il faut souv...
181 
8 
Les outils en général 
HPJMeter 
Analyse de log GC 
Injection 
Profiling 
APM
191 
9 
Notre fil rouge : Happy Store 
Navigateur Tomcat PgSQL 
Une application comme on en 
rencontre souvent, pas très l...
202 
0 
Architecture 
APPLICATION SERVER 
DATABASE SERVER 
Tomcat 
JVM 
PostgreSQL
212 
1 
Modèle de base de données 
Store 
0,n 
1 
Stock 
Category Family Product Sales Operation 
VAT Country Sales Transa...
222 
2 
Acheter des produits
232 
3 
Finaliser sa commande 
Total
242 
4 
Calcul de l’inventaire sur un magasin 
Inventory
252 
5 
Calcul du chiffre d’affaire par groupe de produits 
Turnover 
(group by+order by)
262 
6 
Cible de performance 
! Cible : 100 utilisateurs concurrents 
! Volumétrie de la base de données : 13 millions de ...
LES DIFFÉRENTS TYPES DE TEST 
272 
7 
• Objectif : mesurer la performance unitaire 
• Ex : le use case de souscription est...
282 
8 
DÉMO 
28 
Exécution test unitaire
292 
9 
Que fais le serveur applicatif pendant ce temps ? 
! Identifier la JVM 
! Faire un threadump pendant la requête
303 
0 
! C’est le seul à exécuter du code applicatif 
Identifier notre Thread 
! Il attend la base… mais quelle est la re...
313 
1 
! Vérification de la configuration des traces 
! Les requêtes de plus de 700ms sont tracées 
! On obtient la requê...
323 
2 
Pourquoi cette requête est lente ? 
select sum(amount), …. 
from SaleOperation 
where groupId=1 and operationdate ...
333 
3 
DÉMO 
33 
Exécution test unitaire
343 
4 
Remplissage des données : Benerator 
! Principes : la base de données est alimentées avec 2 sources 
! Une (petite...
353 
5 
Configuration Benerator
363 
6 
! Temps de création de happystore è 1h20 
! 8 tables / 13 M de lignes 
! (un thread sur MB avec VM) 
! Temps de r...
LES DIFFÉRENTS TYPES DE TEST 
383 
8 
• Objectif : mesurer la performance unitaire 
• Ex : le use case de souscription est...
393 
9 
Architecture 
LOCAL SERVER APPLICATION SERVER 
DATABASE SERVER 
Gatling 
Tomcat 
JVM 
PostgreSQL
404 
0 
Gatling - Recorder
414 
1 
Gatling – DSL Scala 
URL + header http 
page1 
page2 
Nb utilisateurs + durée
424 
2 
Montée en charge 
nombre d'utilisateurs 
durée 
20 min 2h 
delay ramp up duration
434 
3 
Exécution Gatling
444 
4 
Résultats Gatling
454 
5
474 
7 
Premature optimization is the 
root of all evil - Donald Knuth
484 
8 
Il voulait dire ça: 
// Do not use the for(Object o : list) 
// because I think it is probably 
// slower than doi...
494 
9 
Code 
Mesure 
Optimise Là où 
c’est 
important
505 
0 
DÉMO 
50 
Visual VM
515 
1 
Architecture 
TOOL SERVER APPLICATION SERVER 
Collectd 
DATABASE SERVER 
CI STACK 
Jenkins 
GRAPHITE STACK 
Gatlin...
525 
2 
DÉMO 
52 
Graphite & Metrics
535 
3 
Un exemple d’outil d’APM du marché : AppDynamics
545 
4
555 
5 
Développement 
Production 
Architecture 
Perf.
565 
6 
3. Développement 
2. Automatisation 
Architecture Développement 
Perf. 
1. Conception 
des tests 
des tests 
logic...
575 
7 
3. Développement 
2. Automatisation 
des tests 
#1 #2 #3 
Délai 
Perf. 
PERFORMANCES 
CATASTROPHIQUES 
MEP À L’ARR...
585 
8 
3. Développement 
2. Automatisation 
1. Conception 
des tests 
des tests 
logiciel 
4. Exécution auto-matique 
des...
595 
9 
Intégrer les tests de performances au cycle de 
développement? 
Hyperviseur 
AppServer 
Chef 
DbServer 
Chef 
1 
2...
626 
2 
DÉMO 
62 
Automatisation des tests
LES DIFFÉRENTS TYPES DE TEST 
636 
3 
• Objectif : mesurer la performance unitaire 
• Ex : le use case de souscription est...
646 
4 
Test de rupture 
100 
requêtes par secondes 
nombre d'utilisateurs
656 
5 
Montée en charge 
nombre d'utilisateurs 
durée 
2h 0 min 
delay ramp up duration
666 
6 
Montée en charge et retour à la normal 
nombre d'utilisateurs 
durée 
delay ramp up duration
676 
7 
Mesure Gatling
686 
8 
Mesures Graphite
696 
9 
Mesure GC
LES DIFFÉRENTS TYPES DE TEST 
707 
0 
• Objectif : mesurer la performance unitaire 
• Ex : le use case de souscription est...
717 
1 
! Déterminer la capacité de l’application à fonctionner sur une 
période étendue 
! Durant ce tests on va surveill...
727 
2 
Montée en charge 
nombre d'utilisateurs 
durée 
20 min 24h 
delay ramp up duration
737 
3 
DÉMO 
73 
Test d’endurance
747 
4 
Memory Leak [1/3] 
! Analyse des logs GC avec HPJMeter (ou Censum) 
! -Xloggc:gc.log -XX:+PrintTenuringDistributio...
757 
5 
! Heapdump puis Eclipse Memory Analyzer (statique) 
! Rapport sur les suspects 
Memory Leak [2/3]
767 
6 
! Visual VM (dynamique) 
Memory Leak [3/3] 
! On cherche les objets vivants avec un grand nombre de génération 
! ...
777 
7 
Résumé de la session 
Préparer les jeux de données Benerator 
Exécuter une mesure unitaire Chrome developer tools ...
787 
8 
! Tunning Système 
! Exemple Bonnie++ 
Pour aller plus loin
808 
0 
! La conférence originale à Devoxx FR 2014 : 
https://parleys.com/play/536749d1e4b04bb59f502709 
! Exemple de benc...
818 
1 
! Remerciement à Henri Tremblay, Marc Bojoly, Mickaël Robert & Ludovic Piot
828 
2 
+Jean Philippe Briend 
@jpbriend 
jpbriend@octo.com 
+Philippe Kernevez 
@pkernevez 
pkernevez@octo.com
Prochain SlideShare
Chargement dans…5
×

Université de la performance

807 vues

Publié le

L’université de la performance vous fera découvrir comment concevoir la plus grosse fonctionnalité implicite d’une application: Sa performance.

Pour cela nous vous proposerons une démarche en trois étapes: - Connaître les différents types de tests de charge et savoir quand les utiliser - Mettre en place un test de charge et des outils nécessaires pour le monitoring - Savoir identifier et optimiser les différents goulets d’étranglement de l’application

Le tout mis en pratique sur une application réelle.

Publié dans : Logiciels
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
807
Sur SlideShare
0
Issues des intégrations
0
Intégrations
4
Actions
Partages
0
Téléchargements
25
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Université de la performance

  1. 1. 1 1 Université de la Performance
  2. 2. 2 2 Présentation de l’équipe Tél : +41 21 312 94 15 www.octo.com © OCTO 2014 Avenue du théâtre 7 CH-1005 Lausanne - SUISSE
  3. 3. 3 3 Jean-Philippe Briend ! Software Architect ! Référent technique Pôle Performance ! PerfUG Paris co-leader ! Opensource commiter
  4. 4. 4 4 Philippe Kernévez ! Directeur Technique ! Référent technique pôle performance ! OSSGTP Member ! JUGLausanne co-leader ! Commiter MOJO
  5. 5. 5 5 Agenda Tél : +41 21 312 94 15 www.octo.com © OCTO 2014 Test de performance unitaire Avenue du théâtre 7 CH-1005 Lausanne - SUISSE Test de charge Test de Test de rupture vieillissement
  6. 6. 6 6 Applicatif Système
  7. 7. 7 7 Développement Production
  8. 8. 8 8 Méthodologie
  9. 9. 9 9 DÉMO
  10. 10. 101 0 DÉMO
  11. 11. 111 1 Les performances d’un système sont une spécification fonctionnelle implicite du système Notre vision ? Source : www.arthursclipart.org
  12. 12. 121 2 La mesure de performance doit être au coeur du processus de développement informatique Notre vision ? Source : Les géants du Web
  13. 13. LES 4 DIFFÉRENTS TYPES DE TEST 131 3 • Objectif : mesurer la performance unitaire • Ex : le use case de souscription est testé pour 1 utilisateur et, pour chaque étape du use case, on mesure le temps passé dans les différents composants de l’application Test de performance unitaire • Objectif : mesurer la tenue en charge de l’application sur la population cible • Ex : on simule l’utilisation de l’application par 200 utilisateurs en parallèle pendant 2h Test de charge • Objectif : déterminer les limites de l’application • Ex : on augmente le nombre d’utilisateurs en parallèle sur l’application jusqu’à ce que le taux d’erreurs / les temps de réponse ne soient plus acceptables Test de rupture • Objectif : déterminer la capacité de l’application à fonctionner sur une période étendue • Ex : on simule l’utilisation de l’application pendant 48h, avec une charge constante et égale à la charge moyenne Test de vieillissement
  14. 14. 141 4 La démarche de test que nous utilisons Global vers Local puis Local vers Global TESTS DE CHARGE TESTS DE PERFORMANCE UNITAIRE Mesurer Optimiser
  15. 15. 151 5 La démarche de test que nous utilisons TESTS DE CHARGE TESTS DE PERFORMANCE UNITAIRE Mesurer Optimiser Scénarios + Monitoring Exécution des scénarios Optimisations Estimation gains potentiels • Environnements de production • Scénarios représentatifs • Jeux de données • Cible à atteindre • Simulation • (Correction) • Mesure • Investigations • Sur un poste de développement • Validation des hypothèses • Tuning des « hot spots »
  16. 16. 161 6 Définition du plan et des cas de test Méthodologie d’un test de charge Plan de test Cas de test Création des scénarii et des scripts de tests Enregistrement des métriques Consolidation des métriques et édition d’un rapport de test Métriques Rapport de test Analyse du rapport de test et émission des préconisations Rapport d’analyse Contrôleur Scripts de test Scénarii de test Application à tester Injecteurs Données de test Création des jeux de données 1 2 3 3 Monitoring 3 Exécution 4 5 2
  17. 17. 171 7 Les outils utilisés aujourd’hui GÉNÉRER LES DONNÉES ! Migrer les données depuis la production mais il faut souvent l’anonymiser. ! Générer un jeux de données mais il doit être représentatif ! Rétablir le jeux de données dans son état initial une fois le tir effectué TESTER EN CHARGE ! Enregistrer et rejouer de manière fidèle un ensemble d’actions utilisateurs. ! Variabiliser ces actions utilisateurs pour être représentatif de l’usage réel ! Simuler un grand nombre d’utilisateurs MONITORER LA CONSOMMATION DE RESSOURCES ! Identifier les ressources en quantité limitante ! Identifier les impacts sur les différentes machines lorsque l’application est distribuée ! Corréler l’évolution des temps de réponse et les consommations de ressources sur les différentes machines
  18. 18. 181 8 Les outils en général HPJMeter Analyse de log GC Injection Profiling APM
  19. 19. 191 9 Notre fil rouge : Happy Store Navigateur Tomcat PgSQL Une application comme on en rencontre souvent, pas très loin de l’état de l’art.. Sauf pour les performances !
  20. 20. 202 0 Architecture APPLICATION SERVER DATABASE SERVER Tomcat JVM PostgreSQL
  21. 21. 212 1 Modèle de base de données Store 0,n 1 Stock Category Family Product Sales Operation VAT Country Sales Transaction 1 0,n 0,n 0,n 0,n 1 0,n 1 0,n 1 1 1,n 1 0,n
  22. 22. 222 2 Acheter des produits
  23. 23. 232 3 Finaliser sa commande Total
  24. 24. 242 4 Calcul de l’inventaire sur un magasin Inventory
  25. 25. 252 5 Calcul du chiffre d’affaire par groupe de produits Turnover (group by+order by)
  26. 26. 262 6 Cible de performance ! Cible : 100 utilisateurs concurrents ! Volumétrie de la base de données : 13 millions de lignes Store 0,n 1 Stock 10'000'000 1'000 1'000 Category Family Product Sales Operation VAT Country Sales Transaction 1 0,n 0,n 0,n 0,n 1 0,n 1 0,n 1 1 1,n 1 0,n 260 1'000 10'000 3'000'000 0
  27. 27. LES DIFFÉRENTS TYPES DE TEST 272 7 • Objectif : mesurer la performance unitaire • Ex : le use case de souscription est testé pour 1 utilisateur et, pour chaque étape du use case, on mesure le temps passé dans les différents composants de l’application Test de performance unitaire • Objectif : mesurer la tenue en charge de l’application sur la population cible • Ex : on simule l’utilisation de l’application par 200 utilisateurs en parallèle pendant 2h Test de charge • Objectif : déterminer les limites de l’application • Ex : on augmente le nombre d’utilisateurs en parallèle sur l’application jusqu’à ce que le taux d’erreurs / les temps de réponse ne soient plus acceptables Test de rupture • Objectif : déterminer la capacité de l’application à fonctionner sur une période étendue • Ex : on simule l’utilisation de l’application pendant 48h, avec une charge constante et égale à la charge moyenne Test de vieillissement
  28. 28. 282 8 DÉMO 28 Exécution test unitaire
  29. 29. 292 9 Que fais le serveur applicatif pendant ce temps ? ! Identifier la JVM ! Faire un threadump pendant la requête
  30. 30. 303 0 ! C’est le seul à exécuter du code applicatif Identifier notre Thread ! Il attend la base… mais quelle est la requête ?
  31. 31. 313 1 ! Vérification de la configuration des traces ! Les requêtes de plus de 700ms sont tracées ! On obtient la requête et ses paramètres d’appel Allons voir la DB
  32. 32. 323 2 Pourquoi cette requête est lente ? select sum(amount), …. from SaleOperation where groupId=1 and operationdate >= '2010-04-15 00:21:31.529' group by saleoperation.currency order by sum(saleoperation.amount) desc; ! Demandons au moteur du SGBD… ! Un index pourrait aider à mieux filtrer les lignes…
  33. 33. 333 3 DÉMO 33 Exécution test unitaire
  34. 34. 343 4 Remplissage des données : Benerator ! Principes : la base de données est alimentées avec 2 sources ! Une (petite) partie des données est maitrisée ! Généralement le jeux de données utilisés pour les tests d’intégration ! Cohérent avec les scripts d’injection (permet de faire des assertions) ! Une (grosse) partie des données est générée aléatoirement xxx xxx Store 0,n 1 Stock 10'000'000 4 16 4 4 1'000 1'000 Category Family Product Sales Operation VAT Country Sales Transaction 1 0,n 0,n 0,n 0,n 1 0,n 1 0,n 1 1 1,n 1 0,n 260 1'000 10'000 3'000'000 0 260 256 1 2
  35. 35. 353 5 Configuration Benerator
  36. 36. 363 6 ! Temps de création de happystore è 1h20 ! 8 tables / 13 M de lignes ! (un thread sur MB avec VM) ! Temps de rechargement è 25 min Temps de génération
  37. 37. LES DIFFÉRENTS TYPES DE TEST 383 8 • Objectif : mesurer la performance unitaire • Ex : le use case de souscription est testé pour 1 utilisateur et, pour chaque étape du use case, on mesure le temps passé dans les différents composants de l’application Test de performance unitaire • Objectif : mesurer la tenue en charge de l’application sur la population cible • Ex : on simule l’utilisation de l’application par 200 utilisateurs en parallèle pendant 2h Test de charge • Objectif : déterminer les limites de l’application • Ex : on augmente le nombre d’utilisateurs en parallèle sur l’application jusqu’à ce que le taux d’erreurs / les temps de réponse ne soient plus acceptables Test de rupture • Objectif : déterminer la capacité de l’application à fonctionner sur une période étendue • Ex : on simule l’utilisation de l’application pendant 48h, avec une charge constante et égale à la charge moyenne Test de vieillissement
  38. 38. 393 9 Architecture LOCAL SERVER APPLICATION SERVER DATABASE SERVER Gatling Tomcat JVM PostgreSQL
  39. 39. 404 0 Gatling - Recorder
  40. 40. 414 1 Gatling – DSL Scala URL + header http page1 page2 Nb utilisateurs + durée
  41. 41. 424 2 Montée en charge nombre d'utilisateurs durée 20 min 2h delay ramp up duration
  42. 42. 434 3 Exécution Gatling
  43. 43. 444 4 Résultats Gatling
  44. 44. 454 5
  45. 45. 474 7 Premature optimization is the root of all evil - Donald Knuth
  46. 46. 484 8 Il voulait dire ça: // Do not use the for(Object o : list) // because I think it is probably // slower than doing this… Probably… for(int i = 0; i < list.size(); i++) { Object o = list.get(i); … } Stop guessing damn it!!!
  47. 47. 494 9 Code Mesure Optimise Là où c’est important
  48. 48. 505 0 DÉMO 50 Visual VM
  49. 49. 515 1 Architecture TOOL SERVER APPLICATION SERVER Collectd DATABASE SERVER CI STACK Jenkins GRAPHITE STACK Gatling Maven Graphite Git Whisper Carbon Collectd PostgreSQL JVM Tomcat
  50. 50. 525 2 DÉMO 52 Graphite & Metrics
  51. 51. 535 3 Un exemple d’outil d’APM du marché : AppDynamics
  52. 52. 545 4
  53. 53. 555 5 Développement Production Architecture Perf.
  54. 54. 565 6 3. Développement 2. Automatisation Architecture Développement Perf. 1. Conception des tests des tests logiciel 4. Exécution auto-matique des tests #1 #2 #3
  55. 55. 575 7 3. Développement 2. Automatisation des tests #1 #2 #3 Délai Perf. PERFORMANCES CATASTROPHIQUES MEP À L’ARRACHE logiciel 4. Exécution auto-matique des tests 1. Conception des tests Développement Architecture Résultats Production
  56. 56. 585 8 3. Développement 2. Automatisation 1. Conception des tests des tests logiciel 4. Exécution auto-matique des tests #1 #2 #3 Architecture Développement Production Tests de charge en continue
  57. 57. 595 9 Intégrer les tests de performances au cycle de développement? Hyperviseur AppServer Chef DbServer Chef 1 2 3 Créer environnement Tir de performance Destruction environnement
  58. 58. 626 2 DÉMO 62 Automatisation des tests
  59. 59. LES DIFFÉRENTS TYPES DE TEST 636 3 • Objectif : mesurer la performance unitaire • Ex : le use case de souscription est testé pour 1 utilisateur et, pour chaque étape du use case, on mesure le temps passé dans les différents composants de l’application Test de performance unitaire • Objectif : mesurer la tenue en charge de l’application sur la population cible • Ex : on simule l’utilisation de l’application par 200 utilisateurs en parallèle pendant 2h Test de charge • Objectif : déterminer les limites de l’application • Ex : on augmente le nombre d’utilisateurs en parallèle sur l’application jusqu’à ce que le taux d’erreurs / les temps de réponse ne soient plus acceptables Test de rupture • Objectif : déterminer la capacité de l’application à fonctionner sur une période étendue • Ex : on simule l’utilisation de l’application pendant 48h, avec une charge constante et égale à la charge moyenne Test de vieillissement
  60. 60. 646 4 Test de rupture 100 requêtes par secondes nombre d'utilisateurs
  61. 61. 656 5 Montée en charge nombre d'utilisateurs durée 2h 0 min delay ramp up duration
  62. 62. 666 6 Montée en charge et retour à la normal nombre d'utilisateurs durée delay ramp up duration
  63. 63. 676 7 Mesure Gatling
  64. 64. 686 8 Mesures Graphite
  65. 65. 696 9 Mesure GC
  66. 66. LES DIFFÉRENTS TYPES DE TEST 707 0 • Objectif : mesurer la performance unitaire • Ex : le use case de souscription est testé pour 1 utilisateur et, pour chaque étape du use case, on mesure le temps passé dans les différents composants de l’application Test de performance unitaire • Objectif : mesurer la tenue en charge de l’application sur la population cible • Ex : on simule l’utilisation de l’application par 200 utilisateurs en parallèle pendant 2h Test de charge • Objectif : déterminer les limites de l’application • Ex : on augmente le nombre d’utilisateurs en parallèle sur l’application jusqu’à ce que le taux d’erreurs / les temps de réponse ne soient plus acceptables Test de rupture • Objectif : déterminer la capacité de l’application à fonctionner sur une période étendue • Ex : on simule l’utilisation de l’application pendant 48h, avec une charge constante et égale à la charge moyenne Test de vieillissement
  67. 67. 717 1 ! Déterminer la capacité de l’application à fonctionner sur une période étendue ! Durant ce tests on va surveiller les dérives au cours du temps : ! Temps de réponse ! Consommation de ressource (espace disk, CPU, mémoire, etc.) ! Libération des ressources (connexions, file, etc.) ! Mémoire Objectif
  68. 68. 727 2 Montée en charge nombre d'utilisateurs durée 20 min 24h delay ramp up duration
  69. 69. 737 3 DÉMO 73 Test d’endurance
  70. 70. 747 4 Memory Leak [1/3] ! Analyse des logs GC avec HPJMeter (ou Censum) ! -Xloggc:gc.log -XX:+PrintTenuringDistribution -XX:+PrintGCDetails
  71. 71. 757 5 ! Heapdump puis Eclipse Memory Analyzer (statique) ! Rapport sur les suspects Memory Leak [2/3]
  72. 72. 767 6 ! Visual VM (dynamique) Memory Leak [3/3] ! On cherche les objets vivants avec un grand nombre de génération ! Jdk 8+ pour les JVM remote
  73. 73. 777 7 Résumé de la session Préparer les jeux de données Benerator Exécuter une mesure unitaire Chrome developer tools Identifier un problème d’index jstack, explain plan Exécuter des tests de charge Gatling Automatisation des tests de charge Jenkins, Capistrano, Chef Problème de contention VisualVM, jstack Mise en place du monitoring Metrics, collectd et Graphite Identifier une fuite mémoire VisualVM, EMA, HPJMeter Tuning système Bonnie++
  74. 74. 787 8 ! Tunning Système ! Exemple Bonnie++ Pour aller plus loin
  75. 75. 808 0 ! La conférence originale à Devoxx FR 2014 : https://parleys.com/play/536749d1e4b04bb59f502709 ! Exemple de benchmark: http://blog.octo.com/lart-du-benchmark/ ! Conférence sur l’industrialisation (USI 2013): https://www.youtube.com/watch?v=BXO3LYQ9Vic ! Tests de performance SQLFire: http://blog.octo.com/en/sqlfire-from-the-trenches/ Liens utiles
  76. 76. 818 1 ! Remerciement à Henri Tremblay, Marc Bojoly, Mickaël Robert & Ludovic Piot
  77. 77. 828 2 +Jean Philippe Briend @jpbriend jpbriend@octo.com +Philippe Kernevez @pkernevez pkernevez@octo.com

×