Forum: Rails France 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 :-)

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 ;-)
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 Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse 
railsfrance@googlegroups.com
Pour résilier votre abonnement envoyez un e-mail à l'adresse 
railsfrance-unsubscribe@googlegroups.com

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).

Sam@Work.

--
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de 
Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse 
railsfrance@googlegroups.com
Pour résilier votre abonnement envoyez un e-mail à l'adresse 
railsfrance-unsubscribe@googlegroups.com

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, Sam@Work a écrit :

> 
> -- 
> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups.
> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@googlegroups.com
> Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscribe@googlegroups.com
> 
> 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 Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse 
railsfrance@googlegroups.com
Pour résilier votre abonnement envoyez un e-mail à l'adresse 
railsfrance-unsubscribe@googlegroups.com

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 Decaux 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 ;-)

--
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de 
Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse 
railsfrance@googlegroups.com
Pour résilier votre abonnement envoyez un e-mail à l'adresse 
railsfrance-unsubscribe@googlegroups.com

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, Sam@Work 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 ;-)
> 
> -- 
> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups.
> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@googlegroups.com
> Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscribe@googlegroups.com
> 
> 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 Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse 
railsfrance@googlegroups.com
Pour résilier votre abonnement envoyez un e-mail à l'adresse 
railsfrance-unsubscribe@googlegroups.com

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 Sam@Work <s.gay@adhoc-software.com>

> 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 ;-) 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.



> Sam@Work.


Merci de ton retour

NG

--
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" 
de Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse 
railsfrance@googlegroups.com
Pour résilier votre abonnement envoyez un e-mail à l'adresse 
railsfrance-unsubscribe@googlegroups.com

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 Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse 
railsfrance@googlegroups.com
Pour résilier votre abonnement envoyez un e-mail à l'adresse 
railsfrance-unsubscribe@googlegroups.com

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