URL: https://linuxfr.org/users/yboy360/journaux/essai-serveur-arm-chez-cloud-online-net Title: Essai serveur ARM chez cloud.online.net Authors: YBoy360 Date: 2015年04月07日T12:49:40+02:00 License: CC By-SA Tags: arm, ma_vie, grails, spring, libreoffice, ubuntu et fedora Score: 18 Il y a quelques jours, nous avons été invité à tester la futur offre de serveur basé sur des processeurs ARM sur le site cloud.online.net. Ces serveurs disposent de 2 Gio de ram, 20 Gio d’espace disque sur SSD, ils ne sont pas virtualisés, et disposent d'un SoC ARM V7 a 4 coeurs (ARMv7 Processor rev 2 (v7l) / Marvell Armada 370/XP pour les intimes). Les applications que nous avons testées sont des applications d'entreprise classique, c.a.d. ayant peu d'utilisateur, mais faisant des choses plutôt lourd et très diverses. Nous utilisons le framework grails, en version 2.4.3 et 2.5.0. Nous avons constaté un gains de 10 pour cent au démarrage avec la version 2.5.0, par rapport à la précédente, rien qu’avec le passage à Groovy 2.4.1 et la version 3 devrait apporter d'importants gains supplémentaires. Grails, c'est RoR (Rubis on Rails), mais basé sur Spring. Spring va gérer la durée de vie des objets de votre application (contrôleur, services, beans), en les injectants par inversion de dépendance. Spring va également offrir de nombreux composants. Grails va ajouter un ORM basé sur Hibernate, ainsi qu'une grande facilité d'utilisation grâce à Groovy, et a un ensemble de conventions pour simplifier la configuration (convention over configuration). Les plugins/composants que nous utilisons: - Spring security, - Spring webflow, - **[BiRT](http://eclipse.org/birt/)** Projet Eclipse Business Intelligence Reporting Tool, permet de générer du xls, ods et de très simplement faire des rapports - Solr et Tika pour l’indexation des fichiers / objets métiers - **LibreOffice** et ImageMagick pour la génération des thumbnail pour les fichiers uploadés. - postgres extention pour pouvoir utiliser les maps, les tableaux, jsond, nativement dans postgres - Quartz pour la planification des jobs "applicatifs" (mailing, tâches de synchronisation). - Protobuff pour la communication avec CRM Android Nous utilisons Postgres, avec un plugin de datamining [Madlib](http://madlib.net/). Il y a 2 instances de base de données, l'une pour les applications, l'autre pour les statistiques/datamining. Les stats sont synchronisées avec les différents ERP des filiales tous les jours, via l'**[ETL Kettle](http://community.pentaho.com/projects/data-integration/)** (une merveille, libre en plus). Sans rentrer dans les détails, tous les ERP sont évidemment différents, et ne sont pas tous basée sur une base SQL... Pour planifier le tout, on utilise [Rundeck](http://rundeck.org/) / ssh. ça fonctionne un peu comme Ansible, c.a.d. qu’il n y a aucune dépendance ou d'agent installée sur les serveurs où les tâches son planifiée, hormis ssh. Les applications que nous développons: CRM, EDI, Qualité, BI, plus la gestion d’utilisateur, de projet et l’upload des données sur les sites web (FR, US, CN, DE)... Voila pour l’aspect applicatif, ce que l’on peut dire, c’est que nous avons pas mal de composant lourds, de plus, si nous utilisons une architecture en plugin pour ranger ce qu’il y a de commun entre les applications, chaque instance d’application utilise son propre espace (mémoire, poll de connexion, cache), l’occupation mémoire est importante, mais on peut faire ce que l’on veut, presque simplement, et le tout tourne bien sur un serveur moyen gamme, avec une grande souplesse et robustesse pour une soixantaine d'utilisateur dans le monde. Les résultats des essais =========== L’interface d’administration est très simple, les machines s’installe en une poignée de secondes, ça pourra gêner les bidouilleurs, mais il est possible de gérer sa propre image. En un ou 2 cliques, l’on peut instancier une nouvelle machine avec l’image de son choix, accéder au données et l’administrer. La plate-forme semble très réactive, j’ai utilisé une Ubuntu sans SystemD (j’aurais aimé une Fedora ou autres avec SystemD). On ne sent pas que l’on est sur un CPU de téléphone portable à l’usage, je suis persuadé que les applications PHP vont très bien tourné, Ubuntu/Debian semble avoir fait du bon boulot pour l’optimisation de leur distribution sur cette architecture, mais comment mon application va t-elle fonctionner? Après avoir fait de nombreux tests sur Raspberry Pi, je m’attendais à ce que le tout fonctionne, mais vraiment très lentement, avec de nombreux blocage, mais le Raspberry Pi avec ces 512 Mo est vraiment trop juste. Ce qu’il faut savoir avant de lancer son Tomcat, c’est que l’on doit impérativement utiliser la version Java d’Oracle, car elle dispose du [c2 compiler](https://blogs.oracle.com/jtc/entry/comparing_jvms_on_arm_linux) sur ARM v7, ce qui n’est pas le cas de l’OpenJDK. OpenJDK disposera du C2 compiler avec le jeu d’instruction ARM v8 (64-bit). Ça fonctionne avec l’OpenJDK, mais c’est vraiment hyper lent. Concrètement, on démarre tomcat très simplement ainsi export JAVA_OPTS=" -Xms512m -Xmx1512m -server " et c’est tout.. En gros on dispose de 1,5 Gio pour les allocations. Comme il ne reste plus grand chose pour postgres et solr, je les démarre avec les options par défaut. Conclusion ========== Que dire? c’est a peu près 3 ou 4 fois plus lent que mon serveur Xeon à dd non SSD. C’est un exploit! Les applications sont largement utilisables (hors des stats si trop grosse requête). Alors que ces CPU sont réfléchis pour supporter un type de charge horizontal (peu de traitement par requête avec plein de requête), j’ai pu faire fonctionner ma stack logiciel complète, sur une sur une seul machine, sans aucune difficulté. Pourquoi est-ce un exploit alors que c’est 4 fois plus lent? parce que les développeurs de compilateur, de java et autres optimisent leur code pour Intel depuis des décennies, en réalisant toutes sortes de micro optimisation favorisant Intel, il y a une personne qui travaille sur le C2 compiler pour ARM v7 chez Oracle... De plus, Linux sur ARM est très agréable à l’usage, autant que sur Intel, il y a quasiment tout ce qu’il y a sur Intel, et le potentiel d’ARM me semble plus prometteur que celui d’Intel à long terme.

AltStyle によって変換されたページ (->オリジナル) /