Forum: Rails France RoR sur un kimsufi

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
C211e4b403330c86c56db30357a2b64c?d=identicon&s=25 Guillaume Betous (Guest)
on 2007-03-09 08:43
(Received via mailing list)
Salut !

J'avais posté le week-end dernier sur le forum, mais vu que mes messages
ne sont
toujours pas apparus sur la ML, je rebalance.

J'ai tenté l'expérience de louer un kimsufi [1] pour y faire tourner
Rails...
c'est plutot un bide.

Hier j'ai tenté tout simplement de faire tourner Mongrel, tout seul, sur
une
application toute con. Le serveuer à commencé à swapper rapidement, c'était
quasi inutilisable... 3 ou 4 secondes pour accéder à chaque page !!!

Mon appli n'est pas grosse, je compte pas avoir 1000 requetes par
seconde, donc
je pensais qu'un petit serveur dans le style suffirait. C'est
apparemment faux.

Avant d'abandonner définitivement la solution kimsufi, y a-t-il un moyen
de
servir du Rails qui utiliserait moins de RAM ?
Au passage, j'utilise sqlite3, pensant que ça prend moins de ressources
que
mySQL par exemple.

Merci !

gUI

[1] http://www.kimsufi.com

--
Guillaume Betous : (05 61) 19 40 65 / bureau 602N
C211e4b403330c86c56db30357a2b64c?d=identicon&s=25 Guillaume Betous (Guest)
on 2007-03-09 09:45
(Received via mailing list)
> Hier j'ai tenté tout simplement de faire tourner Mongrel, tout seul, sur
> une application toute con. Le serveuer à commencé à swapper rapidement,
> c'était quasi inutilisable... 3 ou 4 secondes pour accéder à chaque page
> !!!

Bon, en fait j'avais pas que ça... J'avais mis apache, et en plus il y
avait
postfix ainsi que bind. j'ai tout viré (-:

Le meme test est déjà franchement plus satisfaisant, vu j'ai l'occupation
memoire suivante :

free -m
              total       used       free     shared    buffers
cached
Mem:           217         56        160          0          3
15
-/+ buffers/cache:         37        179
Swap:          509          0        509

gUI

--
Guillaume Betous : (05 61) 19 40 65 / bureau 602N
91eb330fb36d1e03c856574dfb77d2bc?d=identicon&s=25 Thibaut Barrère (thbar)
on 2007-03-09 10:10
(Received via mailing list)
Bonjour Guillaume

je te propose de jeter un oeil à LiteSpeed (gratuit en version
standard), à
utiliser avec LSAPI, sans mongrel (tu peux aussi l'utiliser avec
mongrel).
L'utilisation mémoire est plus légère qu'Apache (note toutefois que j'ai
toujours plein de RAM sur mes serveurs, donc je n'ai pas testé moi même
l'aspect 'small memory footprint'!). Robuste et facile d'emploi.

http://www.mathewabonyi.com/articles/2006/10/28/li...

http://litespeedtech.com/

a+

Thibaut Barrère
--
LoGeek
[mail] thibaut.barrere@gmail.com
[blog] http://www.dotnetguru2.org/tbarrere


Le 09/03/07, Guillaume Betous
<guillaume-exterieur.betous@fr.thalesgroup.com>
a écrit :
Bef7ff8a0537495a1876ffebdc9f8e51?d=identicon&s=25 Lionel Bouton (Guest)
on 2007-03-09 10:20
(Received via mailing list)
Guillaume Betous wrote the following on 09.03.2007 08:40 :
> rapidement, c'était quasi inutilisable... 3 ou 4 secondes pour accéder
> à chaque page !!!
>
> Mon appli n'est pas grosse, je compte pas avoir 1000 requetes par
> seconde, donc je pensais qu'un petit serveur dans le style suffirait.
> C'est apparemment faux.
>
> Avant d'abandonner définitivement la solution kimsufi, y a-t-il un
> moyen de servir du Rails qui utiliserait moins de RAM ?
> Au passage, j'utilise sqlite3, pensant que ça prend moins de
> ressources que mySQL par exemple.

PostgreSQL est beaucoup moins gourmand en RAM que MySQL. SQLite3 est à
éviter en dehors des dev (lorsque tu fais une écriture, aucune autre
écriture ni même lecture n'est possible).

Astuces supplémentaires :
- utiliser un serveur web léger (lighttpd ou nginx par exemple) au lieu
d'Apache.
- utiliser djbdns au lieu de bind (il faut prendre le temps de rentrer
dans le bain, mais la différence en terme de RAM est très importante).
- faire la chasse à tous les processus qui tournent sur la machine (y
compris temporairement par cron, car ils peuvent faire passer ton appli
en swap pour pouvoir tourner, si tu peux te passer de locate, désactiver
updatedb peut aider par exemple).

Lionel
A817be4bff5c9ba9c9282a0dce77bd6a?d=identicon&s=25 Jérémy Dierx (Guest)
on 2007-03-09 11:10
(Received via mailing list)
Salut Guillaume,

J'ai fait mes premiers test Apache+rails+mongrel sur un kimsuffi avec os
debian. Le tout s'est plutôt bien comporté avec une petite appli test.
Depuis je suis passé à un serveur plus performant pour la mise en prod.
J'utilise nginx+mongrel et j'en suis pleinement satisfait. De plus nginx
est d'une facilité de mise en service incroyable.

A+

Jérémy.

Le vendredi 09 mars 2007 à 10:18 +0100, Lionel Bouton a écrit :
C211e4b403330c86c56db30357a2b64c?d=identicon&s=25 Guillaume Betous (Guest)
on 2007-03-09 11:34
(Received via mailing list)
> J'utilise nginx+mongrel et j'en suis pleinement satisfait. De plus nginx
> est d'une facilité de mise en service incroyable.

je vais me tenter nginx (litespeed est une bonne idée... mais pas libre
(-: )

gUI
C211e4b403330c86c56db30357a2b64c?d=identicon&s=25 Guillaume Betous (Guest)
on 2007-03-13 10:56
(Received via mailing list)
> je vais me tenter nginx

depuis qques jours je suis donc avec :
- nginx
- 2 process mongrel
- mysql

je reste à la limite du swap avec la consommation mémoire suivante :

# free -m
              total       used       free     shared    buffers
cached
Mem:           217        210          6          0          8
13
-/+ buffers/cache:        188         28
Swap:          509          1        508

je précise que l'activité du site est proche de l'ancéphalogramme plat,
puisque
c'est en phase de dev, meme si il tourne dans un environnement
"production".

voilà, c'est pour témoigner que dans le cadre d'une appli ayant un
trafic très
faible, les 256Mo de RAM d'un kimsufi sont suffisants.

ensuite, lors d'une augmentation du trafic, je me demande en fait en
quoi la
conso de RAM va augmenter. par exemple, mysql augmente-t-il son nombre
de
proccessus ?

gUI
3c75327133edef1a398f48a3566b0f7b?d=identicon&s=25 Frédéric Logier (Guest)
on 2007-03-13 11:13
(Received via mailing list)
Le 13/03/07, Guillaume Betous  a écrit :
>
>
>
> voilà, c'est pour témoigner que dans le cadre d'une appli ayant un trafic
> très
> faible, les 256Mo de RAM d'un kimsufi sont suffisants.


Perso je préfère les 1Go de RAM d'une dedibox :)
C211e4b403330c86c56db30357a2b64c?d=identicon&s=25 Guillaume Betous (Guest)
on 2007-03-13 11:21
(Received via mailing list)
> Perso je préfère les 1Go de RAM d'une dedibox :)

C'est pas 512 la dédibox ???

gUI

--
Guillaume Betous : (05 61) 19 40 65 / bureau 602N
Bef7ff8a0537495a1876ffebdc9f8e51?d=identicon&s=25 Lionel Bouton (Guest)
on 2007-03-13 11:22
(Received via mailing list)
Guillaume Betous wrote the following on 13.03.2007 10:54 :
> # free -m
>              total       used       free     shared    buffers     cached
> Mem:           217        210          6          0          8         13
> -/+ buffers/cache:        188         28
> Swap:          509          1        508
>

Est-ce possible d'avoir un listing des processus (ps aux)? Je
m'attendais à ce que dans ta configuration (nginx: 1-2M, mongrel:
30M-40M * 2, mysql: ?) ça rentre dans 128M et je vois que tu as 188M
d'utilisé.

Sur un VPS avec lighttpd, postfix, djbdns, PostgreSQL, OpenVPN, SQLgrey,
nagios, tpop3d et les processus courants (sshd, crond, syslog-ng, udevd,
...) j'ai 30 + 24M d'utilisé (RAM + SWAP, sachant que j'ai 128M de RAM
disponible ce qui me laisse ~ 90M de RAM libre)...
Je tape dans le swap, mais uniquement parce que certains processus
n'utilisent pas vraiment la RAM allouée (je n'ai quasiment aucun accès
au swap alors que tous les processus listés sont utilisés en permanence)
et que donc Linux préfère récupérer la RAM pour du cache.

Lionel.
C211e4b403330c86c56db30357a2b64c?d=identicon&s=25 Guillaume Betous (Guest)
on 2007-03-13 11:26
(Received via mailing list)
> Est-ce possible d'avoir un listing des processus (ps aux)?

il y a *bcp* de process mysql...

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.2   1444   504 ?        S    Mar12   0:06 init
[3]
root         2  0.0  0.0      0     0 ?        S    Mar12   0:00
[keventd]
root         3  0.0  0.0      0     0 ?        SN   Mar12   0:00
[ksoftirqd_CPU]
root         4  0.0  0.0      0     0 ?        S    Mar12   0:00
[kswapd]
root         5  0.0  0.0      0     0 ?        S    Mar12   0:00
[bdflush]
root         6  0.0  0.0      0     0 ?        S    Mar12   0:00
[kupdated]
root         7  0.0  0.0      0     0 ?        S<   Mar12   0:00
[mdrecoveryd]
root         8  0.0  0.0      0     0 ?        S    Mar12   0:00
[kjournald]
root     28831  0.0  0.0      0     0 ?        S    Mar12   0:00
[kjournald]
root     28212  0.0  0.3   2096   812 ?        Ss   Mar12   0:00
/usr/sbin/syslo
mysql     3237  0.0 13.0  94036 28944 ?        Ss   Mar12   0:00
/usr/sbin/mysql
mysql    20526  0.0 13.0  94036 28944 ?        S    Mar12   0:00
/usr/sbin/mysql
mysql    32135  0.0 13.0  94036 28944 ?        S    Mar12   0:00
/usr/sbin/mysql
mysql    10427  0.0 13.0  94036 28944 ?        S    Mar12   0:00
/usr/sbin/mysql
mysql      929  0.0 13.0  94036 28944 ?        S    Mar12   0:00
/usr/sbin/mysql
mysql     5404  0.0 13.0  94036 28944 ?        S    Mar12   0:00
/usr/sbin/mysql
mysql    12999  0.0 13.0  94036 28944 ?        S    Mar12   0:12
/usr/sbin/mysql
mysql    27230  0.0 13.0  94036 28944 ?        S    Mar12   0:08
/usr/sbin/mysql
mysql      108  0.0 13.0  94036 28944 ?        S    Mar12   0:00
/usr/sbin/mysql
mysql       87  0.0 13.0  94036 28944 ?        S    Mar12   0:00
/usr/sbin/mysql
mysql    27879  0.0 13.0  94036 28944 ?        S    Mar12   0:00
/usr/sbin/mysql
root     19476  0.0  0.3   5840   888 ?        Ss   Mar12   0:00 nginx:
master p
nginx    21495  0.0  1.3   6000  3100 ?        S    Mar12   0:00 nginx:
worker p
root       361  0.0  0.4   3832   928 ?        Ss   Mar12   0:01
/usr/sbin/sshd
root     27104  0.0  0.3   1968   676 ?        Ss   Mar12   0:00
/usr/sbin/cron
root     29605  0.0 14.4  36100 32144 ?        S    Mar12   0:06
/usr/bin/ruby18
root     11378  0.0 14.4  36040 32020 ?        S    Mar12   0:06
/usr/bin/ruby18
root     17547  0.0  0.2   1432   448 tty1     Ss+  Mar12   0:00
/sbin/agetty 38
root      9336  0.0  0.2   1432   448 tty2     Ss+  Mar12   0:00
/sbin/agetty 38
root     20245  0.0  0.2   1432   448 tty3     Ss+  Mar12   0:00
/sbin/agetty 38
root     20953  0.0  0.2   1432   448 tty4     Ss+  Mar12   0:00
/sbin/agetty 38
root     31338  0.0  0.2   1432   448 tty5     Ss+  Mar12   0:00
/sbin/agetty 38
root     26134  0.0  0.2   1432   448 tty6     Ss+  Mar12   0:00
/sbin/agetty 38
mysql     2334  0.0 13.0  94036 28944 ?        S    07:25   0:00
/usr/sbin/mysql
mysql     6502  0.0 13.0  94036 28944 ?        S    07:25   0:00
/usr/sbin/mysql
root     28377  0.0  0.9   6676  2180 ?        Ss   09:57   0:00 sshd:
root@ttyp
root     25733  0.0  0.7   3008  1676 ttyp0    Ss   09:57   0:00 -bash
root     24346  0.0  0.4   2292   904 ttyp0    R+   11:23   0:00 ps aux
Bef7ff8a0537495a1876ffebdc9f8e51?d=identicon&s=25 Lionel Bouton (Guest)
on 2007-03-13 11:27
(Received via mailing list)
Frédéric Logier wrote the following on 13.03.2007 11:11 :
> Le 13/03/07, *Guillaume Betous*  a écrit :
>
>
>
>     voilà, c'est pour témoigner que dans le cadre d'une appli ayant un
>     trafic très
>     faible, les 256Mo de RAM d'un kimsufi sont suffisants.
>
>
> Perso je préfère les 1Go de RAM d'une dedibox :)

Si tu as besoin de RAM oui. Si tu as besoin de CPU pour faire tourner
erb et que tu peux te contenter de 256M, la kimsufi est préférable (et
moins chère). Enfin, un VPS 256M chez Linode coûte encore moins cher que
la kimsufi, mais il faut s'attendre à avoir moins de CPU de temps en
temps.

Lionel.
3c75327133edef1a398f48a3566b0f7b?d=identicon&s=25 Frédéric Logier (Guest)
on 2007-03-13 11:29
(Received via mailing list)
Le 13/03/07, Guillaume Betous  a écrit :
>
>
> > Perso je préfère les 1Go de RAM d'une dedibox :)
>
> C'est pas 512 la dédibox ???
>

1Go de RAM, processeur 2Ghz VIA.
http://www.dedibox.fr/
C211e4b403330c86c56db30357a2b64c?d=identicon&s=25 Guillaume Betous (Guest)
on 2007-03-13 11:31
(Received via mailing list)
> 1Go de RAM, processeur 2Ghz VIA.

J'étais persuadé que c'était 512 ! C'est récent le passage à 1Go ???

gUI

--
Guillaume Betous : (05 61) 19 40 65 / bureau 602N
3c75327133edef1a398f48a3566b0f7b?d=identicon&s=25 Frédéric Logier (Guest)
on 2007-03-13 11:33
(Received via mailing list)
Le 13/03/07, Lionel Bouton a écrit :
>
>
> Si tu as besoin de RAM oui. Si tu as besoin de CPU pour faire tourner
> erb et que tu peux te contenter de 256M, la kimsufi est préférable (et
> moins chère).


La différence de 10€ n'est à mon avis pas suffisante, l'écart entre la
taille mémoire est trop énorme. 256 Mo de RAM c'est vraiment trop
faible.
3c75327133edef1a398f48a3566b0f7b?d=identicon&s=25 Frédéric Logier (Guest)
on 2007-03-13 11:34
(Received via mailing list)
Le 13/03/07, Guillaume Betous a écrit :
>
> > 1Go de RAM, processeur 2Ghz VIA.
>
> J'étais persuadé que c'était 512 ! C'est récent le passage à 1Go ???
>
>
Ca a toujours été 1Go de RAM.
C211e4b403330c86c56db30357a2b64c?d=identicon&s=25 Guillaume Betous (Guest)
on 2007-03-13 11:37
(Received via mailing list)
> Ca a toujours été 1Go de RAM.

Faut que j'achète des yeux moi (((-:

gUI

--
Guillaume Betous : (05 61) 19 40 65 / bureau 602N
Bef7ff8a0537495a1876ffebdc9f8e51?d=identicon&s=25 Lionel Bouton (Guest)
on 2007-03-13 11:40
(Received via mailing list)
Guillaume Betous wrote the following on 13.03.2007 11:23 :
>
>> Est-ce possible d'avoir un listing des processus (ps aux)?
>
> il y a *bcp* de process mysql...

Si je ne me trompe pas ce sont des threads, donc en fait ça ne prend pas
tant que ça. Mais il est clairement beaucoup plus lourd que
PostgreSQL...
Au fait, si ton occupation RAM était relevée juste après le boot, tu
peux t'attendre à ce qu'une partie aille en SWAP à l'usage, mais je ne
sais pas dans quelles proportions : ça dépend vraiment de trop de
paramètres.

Lionel
C211e4b403330c86c56db30357a2b64c?d=identicon&s=25 Guillaume Betous (Guest)
on 2007-03-13 11:43
(Received via mailing list)
> Mais il est clairement beaucoup plus lourd que PostgreSQL...

je peux toujours tenter avec PostgresSQL. Vu que c'est rails qui
s'occupe de
tout, je me fiche un peu du SGBD qu'il y a derrière !!!

gUI
A817be4bff5c9ba9c9282a0dce77bd6a?d=identicon&s=25 Jérémy Dierx (Guest)
on 2007-03-13 11:55
(Received via mailing list)
Bonjour,

A titre de comparaison, voici ma config sur dédié :

- processeur : Intel  Pentium 4 HyperThreading 3.00 GHz
- RAM : 1Go
- ruby 1.8.5
- rails 1.2.2
- nginx 0.5.12
- mongrel server 1.0.1
- mysql 5.0.32

free -m donne :

             total       used       free     shared    buffers
cached
Mem:           999        673        326          0         99
410
-/+ buffers/cache:        163        836
Swap:          509          0        509

ps aux donne :

USER      PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0  1492  504 ?        S    Feb18   0:12 init
[2]
root         2  0.0  0.0     0    0 ?        S    Feb18   0:00 [keventd]
root         3  0.0  0.0     0    0 ?        SN   Feb18   0:00
[ksoftirqd_CPU0]
root         4  0.0  0.0     0    0 ?        SN   Feb18   0:01
[ksoftirqd_CPU1]
root         5  0.0  0.0     0    0 ?        S    Feb18   0:00 [kswapd]
root         6  0.0  0.0     0    0 ?        S    Feb18   0:00 [bdflush]
root         7  0.0  0.0     0    0 ?        S    Feb18   0:10
[kupdated]
root         8  0.0  0.0     0    0 ?        S    Feb18   0:00
[scsi_eh_0]
root         9  0.0  0.0     0    0 ?        S    Feb18   0:00
[scsi_eh_1]
root        10  0.0  0.0     0    0 ?        S<   Feb18   0:00
[mdrecoveryd]
root        11  0.0  0.0     0    0 ?        S    Feb18   0:36
[kjournald]
root     18231  0.0  0.0     0    0 ?        S    Feb18   0:00
[kjournald]
root     20105  0.0  0.0  2248  792 ?        Ss   Feb18
0:14 /sbin/syslogd
root     31080  0.0  0.0  1492  464 ?        Ss   Feb18
0:00 /sbin/klogd
root      5801  0.0  0.1  3128 2012 ?        Ss   Feb18
0:00 /usr/sbin/named
Debian-   1825  0.0  0.1  5124 1648 ?        Ss   Feb18
0:00 /usr/sbin/exim4 -bd -q30m
root      4686  0.0  0.0  1480  428 ?        Ss   Feb18
0:00 /usr/sbin/inetd
root     10423  0.0  0.0  1752  724 ?        Ss   Feb18
0:04 /usr/sbin/cron
root     32279  0.0  0.0  1488  476 tty1     Ss+  Feb18
0:00 /sbin/getty 38400 tty1
root     10646  0.0  0.0  1488  476 tty2     Ss+  Feb18
0:00 /sbin/getty 38400 tty2
root     24723  0.0  0.0  1488  476 tty3     Ss+  Feb18
0:00 /sbin/getty 38400 tty3
root      2502  0.0  0.0  1484  472 tty4     Ss+  Feb18
0:00 /sbin/getty 38400 tty4
root     11784  0.0  0.0  1488  476 tty5     Ss+  Feb18
0:00 /sbin/getty 38400 tty5
root     26443  0.0  0.0  1488  476 tty6     Ss+  Feb18
0:00 /sbin/getty 38400 tty6
root     18839  0.0  0.0  1488  480 ttyS0    Ss+  Feb18
0:00 /sbin/getty -L ttyS0 9600 vt100
root     10817  0.0  0.1  3724 1564 ?        Ss   Mar02
0:00 /usr/sbin/sshd
root     15993  0.0  0.1  2312 1116 ?        S    Mar07
0:00 /bin/sh /usr/bin/mysqld_safe
mysql      322  0.0  1.8 78468 18976 ?       S    Mar07
0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql
--user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip
root     26402  0.0  0.0  1484  492 ?        S    Mar07   0:00 logger -p
daemon.err -t mysqld_safe -i -t mysqld
mysql    11413  0.0  1.8 78468 18976 ?       S    Mar07
0:02 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql
--user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip
mysql    29924  0.0  1.8 78468 18976 ?       S    Mar07
0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql
--user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip
mysql    14487  0.0  1.8 78468 18976 ?       S    Mar07
0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql
--user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip
mysql     8625  0.0  1.8 78468 18976 ?       S    Mar07
0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql
--user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip
mysql    30215  0.0  1.8 78468 18976 ?       S    Mar07
0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql
--user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip
mysql     7194  0.0  1.8 78468 18976 ?       S    Mar07
0:28 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql
--user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip
mysql    14417  0.0  1.8 78468 18976 ?       S    Mar07
0:38 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql
--user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip
mysql    10668  0.0  1.8 78468 18976 ?       S    Mar07
0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql
--user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip
mysql    10100  0.0  1.8 78468 18976 ?       S    Mar07
0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql
--user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip
mysql    17451  0.0  1.8 78468 18976 ?       S    Mar07
0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql
--user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip
mysql    19480  0.0  1.8 78468 18976 ?       S    Mar07
0:01 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql
--user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip
root     18454  0.0  0.1  3692 1744 ?        Ss   Mar07   0:00 nginx:
master process /usr/local/sbin/nginx
jeremy   30108  0.0  0.2  3992 2140 ?        S    Mar07   0:07 nginx:
worker process
jeremy   16637  0.0  0.2  3992 2108 ?        S    Mar07   0:03 nginx:
worker process
mysql    12021  0.0  1.8 78468 18976 ?       S    Mar07
0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql
--user=mysql --pid-file=/var/run/mysqld/mysqld.pid --skip
root     25394  0.0  3.0 32536 30860 ?       S    Mar08
0:19 /usr/local/bin/ruby /usr/local/bin/mongrel_rails start -d -e
production -p 8002 -a 127.0.0.1 -P log/mongrel.8002.p
root     12832  0.0  3.0 32504 30876 ?       S    Mar08
0:18 /usr/local/bin/ruby /usr/local/bin/mongrel_rails start -d -e
production -p 8003 -a 127.0.0.1 -P log/mongrel.8003.p
root       897  0.0  0.1  7012 2044 ?        Ss   11:18   0:00 sshd:
jeremy [priv]
jeremy   27057  0.0  0.2  7160 2112 ?        S    11:18   0:00 sshd:
jeremy@pts/0
jeremy   17223  0.0  0.1  2600 1508 pts/0    Ss   11:18   0:00 -bash
root     31089  0.0  0.1  2580 1484 pts/0    S    11:33   0:00 bash
root     29180  0.0  0.0  2488  856 pts/0    R+   11:49   0:00 ps aux

Voilà.

Jérémy.



Le mardi 13 mars 2007 à 11:23 +0100, Guillaume Betous a écrit :
A83a70aa42afa4c45563213e6ffc03ce?d=identicon&s=25 Eric Daspet (Guest)
on 2007-03-13 11:57
(Received via mailing list)
Le Mar 13 mars 2007 10:54, Guillaume Betous a écrit :
> "production".
On a vraiment un *énorme* problème avec l'hébergement de rails. Voir comme
un succès qu'une appli sans utilisateur tienne sur un serveur dédié avec
256 Mo de ram ça m'horrifie. Je me rappelle encore il y a 10 ans où
on
faisait tourner des serveurs PHP sur des pentium pro 200 Mghz avec moins
de ram que ça et avec fluidité .

Prendre plus que 100Mo de ram pour ça c'est franchement innacceptable.

Pire, pour ne rien gacher notre architecture est fixe : on a lancé 2
mongrels, qui seront toujours là qu'ils reçoivent 0 requêtes ou 50. Ca
aussi c'est innacceptable. Ca fait des années que les serveurs Web savent
gérer un processus léger permanent pour quand il n'y a aucune requête, et
en créer plein à la volée dès qu'il y en a besoin (et les supprimer
dèsqu'il y en a trop d'inutilisés).

On revient en arrière de presque 12 ans là, tant que le ratio mémoire
utilisée / mémoire dispo que sur la capacité du serveur à s'adapter à sa
charge.

Si quelqu'un a une solution je veux bien, mais là on ne s'imposera pas
tant qu'on n'aura pas résolu le(s) problème(s)

--
Éric Daspet
http://eric.daspet.name/
Bef7ff8a0537495a1876ffebdc9f8e51?d=identicon&s=25 Lionel Bouton (Guest)
on 2007-03-13 12:50
(Received via mailing list)
Eric Daspet wrote the following on 13.03.2007 11:55 :
>> je precise que l'activite du site est proche de l'ancephalogramme plat,
> de ram que ça et avec fluidité .
>
> Prendre plus que 100Mo de ram pour ça c'est franchement innacceptable.
>

Comme je le disais, ce n'est pas Rails le plus gourmand dans cette
histoire, mais plutôt MySQL... Sur un mutualisé la base de données et
tout le reste sont déjà présents, tu peux donc compter environ 60M de
RAM.
Evidemment le tableau change lorsqu'on augmente le nombre de Mongrels ou
processus fastcgi...

> Pire, pour ne rien gacher notre architecture est fixe : on a lancé 2
> mongrels, qui seront toujours là qu'ils reçoivent 0 requêtes ou 50. Ca
> aussi c'est innacceptable. Ca fait des années que les serveurs Web savent
> gérer un processus léger permanent pour quand il n'y a aucune requête, et
> en créer plein à la volée dès qu'il y en a besoin (et les supprimer dès
> qu'il y en a trop d'inutilisés).
>

Rails ne permet pas d'avoir des processus légers et il n'y a pas grand
chose à faire de ce côté (le mieux serait de permettre de forker après
le chargement des librairies et avant l'établissement des connexions
avec la BD, mais c'est complexe et a des effets de bord). De toute
manière ce processus n'est pas intégrable dans le serveur web et
nécessiterait le dev d'un 'super-mongrel'.

> On revient en arrière de presque 12 ans là, tant que le ratio mémoire
> utilisée / mémoire dispo que sur la capacité du serveur à s'adapter à sa
> charge.
>
> Si quelqu'un a une solution je veux bien, mais là on ne s'imposera pas
> tant qu'on n'aura pas résolu le(s) problème(s)
>
>

Tout dépend du marché que tu adresses. J'ai une appli en production qui
aurait probablement coûté le double si elle avait été faite en PHP (on
passe de plus de 150k€ à 300k€ quand même) et elle tourne dans une
infrastructure qui me coûte moins de 100€ par mois (en comptant la
machine, la bande-passante, la supervision, le backup et une machine de
spare). Pour info, actuellement je m'en sors avec 120M tout compris
alors qu'en plus de lighttpd/rails/PostgreSQL j'ai besoin d'un serveur
Postfix dédié et d'un ordonnanceur en Ruby qui me coûtent 41,5M. En
comptant tout le système, ça fait moins de 80M pour une appli Rails avec
trois processus fastcgi traitant les requêtes HTTP en parallèle.

Je pense pouvoir dire qu'il y a très peu de chances que je dépense ne
serait-ce que 10% des 150k€ de différence en coûts d'hébergement
supplémentaires par rapport à toute autre solution technique...

Il faut positionner Rails face aux infrastructures J2EE qui elles
nécessitent encore plus de RAM (x10 ?) pour le ticket d'entrée, pas en
face de mod_php pour héberger des sites webs vaguement interractifs sur
serveurs mutualisés... Je ne pourrai tout simplement *pas* héberger une
appli J2EE sur mon infrastructure actuelle, ça me coûterait probablement
3 fois plus cher en hébergement.

Si tu vends Rails en tant que techno pour héberger un site perso chez
Free, il y a erreur de casting.

Lionel
3c75327133edef1a398f48a3566b0f7b?d=identicon&s=25 Frédéric Logier (Guest)
on 2007-03-13 13:23
(Received via mailing list)
Le 13/03/07, Eric Daspet a écrit :
>
>
> On revient en arrière de presque 12 ans là, tant que le ratio mémoire
> utilisée / mémoire dispo que sur la capacité du serveur à s'adapter à sa
> charge.
>
> Si quelqu'un a une solution je veux bien, mais là on ne s'imposera pas
> tant qu'on n'aura pas résolu le(s) problème(s)
>


Personnellement je pense que c'est un faux problème car Rails n'a pas
vraiment les mêmes objectifs que PHP. Rails est à mon avis clairement
orienté professionnel. Je ne vois pas le grand public hébergé chez free,
apprendre l'objet et un modèle MVC juste pour son site perso. Par contre
un
professionnel a largement les moyens d'investir dans un serveur avec
suffisamment de RAM. Rails est au même niveau que Zope ou Java, il
nécessite
un minimum de ressources matériel, et on remarquera que Zope et Java ne
sont
clairement pas utilisé par le public.
Rails s'impose déjà :)
C211e4b403330c86c56db30357a2b64c?d=identicon&s=25 Guillaume Betous (Guest)
on 2007-03-13 13:29
(Received via mailing list)
> La différence de 10€ n'est à mon avis pas suffisante, l'écart entre la
> taille mémoire est trop énorme. 256 Mo de RAM c'est vraiment trop faible.

Je pense que 10€ (HT en plus) c'est quand meme bcp comme différence.
Faut pas
oublier que le dedibox se trouve à 50% plus cher qu'un kimsufi, ou le
kimsufi à
30% moins cher que le dedibox.

Ensuite, la qualité de la connexion est apparemment pas la meme (là, je
me base
sur ce que je lis sur les forums), ainsi que le processeur (d'ailleurs
au
passage j'ai un Celeron 2.6GHz, et non pas 2GHz comme écrit sur le
site).

Et pour finir, un kimsufi se paye par CB, chaque mois si on veut (alors
que
dedibox c'est RIB, sinon amende !!!). Pas besoin de résilier, suffit de
pas payer !

En fait il manque pile-poil la prestation au milieu : un petit serveur
(Celeron
pourquoi pas) avec 512Mo de RAM. 256Mo de RAM ça limite les utilisations
(c'est
de toutes façons clairement dit sur le site), et pour du Rails, ça
devrait
servir à faire tourner une maquette, ou alors un tout petit site en
production.

gUI
C211e4b403330c86c56db30357a2b64c?d=identicon&s=25 Guillaume Betous (Guest)
on 2007-03-13 13:58
(Received via mailing list)
> Mais il est clairement beaucoup plus lourd que PostgreSQL...

Magie de RubyOnRails, me voici déjà avec un système PostgreSQL qui
tourne (-:

Les stats sont déjà bcp plus flatteuses ! Bon, je vais le laisser
tourner qques
jours, pour voir si il devient plus gourmand.

# free -m
              total       used       free     shared    buffers
cached
Mem:           217        179         37          0         12
72
-/+ buffers/cache:         94        122
Swap:          509          1        508


# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.1   1444   444 ?        S    Mar12   0:06 init
[3]
root         2  0.0  0.0      0     0 ?        S    Mar12   0:00
[keventd]
root         3  0.0  0.0      0     0 ?        SN   Mar12   0:00
[ksoftirqd_CPU0]
root         4  0.0  0.0      0     0 ?        S    Mar12   0:01
[kswapd]
root         5  0.0  0.0      0     0 ?        S    Mar12   0:00
[bdflush]
root         6  0.0  0.0      0     0 ?        S    Mar12   0:00
[kupdated]
root         7  0.0  0.0      0     0 ?        S<   Mar12   0:00
[mdrecoveryd]
root         8  0.0  0.0      0     0 ?        S    Mar12   0:00
[kjournald]
root     28831  0.0  0.0      0     0 ?        S    Mar12   0:00
[kjournald]
root     28212  0.0  0.3   2096   768 ?        Ss   Mar12   0:00
/usr/sbin/syslog-ng
root     19476  0.0  0.3   5840   888 ?        Ss   Mar12   0:00 nginx:
master
process /usr/sbin
nginx    21495  0.0  0.8   6000  1924 ?        S    Mar12   0:00 nginx:
worker
process
root       361  0.0  0.4   3832   928 ?        Ss   Mar12   0:01
/usr/sbin/sshd
root     27104  0.0  0.3   1968   676 ?        Ss   Mar12   0:00
/usr/sbin/cron
root     17547  0.0  0.1   1432   380 tty1     Ss+  Mar12   0:00
/sbin/agetty
root      9336  0.0  0.1   1432   380 tty2     Ss+  Mar12   0:00
/sbin/agetty
root     20245  0.0  0.1   1432   380 tty3     Ss+  Mar12   0:00
/sbin/agetty
root     20953  0.0  0.1   1432   380 tty4     Ss+  Mar12   0:00
/sbin/agetty
root     31338  0.0  0.1   1432   380 tty5     Ss+  Mar12   0:00
/sbin/agetty
root     26134  0.0  0.1   1432   380 tty6     Ss+  Mar12   0:00
/sbin/agetty
root     28377  0.0  1.0   6832  2336 ?        Ss   09:57   0:01 sshd:
root
25733  0.0  0.8   3144  1796 ttyp0    Ss   09:57   0:00 -bash
postgres 31621  0.0  2.6  23152  5956 ?        Ss   13:11   0:00
/usr/bin/postmaster -D /var/lib
postgres  8259  0.0  3.0  23284  6832 ?        S    13:11   0:00
postgres:
writer process
postgres 16353  0.0  1.0   8420  2400 ?        S    13:11   0:00
postgres: stats
buffer process
postgres  2750  0.0  1.3   8048  2932 ?        S    13:11   0:00
postgres: stats
collector proce
root     25181  0.3 13.6  32820 30444 ?        S    13:38   0:02
/usr/bin/ruby18
/usr/bin/mongre
root     18007  0.3 13.8  33172 30880 ?        S    13:38   0:02
/usr/bin/ruby18
/usr/bin/mongre
postgres 25969  0.0  3.7  24040  8432 ?        S    13:40   0:00
postgres:
elevage elevage 127.0
postgres  5178  0.0  4.0  24136  8952 ?        S    13:40   0:00
postgres:
elevage elevage 127.0
root     18452  0.0  0.4   2292   904 ttyp0    R+   13:52   0:00 ps aux

gUI
3c75327133edef1a398f48a3566b0f7b?d=identicon&s=25 Frédéric Logier (Guest)
on 2007-03-13 14:08
(Received via mailing list)
2007/3/13, Guillaume Betous :

>
> Magie de RubyOnRails, me voici déjà avec un système PostgreSQL qui tourne
> (-:
>
> Les stats sont déjà bcp plus flatteuses ! Bon, je vais le laisser tourner
> qques
> jours, pour voir si il devient plus gourmand.


A propos de PostgreSQL il existe ce bouquin récent que je viens de
commander
:
http://www.amazon.fr/PostgreSQL-8-1-Administration...

Pour ceux intéressés par une vraie base de données ... :)
C211e4b403330c86c56db30357a2b64c?d=identicon&s=25 Guillaume Betous (Guest)
on 2007-03-13 14:11
(Received via mailing list)
> A propos de PostgreSQL il existe ce bouquin récent que je viens de
> commander :

Si il y a un chapitre sur l'optimisation mémoire, je t'autorise à m'en faire
un
résumé (((-:

gUI

--
Guillaume Betous : (05 61) 19 40 65 / bureau 602N
3c75327133edef1a398f48a3566b0f7b?d=identicon&s=25 Frédéric Logier (Guest)
on 2007-03-13 14:13
(Received via mailing list)
Le 13/03/07, Guillaume Betous a écrit :
>
>
> > A propos de PostgreSQL il existe ce bouquin récent que je viens de
> > commander :
>
> Si il y a un chapitre sur l'optimisation mémoire, je t'autorise à m'en
> faire un
> résumé (((-:
>

On verra :)
Mais bon si tu tiens vraiment à utiliser une base de données sur un
serveur
très limité en RAM utilise Sqlite ... Rails fonctionne aussi avec il me
semble.
Bef7ff8a0537495a1876ffebdc9f8e51?d=identicon&s=25 Lionel Bouton (Guest)
on 2007-03-13 14:16
(Received via mailing list)
Guillaume Betous wrote the following on 13.03.2007 13:54 :
> > Mais il est clairement beaucoup plus lourd que PostgreSQL...
>
> Magie de RubyOnRails, me voici déjà avec un système PostgreSQL qui
> tourne (-:
>
> Les stats sont déjà bcp plus flatteuses ! Bon, je vais le laisser
> tourner qques jours, pour voir si il devient plus gourmand.
>

Pour le dev et des petites démos, ça n'a guère d'importance, mais si tu
utilises PostgreSQL en prod, tu auras intérêt à faire tourner
pg_autovacuum. Ca te prendra probablement moins d'un mega de RAM mais
c'est un excellent investissement (PostgreSQL a besoin d'avoir des stats
à jour sur ses tables pour bien utiliser ses indexes et pg_autovacuum
automatise cela, MySQL a l'avantage de faire ça automatiquement).

Lionel.
C211e4b403330c86c56db30357a2b64c?d=identicon&s=25 Guillaume Betous (Guest)
on 2007-03-13 14:17
(Received via mailing list)
> Rails fonctionne aussi avec il me semble.

oui, et c'est d'ailleurs ce que j'utilise en dev. on m'a dit qu'il a
l'inconvénient de ne pas pouvoir faire d'accès concurrents, donc je voulais
voir
avec un *vrai* SGBD. Vu que PostgreSQL a l'air d'etre pas trop gourmand,
je
pense que je vais le garder le temps de faire un peu plus d'essais.

gUI

--
Guillaume Betous : (05 61) 19 40 65 / bureau 602N
3c75327133edef1a398f48a3566b0f7b?d=identicon&s=25 Frédéric Logier (Guest)
on 2007-03-13 14:21
(Received via mailing list)
Le 13/03/07, Lionel Bouton a écrit :
>
>
> Pour le dev et des petites démos, ça n'a guère d'importance, mais si tu
> utilises PostgreSQL en prod, tu auras intérêt à faire tourner
> pg_autovacuum. Ca te prendra probablement moins d'un mega de RAM mais
> c'est un excellent investissement (PostgreSQL a besoin d'avoir des stats
> à jour sur ses tables pour bien utiliser ses indexes et pg_autovacuum
> automatise cela, MySQL a l'avantage de faire ça automatiquement).
>


J'en saurais plus avec le bouquin mais je suis presque sûr que le vacuum
est
automatique depuis les version 8.x
C211e4b403330c86c56db30357a2b64c?d=identicon&s=25 Guillaume Betous (Guest)
on 2007-03-13 14:24
(Received via mailing list)
> J'en saurais plus avec le bouquin mais je suis presque sûr que le vacuum
> est automatique depuis les version 8.x

En tous cas il était présent lors d'une simple installation Gentoo "emerge
postgresql". Je viens de l'activer...

gUI

--
Guillaume Betous : (05 61) 19 40 65 / bureau 602N
A83a70aa42afa4c45563213e6ffc03ce?d=identicon&s=25 Eric Daspet (Guest)
on 2007-03-13 14:36
(Received via mailing list)
> Rails ne permet pas d'avoir des processus légers et il n'y a pas grand
> chose à faire de ce côté (le mieux serait de permettre de forker après
> le chargement des librairies et avant l'établissement des connexions
> avec la BD, mais c'est complexe et a des effets de bord). De toute
> manière ce processus n'est pas intégrable dans le serveur web et
> nécessiterait le dev d'un 'super-mongrel'.

Mea cupla sur le vocabulaire, j'aurai du dire "pas trop lourd en mémoire".
J'entendais bien un modèle de type prefork.

Et à vrai dire je n'ai même pas besoin d'avoir un fork complexe à la
super-mongrel. Déjà pouvoir adapter le nombre de fils à la charge serait
super. Après si on doit se taper une ou deux requêtes lentes le temps que
rails initialise tout ce n'est pas le plus gênant.

Je ne demande pas un serveur threadé et toutes les bibliothèques et cache
en mémoire partagé. Ca serait bien mais on n'en est pas là. Si déjà le
serveur savait s'adapter à la charge au lieu d'imposer le démarrage d'un
nombre de fils fixes, ça serait bien.

> Il faut positionner Rails face aux infrastructures J2EE qui elles
> nécessitent encore plus de RAM (x10 ?) pour le ticket d'entrée, pas en
> face de mod_php pour héberger des sites webs vaguement interractifs sur
> serveurs mutualisés...


Oulà, ça vient peut être de mon expérience, mais pour moi Rails est bien
plus proche de PHP que de Java. Les sites Web PHP ne sont pas plus
"vaguement" interactifs que les Java ou Rails.

Pour voir comment sont utilisées et conçues les applications Web autour de
moi, je peux t'assurer qu'un problème d'hébergement est un problème
critique. Qu'on soit en entreprise n'y change rien. Au contraire j'aurai
presque tendance à dire : l'amateur bidouillera pour faire fonctionner,
pas le professionnel.


> Je ne pourrai tout simplement *pas* héberger une
> appli J2EE sur mon infrastructure actuelle, ça me coûterait probablement
> 3 fois plus cher en hébergement.

Oui, peut être (quoi que), mais les procédures sont claires et les
déploiements automatisés. Je n'ai pas à installer un proxy, puis décider
combien de fils lancer, puis me rendre compte que mon serveur ne répond
pas à certaine parce que même si la charge moyenne est bonne j'ai eu le
malheur d'avoir N+1 requêtes à un instant T avec seulement N processus.

Ca c'est franchement bloquant.
Et d'ailleurs *ça* c'est cher à l'hébergement, car ça demande des
administrateurs qui manuellement vont toucher à ce genre de détails et
connaissent l'architecture.


--
Eric
3c75327133edef1a398f48a3566b0f7b?d=identicon&s=25 Frédéric Logier (Guest)
on 2007-03-13 14:37
(Received via mailing list)
Le 13/03/07, Guillaume Betous a écrit :
>
>
> > J'en saurais plus avec le bouquin mais je suis presque sûr que le vacuum
> > est automatique depuis les version 8.x
>
> En tous cas il était présent lors d'une simple installation Gentoo "emerge
> postgresql". Je viens de l'activer...


Depuis la 8.1 c'est un paramètre à activer dans le postgresql.conf :
autovacuum = on
Avant la 8.0 l'autovaccum n'existait pas.
http://www.postgresql.org/docs/8.1/static/maintena...
Bef7ff8a0537495a1876ffebdc9f8e51?d=identicon&s=25 Lionel Bouton (Guest)
on 2007-03-13 14:40
(Received via mailing list)
Frédéric Logier wrote the following on 13.03.2007 14:19 :
>     automatise cela, MySQL a l'avantage de faire ça automatiquement).
>
>
>
> J'en saurais plus avec le bouquin mais je suis presque sûr que le
> vacuum est automatique depuis les version 8.x

Oui, à partir de la 8.1. Mais d'après le 'ps aux' il n'est pas activé
sur l'installation de Guillaume s'il utilise la 8.1. J'ai l'impression
qu'il a une Gentoo (syslog-ng, ce n'est pas si courant que ça comme
démon syslog), donc la 8.1 n'est pas encore dispo dans les versions
stables pour lui.

Lionel
3c75327133edef1a398f48a3566b0f7b?d=identicon&s=25 Frédéric Logier (Guest)
on 2007-03-13 14:45
(Received via mailing list)
Le 13/03/07, Eric Daspet a écrit :
>
>
> Oulà, ça vient peut être de mon expérience, mais pour moi Rails est bien
> plus proche de PHP que de Java. Les sites Web PHP ne sont pas plus
> "vaguement" interactifs que les Java ou Rails.
>

Je ne comprend pas pourquoi tu tiens à comparer PHP et Rails. Compare
Ruby
et PHP, et là l'avantage de Ruby est plutôt faible. Idem pour Java, on
ne
développe pas un site en Java mais on utilise un framework type Struts.
Les
problèmatiques des framework n'ont rien à voir avec celles d'un simple
langage inclus dans Apache via un mod_tonlangage.
Après le tuning d'une plateforme Rails peut être effectivement plus
complexe
qu'un bon vieux framework rodé depuis des années, mais le mieux en
attendant
une amélioration ne serait-il pas de sous-traiter cela à des
spécialistes du
genre Typhon ou Telecom Italia ?
3c75327133edef1a398f48a3566b0f7b?d=identicon&s=25 Frédéric Logier (Guest)
on 2007-03-13 14:50
(Received via mailing list)
Le 13/03/07, Lionel Bouton a écrit :
> stables pour lui.
>

D'après le chan irc #postgresqlfr l'autovaccum n'est plus dans un
process
séparé depuis la 8.1 mais dans le moteur. Donc je doute que tu puisse le
voir dans la liste des process. De plus la 8.2 est sortie depuis peu
avec
certains avantages à la Oracle comme insert into .. returning id :)
Bef7ff8a0537495a1876ffebdc9f8e51?d=identicon&s=25 Lionel Bouton (Guest)
on 2007-03-13 14:59
(Received via mailing list)
Eric Daspet wrote the following on 13.03.2007 14:34 :
> Et à vrai dire je n'ai même pas besoin d'avoir un fork complexe à la
> super-mongrel. Déjà pouvoir adapter le nombre de fils à la charge serait
> super.

Le problème n'est pas Rails alors, mais le serveur web. lighttpd a un
bug dans mod_fastcgi qui bien que permettant la configuration de nombre
de processus fastcgi min et max lance toujours le max. Mais c'est un bug
de lighttpd qui devrait être corrigé, pas un bug de Rails. Je me demande
si Apache et/ou nginx ne gère(nt) pas correctement ce genre de choses.

>  Après si on doit se taper une ou deux requêtes lentes le temps que
> rails initialise tout ce n'est pas le plus gênant.
>

Fais attention que si c'est pour faire du mutualisé, le serveur web
risque de passer plus de temps à lancer des processus qu'à traiter les
requêtes.
Si c'est pour un serveur dédié, je ne vois pas l'intérêt de forker à la
demande, ton serveur a une capacité, la dépasser ne sert à rien et ne
pas pré-lancer un mongrel te coûtera au moment où tu en auras besoin :
dans ce cas on lance le nombre qui correspond à la capacité du serveur
et on ajoute un serveur supplémentaire lorsque le premier est victime du
succès de l'application.
> [...]
> Oulà, ça vient peut être de mon expérience, mais pour moi Rails est bien
> plus proche de PHP que de Java. Les sites Web PHP ne sont pas plus
> "vaguement" interactifs que les Java ou Rails.
>
>

Je parle surtout PHP en tant que Personal Home Page sur serveurs
mutualisés. Après il y a effectivement la catégorie des applications pro
en PHP, mais je ne vois pas l'intérêt du pre-fork dans ce cas là pour
les même raisons que celles évoquées ci-dessus. La signature mémoire est
alors équivalente à celle de Rails.

>> Je ne pourrai tout simplement *pas* héberger une
>> appli J2EE sur mon infrastructure actuelle, ça me coûterait probablement
>> 3 fois plus cher en hébergement.
>>
>
> Oui, peut être (quoi que),

Il n'y a pas de "quoi que", essayer de démarrer une JVM sur un serveur
virtuel n'ayant que 128-160M de RAM libre pour faire tourner un
Jboss/Jonas/Websphere c'est tout simplement une perte de temps.

>  mais les procédures sont claires et les
> déploiements automatisés. Je n'ai pas à installer un proxy, puis décider
> combien de fils lancer, puis me rendre compte que mon serveur ne répond
> pas à certaine parce que même si la charge moyenne est bonne j'ai eu le
> malheur d'avoir N+1 requêtes à un instant T avec seulement N processus.
>
>

Comme indiqué plus haut, cela n'a pas de sens. D'abord lorsque tu es à
N+1 requêtes le serveur ne te jettera pas, il te mettra en attente.
Cette attente n'est pas grave tant que cet un état transient
relativement court. Lorsque ça va jusqu'au timeout ou que ça devient
récurrent/permanent, il y a un vrai problème de charge. A ce moment ton
serveur n'est tout simplement pas assez puissant, point barre.

> Ca c'est franchement bloquant.
> Et d'ailleurs *ça* c'est cher à l'hébergement, car ça demande des
> administrateurs qui manuellement vont toucher à ce genre de détails et
> connaissent l'architecture.
>
>

Pour moi une appli pro vient avec ses procédures
d'install/maintenance/backup/..., ses abaques pour la configuration de
l'infra à tels et tels niveaux de charges. Un admin sys n'a pas à
toucher à ce genre de choses, son boulot c'est de maintenir
l'environnement sous-jacent, de valider puis d'appliquer les procédures
qu'on lui donne.

Lionel.
Bef7ff8a0537495a1876ffebdc9f8e51?d=identicon&s=25 Lionel Bouton (Guest)
on 2007-03-13 15:00
(Received via mailing list)
Frédéric Logier wrote the following on 13.03.2007 14:48 :
>     démon syslog), donc la 8.1 n'est pas encore dispo dans les versions
>     stables pour lui.
>
>
> D'après le chan irc #postgresqlfr l'autovaccum n'est plus dans un
> process séparé depuis la 8.1 mais dans le moteur.

Ils se trompent. Cf doc postgreSQL.
3c75327133edef1a398f48a3566b0f7b?d=identicon&s=25 Frédéric Logier (Guest)
on 2007-03-13 15:14
(Received via mailing list)
Le 13/03/07, Lionel Bouton a écrit :
>
> Frédéric Logier wrote the following on 13.03.2007 14:48 :
>
> > D'après le chan irc #postgresqlfr l'autovaccum n'est plus dans un
> > process séparé depuis la 8.1 mais dans le moteur.
>
> Ils se trompent. Cf doc postgreSQL.
>
>
Alors ce démon ne se lance que lorsque PostgreSQL le juge nécessaire
d'une
part, c'est un process controllé par PostgreSQL. D'autre part, il faut
également activer l'option stats_start_collector. CF la doc ... :)
A83a70aa42afa4c45563213e6ffc03ce?d=identicon&s=25 Eric Daspet (Guest)
on 2007-03-13 15:15
(Received via mailing list)
Le Mar 13 mars 2007 13:21, Frédéric Logier a écrit :
> Personnellement je pense que c'est un faux problème car Rails n'a pas
> vraiment les mêmes objectifs que PHP. Rails est à mon avis clairement
> orienté professionnel. Je ne vois pas le grand public hébergé chez free,
> apprendre l'objet et un modèle MVC juste pour son site perso. Par contre
> un professionnel a largement les moyens d'investir dans un serveur avec
> suffisamment de RAM.

Je déteste ce faux distingo entre public et professionnel. Les contraintes
ne sont pas identiques mais sont plus proches qu'on ne le pense.

Les deux veulent des solutions pas chères, performantes et simples. Le
gros succès de PHP en entreprise tient aussi à ça.

> Rails est au même niveau que Zope ou Java, il
> nécessite un minimum de ressources matériel, et on remarquera que Zope et
> Java ne sont clairement pas utilisé par le public.


Ne disons pas qu'il demande un minimum de ressources matériel dans le même
thread où on débat de difficultés à le faire tourner sur un serveur dédié
d'entrée de gamme. A coté PHP ferait tourner à moindre coût une infinité
de sites sur la même plateforme (la limitation étant la fréquentation, pas
le nombre d'applications PHP).

Certes, Java aussi a de grosses contraintes matérielles, mais Java aussi
apporte par défaut sans rien toucher bien des choses qu'on n'a pas avec
Rails au niveau des services Web, de la connexion avec le métier Java
existant, des transactions XA, des couches métier distantes ...
Du coup on accepte bien plus facilement d'avoir du gros matos sur du
Java,
parce qu'on a pas/peu le choix.

Si on vise du frontal Web uniquement comme Rails, demander des gros
serveurs dans le cadre de petites applis, c'est contre productif.


> Rails s'impose déjà :)

Il ne s'agit pas de dire que Rails est mauvais, je ne serai pas là sinon.
Mais il s'agit de constater qu'il y a encore de très gros défauts. Et pour
moi un serveur qui s'adapte à la charge ça reste dans le domaine et du
besoin et du réalisable (la consommation mémoire c'est une autre affaire).

--
Éric Daspet
http://eric.daspet.name/
A83a70aa42afa4c45563213e6ffc03ce?d=identicon&s=25 Eric Daspet (Guest)
on 2007-03-13 15:20
(Received via mailing list)
Le Mar 13 mars 2007 14:43, Frédéric Logier a écrit :

> Je ne comprend pas pourquoi tu tiens à comparer PHP et Rails. Compare Ruby
> et PHP, et là l'avantage de Ruby est plutôt faible. Idem pour Java, on ne
> développe pas un site en Java mais on utilise un framework type Struts.
> Les problèmatiques des framework n'ont rien à voir avec celles d'un simple
> langage inclus dans Apache via un mod_tonlangage.


Je compare une "solution". Je ne parle pas de framework pour PHP parce
qu'ils n'imposent rien sur l'hébergement (contrairement à Rails). Je ne
voyais pas le but d'en nommer un parce qu'ils sont tous équivalents sur ce
point. Tu peux prendre Symfony si tu veux un exemple.

Le fait est qu'installer un applicatif J2EE ou PHP est bien plus simple
qu'un applicatif Rails.

> le mieux en attendant une amélioration ne serait-il pas de sous-traiter
> cela à des spécialistes du genre Typhon ou Telecom Italia ?

Si, mais c'est bien uniquement ce qui motive mon constat : on a un
problème de ce côté là pour l'instant. Je n'ai rien dit de plus.

--
Éric Daspet
http://eric.daspet.name/
3c75327133edef1a398f48a3566b0f7b?d=identicon&s=25 Frédéric Logier (Guest)
on 2007-03-13 15:30
(Received via mailing list)
Le 13/03/07, Eric Daspet a écrit :
>
Ok sans doute pour des entreprises souhaitant une solution clic and
play.
Mais pour une entreprise ayant fait réellement le choix de Rails prête à
s'investir un minimum car elle voit très bien les avantages que Rails
lui
apporte, je n'y vois aucun problème.
Les problèmes que tu cites concernent plus les hébergements mutualisés
en
Rails, donc par définition destinés à un public non professionnel. En
effet
sur ce type de profil Rails n'est sans doute pas adapté ...
A83a70aa42afa4c45563213e6ffc03ce?d=identicon&s=25 Eric Daspet (Guest)
on 2007-03-13 15:30
(Received via mailing list)
Le Mar 13 mars 2007 14:58, Lionel Bouton a écrit :
> Le problème n'est pas Rails alors, mais le serveur web.

Nous sommes d'accord. Je ne cherchais pas "à qui la faute". Disons que
j'ai un problème "avec Rails", pas forcément à cause de lui.



> Si c'est pour un serveur dédié, je ne vois pas l'intérêt de forker à
> la demande, ton serveur a une capacité, la dépasser ne sert à rien et ne
> pas pré-lancer un mongrel te coûtera au moment où tu en auras besoin


Ah si. Si c'est une application de moyenne importance on va tenter de
mettre deux applications sur le même serveur, donc espérer que l'une
pourra prendre plus quand l'autre est en sommeil, ou, ce qui se fait
énormément en entreprise, faire tourner le serveur sur une machine
virtuelle (donc espérer qu'elle prendra le moins de ressources possible
même si elle a l'impression d'être seule).


> Je parle surtout PHP en tant que Personal Home Page sur serveurs
> mutualisés. Après il y a effectivement la catégorie des applications
> pro en PHP

Je ne fais pas la différence. Pour moi cette différence est
majoritairement un fort égo des architectes professionnels. En pratique
j'ai presque l'impression d'avoir vu les applis les plus pro et complètes
dans le milieu privé plutot que le milieu entreprise.

Ce qui est fait en entreprise est le plus souvent tout aussi simple que
ce
qui est fait en privé, et Rails vise largement cette cible.
Ce qui est fait par 43things ou par nouvelobs / figaro madamme, pour
prendre des référence connues, ce n'est pas du développement en soi
trèscomplexe. Pas tellement plus complexe qu'un moteur de blog complet ou
qu'un forum bien fait.

--
Eric Daspet
http://eric.daspet.name/
9713dd2ed86923b44c78108a2a83f012?d=identicon&s=25 Renaud Morvan (Guest)
on 2007-03-13 15:31
(Received via mailing list)
Le 13 mars 07 à 12:49, Lionel Bouton a écrit :

> Si tu vends Rails en tant que techno pour héberger un site perso chez
> Free, il y a erreur de casting.

C'est clair que comparer une techno comme php à un serveur
d'application comme rails n'est pas du tout avisé. C'est comme
comparer un stockage fichier et un serveur de base de donnée.

Ca ne sera jamais une techno aussi simple et low cost que php parce
qu'il faudra toujours un process persistant et que donc on ne pourra
jamais empiler les sites sur un même serveur comme on le fait avec php.

Néanmoins il y a quand même un défaut majeur avec rails (ruby...)
c'est son incapacité à gérer le multithread et tant que ce sera le
cas et qu'en attendant il n'y a aura pas de vraie solution pour gérer
le nombre de process actif en fonction de la charge et bien la
situaton ne changera pas.

Maintenant Lionel a raison il faut savoir remettre les choses dans
leur contexte. Rails scale très bien en terme technique et financier.
Dans un contexte professionnel l'hébergement Rails peut être
considéré comme peu onéreux. C'est uniquement au niveau du grand
publique que ca pose problème, pas plus qu'avec Java il n'y aura
jamais d'hébergement rails quasi gratos comme il y a pu en avoir avec
php (et qui a tendance à disparaitre à cause des cms mamouthesques
qui sont maintenant la norme).

Renaud_______________________________________________
Railsfrance mailing list
Railsfrance@rubyonrails.fr
http://lists.rubyonrails.fr/mailman/listinfo/railsfrance
9713dd2ed86923b44c78108a2a83f012?d=identicon&s=25 Renaud Morvan (Guest)
on 2007-03-13 15:39
(Received via mailing list)
Le 13 mars 07 à 11:54, Jérémy Dierx a écrit :

> Bonjour,
>
> A titre de comparaison, voici ma config sur dédié :
>
> mysql    11413  0.0  1.8 78468 18976 ?       S    Mar07   0:02 /usr/
> sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --
> pid-file=/var/run/mysqld/mysqld.pid --skip

11 process mysql
>
> root     25394  0.0  3.0 32536 30860 ?       S    Mar08   0:19 /usr/
> local/bin/ruby /usr/local/bin/mongrel_rails start -d -e production -
> p 8002 -a 127.0.0.1 -P log/mongrel.8002.p
> root     12832  0.0  3.0 32504 30876 ?       S    Mar08   0:18 /usr/
> local/bin/ruby /usr/local/bin/mongrel_rails start -d -e production -
> p 8003 -a 127.0.0.1 -P log/mongrel.8003.p
>

2 mongrels

>>  /usr/sbin/mysql mysql 20526 0.0 13.0 94036 28944 ?

11 process mysql

>> /usr/bin/ruby18root 11378 0.0 14.4 36040 32020 ? S Mar12 0:06

2 process mongrels

Petite remarque sur ces deux configs

1) vous avez 5 fois plus de daemon mysql qui attendent que de process
mongrel qui déserve, c'est comme d'avoir 2 avions de lignes et 11
pistes d'atterissage, du pure gachi surtout sur une config avec 256
Meg de ram

Rails est un serveur d'application non multithread, chaque process a
sa propre connexion qu'il fait persister et l'utilise de facon
synchrone donc rails n'en utilise jamais plus que 2 à la fois !!

2) Mongrel a l'air de tourner en root et c'est franchement pas du
tout une bonne
idée
C211e4b403330c86c56db30357a2b64c?d=identicon&s=25 Guillaume Betous (Guest)
on 2007-03-13 15:44
(Received via mailing list)
> 11 process mysql

si tu sais ou on peut regler ça, je suis preneur...

> 2) Mongrel a l'air de tourner en root et c'est franchement pas du tout
> une bonne idée

oui, c'est vrai. c'est du temporaire, mais en effet, c'est pas bien (c)

gUI

--
Guillaume Betous : (05 61) 19 40 65 / bureau 602N
Fd608c2b5ba7896b449e26fcf18b70b4?d=identicon&s=25 Zambra (Guest)
on 2007-03-13 17:28
(Received via mailing list)
> Les problèmes que tu cites concernent plus les hébergements mutualisés
> en Rails, donc par définition destinés à un public non professionnel. En
> effet sur ce type de profil Rails n'est sans doute pas adapté ...

J'ai un peu le même sentiment qu'E. Daspet à propos de Rails, ou plus
exactement les solutions d'hébergement, ce qui est intimement lié. Rails
est quand même "vendu" comme un "php killer" par DHH à travers ses
screencasts. Et je ne trouve pas déplacé de comparer Rails à php dans la
mesure ou ce dernier ne permet (quasiment) que du développement web,
même si techniquement il faut le comparer à des frameworks comme
symphony.

L'essentiel des entreprises sont des PME avec des besoins assez limités,
les projets à 150000€ ne sont pas majoritaires, il y a donc à mon avis
un réel besoin pour des projets plus modestes bénéficiant tout de même
des avantages d'un développement ruby/rails (mvc, syntaxe agréable,
tests...)
3c75327133edef1a398f48a3566b0f7b?d=identicon&s=25 Frédéric Logier (Guest)
on 2007-03-13 17:43
(Received via mailing list)
Le 13/03/07, Zambra a écrit :
>
> L'essentiel des entreprises sont des PME avec des besoins assez limités,
> les projets à 150000€ ne sont pas majoritaires, il y a donc à mon avis
> un réel besoin pour des projets plus modestes bénéficiant tout de même
> des avantages d'un développement ruby/rails (mvc, syntaxe agréable,
> tests...)
>
>
Heu perso j'utilise en production une dédibox à 30€ HT/mois ... Maximum
100€
/mois chez OVH.
C'est un peu le danger des perfectionnistes qui sont souvent mal
compris, et
les gens comprennent : Rails c'est bien pour des projets à partir de
150K€
... :)
Par contre il faut quelqu'un qui sache administrer un serveur Linux et
la
config Rails. Mais le problème est le même pour une entreprise qui
décide de
gérer elle-même ses serveurs.
Ce que veux dire Eric c'est qu'il n'est pas aisé, pour une entreprise
qui
souhaite proposer de l'hébergement mutualisé, d'optimiser au mieux ses
ressources matériels.
Cependant un prestataire spécialisé pourra sans problème effectuer ce
travail sur un serveur dédié, ou simplement un salarié administrateur
Linux.
997433f165140d58f52b8c0d1d005dc1?d=identicon&s=25 Patrick Aljord (Guest)
on 2007-03-13 19:29
(Received via mailing list)
On 3/13/07, Frédéric Logier <fredix@gmail.com> wrote:
> Heu perso j'utilise en production une dédibox à 30€ HT/mois ... Maximum 100€
> /mois chez OVH.
> C'est un peu le danger des perfectionnistes qui sont souvent mal compris, et
> les gens comprennent : Rails c'est bien pour des projets à partir de 150K€
> ... :)
Je ne pense pas que rails ce soit bien uniquement pour les projets à
partir de 150K€.
Exemple: une application de gestion de stock/facturation/sav/prises de
commandes/ventes/achats/avoirs en rails utilisée en interne uniquement
par une PME donc pas plus d'une centaine d'utilisateurs par jours.
Dans ce cas, un serveur Kimsufi suffit largement (sans mauvais jeux de
mots), on peut même faire tourner l'application sur un serveur en
interne. Hors une petite application comme celle-là ne vaut même pas
10k€ (j'en ai fait une en une semaine :) et je suis sur qu'on peut
faire beaucoup mieux :D)

Rails c'est fait pour faire des applications en réseaux, pas forcément
des sites web2.0, et là c'est super rentable parceque l'application tu
la développes de manière super rapide et pour un coup minimum niveau
hardware (n'importe quel serveur suffit) comme software (rails, apache
mongrel etc c'est gratuit).

Après c'est sûr que si tu veux faire un site web qui accueillera des
millions de visiteurs là il faut prévoir une architecture hardware
béton mais ce se sera pareil pour du php et du java.

Et en ce qui concerne du mutualisé gratuit ou quasi-gratuit, ça existe
déjà!
http://www.railsplayground.com/
http://www.hostingrails.com/
http://www.soyhost.com/


et pour ceux qui ont des problèmes de RAM et MySQL, n'oubliez pas de
chacher à fond tous que vous pouvez :D

Pour finir, c'est vrai que Ruby ne gère pas les thread (pour
l'instant), mais avec mongrel il y a le plugin fastthread qui résoud
pas mal le problème.
A817be4bff5c9ba9c9282a0dce77bd6a?d=identicon&s=25 Jérémy Dierx (Guest)
on 2007-03-15 07:50
(Received via mailing list)
Le mardi 13 mars 2007 à 15:34 +0100, Renaud Morvan a écrit :
2) Mongrel a l'air de tourner en root et c'est franchement pas du
tout une bonne idée

Merci pour le conseil :-)  j'ai maintenant changé le user des process
mongrel à mon user personnel.

Pour éviter à d'autre de chercher comment faire, dans le fichier de
config mon_appli.yml spécifique à l'appli et déstiné à mongrel, il faut
ajouter :

user: mon_user
group: mon_group


1) vous avez 5 fois plus de daemon mysql qui attendent que de process
mongrel qui déserve, c'est comme d'avoir 2 avions de lignes et 11
pistes d'atterissage, du pure gachi surtout sur une config avec 256
Meg de ram

Là, je comprends pas trop, je n'ai pas configuré mysql_multi, j'ai
simplement installé mysql par les paquets dispo... et je me retrouve
avec plein de petits gremlins mysqld :-O
Si quelqu'un peut m'expliquer ? Et me dire comment en arrêter quelques
uns ?


Jérémy.
2e8023fd681e1653a33a396260a30493?d=identicon&s=25 Guillaume "Zifro" DESRAT (Guest)
on 2007-03-15 12:57
(Received via mailing list)
Le 13/03/07, Renaud Morvan<renaud.morvan@feedback20.com> a écrit :

> Néanmoins il y a quand même un défaut majeur avec rails (ruby...)
> c'est son incapacité à gérer le multithread et tant que ce sera le
> cas et qu'en attendant il n'y a aura pas de vraie solution pour gérer
> le nombre de process actif en fonction de la charge et bien la
> situaton ne changera pas.

Ruby gère le multithread, actuellement en interne (dans
l'interpréteur), mais je crois pouvoir affirmer sans me tromper qu'il
est justement prévu pour Ruby 2.0 d'utiliser des threads POSIX.
Courage, encore un an ou deux !

--
Guillaume "Zifro" DESRAT
Secrétaire de l'association Ruby France
http://www.rubyfrance.org/
9713dd2ed86923b44c78108a2a83f012?d=identicon&s=25 Renaud Morvan (Guest)
on 2007-03-15 14:47
(Received via mailing list)
Le 15 mars 07 à 12:55, Guillaume Zifro DESRAT a écrit :

> est justement prévu pour Ruby 2.0 d'utiliser des threads POSIX.
> Courage, encore un an ou deux !

Je n'ai pas dis le contraire, à ma connaissance le problème actuel se
situe à 2 niveaux:

-L'implémentation actuelle de rails ne supporte le multithread que
sur une petite partie du code (les scopes par exemple). C'est un
nasty little secret et aucune action pour remédier à cela n'est
planifié pour l'instant. (+ d'info sur http://rubyforge.org/pipermail/
mongrel-users/2006-May/000302.html ) Une des raisons du faible
intéret du core pour cela est sans doute lié au faible gain en
perspective (cf la suite).

-L'implémentation actuelle des thread dans ruby est pas mal décriée.
Pas mal de projet sérieux qui gère la concurrence commence par
utiliser les thread ruby et finisse par passer à une autre solution,
mongrel qui implémente maintenant son propre système de thread,
backgroundrb qui est passé en multiprocess... Je n'ai jamais
expérimenté ni rien lu à ce propos de très concret sur le pourquoi du
comment, si ce n'est qu'effectivement pour maximiser la compatibilité
cross plateform ruby n'a pas utilisé de thread natif mais implémente
sa propre solution logicielle. J'imagine qu'une partie du problème
est donc lié à une performance déplorable de l'implémentation des
threads actuels qui de ce fait n'aurait aucun intéret pour rails mais
là je spécule. Si tu as plus d'information je suis preneur, c'est
vraiment une question qui m'intrigue et plutôt inquiétante.

Renaud_______________________________________________
Railsfrance mailing list
Railsfrance@rubyonrails.fr
http://lists.rubyonrails.fr/mailman/listinfo/railsfrance
3c75327133edef1a398f48a3566b0f7b?d=identicon&s=25 Frédéric Logier (Guest)
on 2007-03-15 15:00
(Received via mailing list)
Le 15/03/07, Renaud Morvan a écrit :
>
>
>
> Pas mal de projet sérieux qui gère la concurrence commence par
> utiliser les thread ruby et finisse par passer à une autre solution,


Tout le monde sait qu'un projet sérieux qui souhaite être hautement
concurrent utilise Erlang ;)

Sinon il me semble avoir lu que les threads systèmes sont prévu pour
Ruby2.
A voir du côté de la version dev 1.9
A99870c1391c39da2089649745965bda?d=identicon&s=25 Jean-François Trân (Guest)
on 2007-03-15 16:26
(Received via mailing list)
Renaud :

quelques remarques...

> Je n'ai pas dis le contraire, à ma connaissance le problème actuel
> se situe à 2 niveaux:
>
> -L'implémentation actuelle de rails ne supporte le multithread que
> sur une petite partie du code (les scopes par exemple).

ActiveRecord est sensé être thread safe. Merb qui est
multithreadé,peut utiliser AR.

> C'est un nasty little secret et aucune action pour remédier à cela n'est
> planifié pour l'instant. (+ d'info sur http://rubyforge.org/pipermail/
> mongrel-users/2006-May/000302.html ) Une des raisons du faible
> intéret du core pour cela est sans doute lié au faible gain en
> perspective (cf la suite).
>
> -L'implémentation actuelle des thread dans ruby est pas mal
> décriée. Pas mal de projet sérieux qui gère la concurrence commence
> par utiliser les thread ruby et finisse par passer à une autre solution,
> mongrel qui implémente maintenant son propre système de thread,

Ah bon ?

Zed Shaw encourage l'utilisation de la lib fastthread de MenTalguY,
mais celle-ci n'est pas spécifique à Mongrel. De plus, fastthread
a été mergé dans la branche 1.8 ; ainsi par exemple, il est utilisé
par défaut dans 1.8.6, on peut désactiver ce comportement dans
une option de configure.

> backgroundrb qui est passé en multiprocess... Je n'ai jamais
> expérimenté ni rien lu à ce propos de très concret sur le pourquoi
> du comment, si ce n'est qu'effectivement pour maximiser la
> compatibilité cross plateform ruby n'a pas utilisé de thread natif
> mais implémente sa propre solution logicielle.

Sans rentrer dans le débat threads natifs vs. green threads,
je rappellerai qu'au départ (les spécialistes Java me corrigeront),
Java implémentait son système de green threads.

A ce propos, JRuby utilise les threads Java et non les threads
Ruby.

   -- Jean-François.
9713dd2ed86923b44c78108a2a83f012?d=identicon&s=25 Renaud Morvan (Guest)
on 2007-03-15 17:13
(Received via mailing list)
Le 15 mars 07 à 16:25, Jean-François Trân a écrit :

> ActiveRecord est sensé être thread safe. Merb qui est multithreadé,
> peut utiliser AR.
J'ai eu personnellement avec AR les mêmes problèmes que zed souligne
en ce qui concerne les connexions sql qui ne sont pas fermé et ne
passe pas dans le GC. Ce qui est particulièrement énervant puisque un
daemon comme mysql n'autorise plus les connexions une fois qu'on a
dépassé le maximum. http://rubyforge.org/pipermail/backgroundrb-devel/
2006-October/000445.html

Donc ca reste assez relatif. Mais je suis d'accord avec toi AR est ce
qui me semble le plus multithreadé dans rails, c'est également celui
qui est le plus difficile à rendre vraiment multithread. Maintenant
si tu commences à faire des trucs un peu amusant comme de redéfinir
des réflexions à la volée tu vas avoir de mauvaise surprise car tout
est stockée sous forme de variable de classe.

> mais celle-ci n'est pas spécifique à Mongrel.
Fastthread n'est pas spécifique à mongrel mais surtout n'est pas codé
en ruby, c'est du compilé. Ca marche avec ruby, ca implémente des
threads pour ruby, ce n'est pas codé avec ruby, c'est bien un
workaround :)


> De plus, fastthread
> a été mergé dans la branche 1.8 ; ainsi par exemple, il est utilisé
> par défaut dans 1.8.6, on peut désactiver ce comportement dans
> une option de configure.

Alors ca c'est super, je ne le savais pas. Content que ca avance dans
le bon sens même avant la 2.0. On aura peut-être pas besoin
d'attendre deux ans alors, en attendant retour à la réalité et à la
gestion manuelle de process mongrel, ou à fcgi :).
8a85c693f13ef7cb542ef94d2a403d4d?d=identicon&s=25 Luc Heinrich (Guest)
on 2007-03-15 23:45
(Received via mailing list)
On 15 mars 07, at 17:09, Renaud Morvan wrote:

> Ca marche avec ruby, ca implémente des threads pour ruby

Absolument pas. fastthread accélère l'exécution des green-threads
ruby, il ne les remplace pas. Il ne fait "que" remplacer les
implémentations des classes Mutex, ConditionVariable, Queue et
SizedQueue par des version plus rapides et fixe au passage de gros
leaks.

> ce n'est pas codé avec ruby, c'est bien un workaround :)

Ce n'est pas un workaround, c'est un fix.

--
Luc Heinrich
This topic is locked and can not be replied to.