|
|
Par Geoffray GRUEL, le Jeudi 3 janvier 2008 Bonjour et bonne année 2008 à tous, Pour bien commencer l’année Ippon Technologies vient de signer un accord de partenariat avec MuleSource, société qui supporte le projet d’ESB opensource Mule. Pourquoi Mule et pas un autre ESB ?
- Nos consultants utilisent Mule depuis maintenant presque 2 ans. D’abord en tant que bus d’intégration et de transformation (EAI) puis plus récemment en tant qu’ESB (Processus métiers,…),
- Nos consultants ont pu évaluer la robustesse de la solution en production et y apporter de précieuses contributions,
- Mule se présente à notre avis comme l’ESB opensource de référence en 2008 tant au niveau du nombre de contributeurs que de références actives.
Pourquoi un partenariat avec MuleSource ?
- Pour fournir une infrastructure SOA “Best of breed” complète en opensource avec Portail, ESB et BPM (Liferay + Mule + jBPM),
- Pour répondre au besoin des grands comptes, éditeurs et administrations de disposer de services professionels complets autour de l’ESB Mule (Formation, conseil, support, réalisation),
- Pour capitaliser au sein d’Ippon Technologies une expertise ESB opensource comme nous l’avons fait sur le portail avec Liferay.
Je vous donne rendez-vous très prochainement pour les premières dates de formation en France animées directement par les consultants de Mule. Merci à MuleSource pour sa confiance qui vient renforcer le poistionnement “Expert J2EE, Portail et SOA” d’Ippon Technologies. A ceux qui nous reprocherons de perdre une quelconque neutralité en signant ce type de partenariat je répondrai simplement qu’on ne peut être expert en remplissant des grilles d’évaluation et que finalement seule la mise en production de solutions robustes intéresse nos clients. Bonne année ESB à tous. . . . → Lire la suite: Ippon Technologies partenaire de MuleSource
Par Freddy HATTE, le Jeudi 3 janvier 2008 Les performances d’une application J2EE deviennent de plus en plus une exigence naturelle quand elle n’est pas contractuelle. Architectes, développeurs, experts DBA doivent collaborer dès le début du projet. Des recherches multicritères, des bases de données de quelques dizaines de Giga deviennent courantes… Une fois livrée, une nouvelle application J2EE fonctionne très bien avec une fluidité souvent seulement limitée par la bande passante réseau ou internet….mais après quelques jours, semaines et mois de mise en production, elle peut montrer des signes de ralentissement pouvant devenir très gênant et voire bloquant. L’optimisation de la structure de la base de données devient très vite inévitable, durant des tests de charge et tests IHM (LoadRunner, Jmeter, OpenSTA), on observe via OEM ou la dbconsole (ci dessous), Tkprof pour les experts, l’ensemble de transactions… Le module performance de la console ORACLE (dbconsole) dresse rapidement les requêtes les plus utilisés et permet d’observer en – de 2 minutes les plans d’exécutions des requêtes à optimiser. Eviter les FULL SCAN de table par exemple, une simple requête prend quelques millisecondes sur une table de 100 enregistrements alors qu’elle prendra beaucoup plus de temps lorsqu’elle atteindra des milliers, des millions d’enregistrements. Les tests de charge, aux limites, d’endurance ou encore de stress effectués après un vieillissement accéléré de l’application remontent ces bottlenecks qu’il faudra solutionner avant mise en production. Améliorer sa base de données : Quelques points à vérifier.
- Indexation (optimisation des select mais ralenti les insert, delete, update)
- Statistiques (exécution régulière voire quotidienne)
- Paramètres internes : SGA, PGA, LOG Buffer, cache…. (Variables aussi importantes que la taille d’une machine virtuelle java JVM)
- Partitionnement, multithread, Pool JDBC, tablespaces, deadlock, …
Liens vers de bonnes pratiques :
Ce billet résume un retour d’expérience d’une application J2EE dont les performances métiers ont été multiplié par plus de 80 ! . . . → Lire la suite: Performance : x1 x2 …x5..10..20..50…x100 !
|
|