Retour d'expérience sur un serveur rails en ARM

Bonjour je pense que cela ne va pas être d’un grand intérêt pour tous
mais
cela peut servir.

Dans le cadre d’un déploiement d’un intranet avec une contrainte forte
en
basse consommation j’ai eu l’idée d’une machine arm en client mais aussi
en
serveur sachant que les performances des dernières puces sont plus
qu’honorables en rapport puissance/conso et que les distrib linux que je
comptais utiliser, ubuntu/debian, tournent bien dessus avec un bon
support.

Il y avait le choix entre le efika MX de genesi et le open-rd de
globalscale
(j’ai laissé tombé les plug computer de type sheeva etc.)
j’ai opté pour des clients et un serveur efika mx.

Sur les clients une installation minimale de xfce avec arora (webkit)
comme
navigateur
Sur le serveur une karmic préinstallée sur une carte SDHC classe 10 sur
laquelle j’ai installé nginx et thin et mysql.

l’application est relativement simple avec une bonne dose d’ajax, pas
forcément bien optimisée (voire codée avec les pieds - je suis codeur
amateur sur mon temps libre - ), je l’ai testée avec une base de 6000
dossiers et de 20 tables.
ah oui pas de tests :slight_smile:

elle est démarrée en mode development (problème avec le mode production
pour
le moment) avec thin sur une base mysql 5

Globalement pour une telle application les résultats ne sont pas trop
probants côté performance avec un temps de latence qui est important de
l’ordre de 4-5 secondes dans le pire des cas, dans le cadre de pages un
peu
lourdes (recherches croisées sur plusieurs tables, même si je suis sûr
que
du refactoring de code peut bien améliorer les choses), une charge du
serveur thin à 80-99% sur ces mêmes grosses requêtes. Le tout avec un
seul
utilisateur alors que l’application est censée servir pour 4-8+
personnes.
L’application tourne actuellement sur un “serveur” pentium celeron d430
Ã
1.8 et 2Go de RAM avec de très bonnes performances pour un groupe de
travail
de 7 personnes.

J’ai testé avec des applications plus légères (gestion carnet d’adresse,
todo list etc.) et là par contre c’est beaucoup mieux avec des
performances
très acceptables.
Je compte tester Oupsnow mais la compilation de mongodb sur arm plante Ã
un
moment.

Niveau consommation j’arrive à une consommation serveur de 10-12 W en
pleine
charge et 5-7 en idle (carte SD comprise) c’est assez impressionnant.

En conclusion pour une utilisation un peu importante c’est, sans
surprise,
sous dimensionné; par contre comme serveur sur des petits projets peu
exigeants en ressources je trouve que c’est une bonne plateforme.

Voilà un petit retour sur expérience rapide :wink:
si cela peut servir ou donner des idées

NG


Vous avez reçu ce message, car vous êtes abonné au groupe “Railsfrance”
de Google G…
Pour transmettre des messages à ce groupe, envoyez un e-mail à l’adresse
[email protected]
Pour résilier votre abonnement envoyez un e-mail à l’adresse
[email protected]

To unsubscribe from this group, send email to
railsfrance+unsubscribegooglegroups.com or reply to this email with the
words “REMOVE ME” as the subject.

Tout retour d’expérience à de l’intérêt.

elle est démarrée en mode development (problème avec le mode production
pour le moment) avec thin sur une base mysql 5

Ca c’est un énorme handicap, surtout avec un CPU mou du genou. Entre la
config de dev et celle de prod les performances changent énormément.
Bref, une fois ton problème réglé, les résultats pourraient changer très
significativement.

Par ailleurs une une carte SHDC, ça n’est peut-être pas l’idéal non
plus. Un petit SSD à la place ne serait-il pas plus efficace (avec sa
mémoire cache, etc…) ? A défaut, assez de RAM pour avoir presque toute
la base en mémoire (lecture rapide, mais écritures toujours lentes).

[email protected]


Vous avez reçu ce message, car vous êtes abonné au groupe “Railsfrance” de
Google G…
Pour transmettre des messages à ce groupe, envoyez un e-mail à l’adresse
[email protected]
Pour résilier votre abonnement envoyez un e-mail à l’adresse
[email protected]

To unsubscribe from this group, send email to
railsfrance+unsubscribegooglegroups.com or reply to this email with the
words “REMOVE ME” as the subject.

Bonjour Sam,
Excusez-moi de m’immiscer dans la conversation, mais que veux tu dire
à propos des différences de performances entre une config de dev et une de
prod.

Je suis assez néophite sur RoR. Peux-tu me pointer vers des articles/infos
sur le sujet.

Merci d’avance
Christophe

Le 24 mars 2010 à 09:34, [email protected] a écrit :


Vous avez reçu ce message, car vous êtes abonné au groupe “Railsfrance” de Google G…
Pour transmettre des messages à ce groupe, envoyez un e-mail à l’adresse [email protected]
Pour résilier votre abonnement envoyez un e-mail à l’adresse [email protected]

To unsubscribe from this group, send email to railsfrance+unsubscribegooglegroups.com or reply to this email with the words “REMOVE ME” as the subject.


Vous avez reçu ce message, car vous êtes abonné au groupe “Railsfrance” de
Google G…
Pour transmettre des messages à ce groupe, envoyez un e-mail à l’adresse
[email protected]
Pour résilier votre abonnement envoyez un e-mail à l’adresse
[email protected]

To unsubscribe from this group, send email to
railsfrance+unsubscribegooglegroups.com or reply to this email with the
words “REMOVE ME” as the subject.

Le 24/03/2010 10:06, Christophe D. a écrit :

Bonjour Sam,
Excusez-moi de m’immiscer dans la conversation, mais que veux tu dire à propos des différences de performances entre une config de dev et une de prod.

Je suis assez néophite sur RoR. Peux-tu me pointer vers des articles/infos sur le sujet.

En config de dev, une partie importante du code est rechargé a chaque
requête. Or lire le fichier + “parser” le code Ruby c’est couteux.
L’objectif étant tout simplement de prendre en compte les modification
effectuées dans le code et de pouvoir tester sans avoir à redémarrer le
processus serveur à chaque fois.

En config de prod, le code est lu une fois pour toute. Pas d’un seul
coup (au fur et à mesure que c’est utile), mais un fichier de code
donné ne sera traité qu’une seule fois. Une fois une classe ou une
module en mémoire, c’est acquis.

La config de dev est donc fortement gourmande en CPU.

Il y a d’autres différences comme le contenu des fichiers de traces par
exemple. Je n’ai pas de lien précis à donner dans l’immédiat, désolé.
Mais ça se trouve facilement à mon avis :wink:


Vous avez reçu ce message, car vous êtes abonné au groupe “Railsfrance” de
Google G…
Pour transmettre des messages à ce groupe, envoyez un e-mail à l’adresse
[email protected]
Pour résilier votre abonnement envoyez un e-mail à l’adresse
[email protected]

To unsubscribe from this group, send email to
railsfrance+unsubscribegooglegroups.com or reply to this email with the
words “REMOVE ME” as the subject.

2010/3/24 [email protected] [email protected]

significativement.

Je le pensais mais si les différences sont si importantes que cela c’est
en
effet à tester

Par ailleurs une une carte SHDC, ça n’est peut-être pas l’idéal non plus.
Un petit SSD à la place ne serait-il pas plus efficace (avec sa mémoire
cache, etc…) ? A défaut, assez de RAM pour avoir presque toute la base en
mémoire (lecture rapide, mais écritures toujours lentes).

Un SSD en effet via le port usb2, en effet mais du coup on est dans le
coût
un peu élevé pour un test :wink: même si on en trouve à 40 Go avec de
bonnes
performances. C’est surtout la lecture qui dans l’appli est invalidante.
Le problème de la ram sur ces machines c’est qu’elle est soudée à la
carte
mère et pour le moment on est au max à 512 Mo, ce qui est déjà pas mal.

[email protected]

Merci de ton retour

NG


Vous avez reçu ce message, car vous êtes abonné au groupe “Railsfrance”
de Google G…
Pour transmettre des messages à ce groupe, envoyez un e-mail à l’adresse
[email protected]
Pour résilier votre abonnement envoyez un e-mail à l’adresse
[email protected]

To unsubscribe from this group, send email to
railsfrance+unsubscribegooglegroups.com or reply to this email with the
words “REMOVE ME” as the subject.

Merci,
C’est un excellent début.

Le 24 mars 2010 à 10:33, [email protected] a écrit :

La config de dev est donc fortement gourmande en CPU.

Il y a d’autres différences comme le contenu des fichiers de traces par exemple. Je n’ai pas de lien précis à donner dans l’immédiat, désolé. Mais ça se trouve facilement à mon avis :wink:


Vous avez reçu ce message, car vous êtes abonné au groupe “Railsfrance” de Google G…
Pour transmettre des messages à ce groupe, envoyez un e-mail à l’adresse [email protected]
Pour résilier votre abonnement envoyez un e-mail à l’adresse [email protected]

To unsubscribe from this group, send email to railsfrance+unsubscribegooglegroups.com or reply to this email with the words “REMOVE ME” as the subject.


Vous avez reçu ce message, car vous êtes abonné au groupe “Railsfrance” de
Google G…
Pour transmettre des messages à ce groupe, envoyez un e-mail à l’adresse
[email protected]
Pour résilier votre abonnement envoyez un e-mail à l’adresse
[email protected]

To unsubscribe from this group, send email to
railsfrance+unsubscribegooglegroups.com or reply to this email with the
words “REMOVE ME” as the subject.

Je le pensais mais si les différences sont si importantes que cela c’est en
effet à tester

Je confirme que c’est déterminant au niveau perf. Rails est un serveur
d’application, le mode dev recharge tout le code à chaque requête
(facon php), c’est pratique quand on modifie le code en dev mais en
terme de performance c’est complètement pourri surtout sur des grosses
applis.

Il n’y a aucune raison que ca ne tourne pas en mode production (c’est
plus simple) donc c’est sans doute un micro problème genre la
configuration de la base de donnée manquante ou un fichier
environnement production.rb incorrect. Ca ne change rien au niveau de
thin.

Tu peux tester déjà en mode development avec config.cache_classes =
true, c’est l’élément le plus important (hors cache manuel ce qui ne
te concerne sans doute pas).


Vous avez reçu ce message, car vous êtes abonné au groupe “Railsfrance” de
Google G…
Pour transmettre des messages à ce groupe, envoyez un e-mail à l’adresse
[email protected]
Pour résilier votre abonnement envoyez un e-mail à l’adresse
[email protected]

To unsubscribe from this group, send email to
railsfrance+unsubscribegooglegroups.com or reply to this email with the
words “REMOVE ME” as the subject.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs