Template de site pour PME

JKB <knatschke@koenigsberg.fr> wrote:

J'utilise la JVM (la dernière) de monsieur Sun à la fois sur du
Linux X86-64 (machines Sun/SMP) et sur du Solaris 10
(UltraSPARC/SMP). Je n'ai pour l'instant jamais vu une JVM occuper
deux processeurs, et pourtant, cela m'arrangerait bien. Le support
multithread est _interne_ à la JVM et ne concerne pas le système
sous-jacent. Ou alors j'ai raté un truc dans la doc, mais je ne suis
pas le seul.

Tu as découvert qu'on pouvait compiler la JVM soit avec des "green threads"
soit avec des "native threads"? Quand tu lances le moindre JBoss il te
fabrique une bonne trentaine de threads, et de fait ils se répartissent les
processeurs.
Mais enfin je dois dire que chez toi rien ne marche comme chez tout le monde.

Donc là je te montre un exemple, sur ma machine (FreeBSD) ayant lancé "resin"
10721 michel 96 0 253M 87812K select 1 0:17 0.00% 0.00% java
10721 michel 96 0 253M 87812K select 1 0:17 0.00% 0.00% java
10721 michel 96 0 253M 87812K select 0 0:17 0.00% 0.00% java
10721 michel 96 0 253M 87812K select 0 0:17 0.00% 0.00% java
10721 michel 96 0 253M 87812K select 0 0:17 0.00% 0.00% java
10721 michel 96 0 253M 87812K select 0 0:17 0.00% 0.00% java
10721 michel 96 0 253M 87812K select 1 0:17 0.00% 0.00% java
10721 michel 96 0 253M 87812K select 0 0:17 0.00% 0.00% java
10721 michel 96 0 253M 87812K select 0 0:17 0.00% 0.00% java
10721 michel 20 0 253M 87812K kserel 1 0:17 0.00% 0.00% java
10721 michel 20 0 253M 87812K kserel 0 0:17 0.00% 0.00% java
10721 michel 20 0 253M 87812K ksesig 0 0:17 0.00% 0.00% java
10721 michel 16 0 253M 87812K select 0 0:17 0.00% 0.00% java
10721 michel 16 0 253M 87812K select 0 0:17 0.00% 0.00% java
10721 michel 16 0 253M 87812K select 1 0:17 0.00% 0.00% java
Comme tu peux voir il y a des threads sur le processeur 0 et d'autres sur le
1. Bien entendu il y a un seul processus java, ayant créé ces threads.

JKB

--

Michel TALON

Merci pour ces indications (et celles qui précédaient). Mais pour
autant que je peux voir les solutions comme Zope et Plone sont des
trucs de près ou de loin de professionnels. Ici je pense à des amis
qui font un site (affreux), dont ce n'est pas le boulot, qui ne
pourront pas maîtriser une solution complexe ; est-ce que pour les
gens comme ça il existe des "patrons" de site (pas des systèmes de
publication en général), où il suffit à la rigueur de personnaliser
des champs (genre nom de la boîte, adresse), de rajouter le contenu et
les pages que l'on souhaite, et qui en fait un site plus ou moins
personnalisable mais déjà fonctionnel et pas trop laid ?

On 2006-05-06, Michel Talon <talon@lpthe.jussieu.fr> wrote:

100 fois plus lent ça correspond à ce que j'ai mesuré sur quelques exemples.

C'est marrant, on avait fait des tests en comparant des programmes en C
et en Perl pour faire de la REGEX et il en sortait que Perl etait plus
rapide.

On pourrait dire 100 fois, 1000 fois ... c'est une question de contexte
et de bonne foie pour reconnaitre que les performances brutes d'un
language n'ont rien a voir la dedans.

Outre ces questions python a un support assez rudimentaire des threads, ce
qui fait que chaque fois qu'on rentre dans un module écrit en C il ne peut y
avoir changement de thread. Autant dire qu'une machine avec beaucoup de
processeurs ne va pas faire gagner grand chose. Je crois que c'est une des
qualités de perl d'avoir un meilleur support dans ce domaine. Et bien sûr
java d'autant plus.

Et tu penses que tu vas gagner en credibilite en pretendant que Perl a
une meilleur gestion du multi-threading que Python ? alors meme que
creer un thread en Perl est plus long que creer un nouveau process.


--
http://www.unices.org Photos, humour et autres blogueries
http://www.pbase.com/stougard/ Pfff, encore des photos

Le 06-05-2006, à propos de
Re: Template de site pour PME,
Michel Talon écrivait dans fr.comp.os.linux.debats :

JKB <knatschke@koenigsberg.fr> wrote:

J'utilise la JVM (la dernière) de monsieur Sun à la fois sur du
Linux X86-64 (machines Sun/SMP) et sur du Solaris 10
(UltraSPARC/SMP). Je n'ai pour l'instant jamais vu une JVM occuper
deux processeurs, et pourtant, cela m'arrangerait bien. Le support
multithread est _interne_ à la JVM et ne concerne pas le système
sous-jacent. Ou alors j'ai raté un truc dans la doc, mais je ne suis
pas le seul.

Tu as découvert qu'on pouvait compiler la JVM soit avec des "green threads"
soit avec des "native threads"? Quand tu lances le moindre JBoss il te
fabrique une bonne trentaine de threads, et de fait ils se répartissent les
processeurs.
Mais enfin je dois dire que chez toi rien ne marche comme chez tout le monde.

Donc là je te montre un exemple, sur ma machine (FreeBSD) ayant lancé "resin"
10721 michel 96 0 253M 87812K select 1 0:17 0.00% 0.00% java
10721 michel 96 0 253M 87812K select 1 0:17 0.00% 0.00% java
10721 michel 96 0 253M 87812K select 0 0:17 0.00% 0.00% java
10721 michel 96 0 253M 87812K select 0 0:17 0.00% 0.00% java
10721 michel 96 0 253M 87812K select 0 0:17 0.00% 0.00% java
10721 michel 96 0 253M 87812K select 0 0:17 0.00% 0.00% java
10721 michel 96 0 253M 87812K select 1 0:17 0.00% 0.00% java
10721 michel 96 0 253M 87812K select 0 0:17 0.00% 0.00% java
10721 michel 96 0 253M 87812K select 0 0:17 0.00% 0.00% java
10721 michel 20 0 253M 87812K kserel 1 0:17 0.00% 0.00% java
10721 michel 20 0 253M 87812K kserel 0 0:17 0.00% 0.00% java
10721 michel 20 0 253M 87812K ksesig 0 0:17 0.00% 0.00% java
10721 michel 16 0 253M 87812K select 0 0:17 0.00% 0.00% java
10721 michel 16 0 253M 87812K select 0 0:17 0.00% 0.00% java
10721 michel 16 0 253M 87812K select 1 0:17 0.00% 0.00% java
Comme tu peux voir il y a des threads sur le processeur 0 et d'autres sur le
1. Bien entendu il y a un seul processus java, ayant créé ces threads.

Je dois être un sombre crétin mais avec la JVM de Sun (je n'ai pas
recompilé d'une par parce que je ne sais pas s'il y a les sources de
disponibles et d'autre part parce que je n'ai pas que ça à faire).

Proc.
20603 jcollab 18 0 3568m 578m 15m S 0 14.7 0:02.60 1 java
20604 jcollab 16 0 3568m 578m 15m S 0 14.7 0:00.02 1 java
20605 jcollab 16 0 3568m 578m 15m S 0 14.7 0:00.02 0 java
20606 jcollab 16 0 3568m 578m 15m S 0 14.7 0:00.02 0 java
20607 jcollab 16 0 3568m 578m 15m S 0 14.7 0:00.00 0 java
20608 jcollab 16 0 3568m 578m 15m S 0 14.7 0:00.02 0 java
20609 jcollab 18 0 3568m 578m 15m S 0 14.7 0:00.00 1 java
20610 jcollab 16 0 3568m 578m 15m S 0 14.7 0:00.02 1 java
20611 jcollab 17 0 3568m 578m 15m S 0 14.7 0:03.52 1 java
20612 jcollab 16 0 3568m 578m 15m S 0 14.7 0:04.38 0 java
20613 jcollab 16 0 3568m 578m 15m S 0 14.7 0:00.00 0 java
20614 jcollab 15 0 3568m 578m 15m S 0 14.7 0:00.00 0 java
20618 jcollab 16 0 3568m 578m 15m S 0 14.7 0:00.00 0 java
20621 jcollab 16 0 3568m 578m 15m S 0 14.7 0:00.63 1 java
20622 jcollab 16 0 3568m 578m 15m S 0 14.7 0:00.00 0 java
20623 jcollab 17 0 3568m 578m 15m S 0 14.7 0:00.02 1 java
20624 jcollab 16 0 3568m 578m 15m S 0 14.7 0:00.00 1 java
20707 jcollab 16 0 1879m 235m 15m S 0 6.0 0:02.52 0 java
20711 jcollab 15 0 1879m 235m 15m S 0 6.0 0:00.03 0 java
20712 jcollab 15 0 1879m 235m 15m S 0 6.0 0:00.00 1 java
20715 jcollab 16 0 1879m 235m 15m S 0 6.0 0:00.00 0 java
20716 jcollab 15 0 1879m 235m 15m S 0 6.0 0:00.00 0 java
20717 jcollab 15 0 1879m 235m 15m S 0 6.0 0:00.00 0 java
20718 jcollab 17 0 1879m 235m 15m S 0 6.0 0:00.00 1 java
20719 jcollab 16 0 1879m 235m 15m S 0 6.0 0:00.03 1 java
20720 jcollab 20 0 1879m 235m 15m S 0 6.0 0:04.04 0 java
20721 jcollab 16 0 1879m 235m 15m S 0 6.0 0:01.56 0 java
20722 jcollab 18 0 1879m 235m 15m S 0 6.0 0:00.00 1 java
20723 jcollab 15 0 1879m 235m 15m S 0 6.0 0:00.00 0 java
20792 jcollab 16 0 1879m 235m 15m S 0 6.0 0:00.00 1 java
20818 jcollab 16 0 1879m 235m 15m S 0 6.0 0:00.53 1 java
20819 jcollab 16 0 1879m 235m 15m S 0 6.0 0:00.00 0 java
20820 jcollab 16 0 1879m 235m 15m S 0 6.0 0:00.00 0 java
20821 jcollab 16 0 1879m 235m 15m S 0 6.0 0:00.00 0 java
20822 jcollab 16 0 1879m 235m 15m S 0 6.0 0:00.00 0 java
20823 jcollab 16 0 1879m 235m 15m S 0 6.0 0:00.00 0 java
1869 mysql 16 0 156m 51m 4924 S 0 1.3 0:01.53 2 mysqld
1871 mysql 18 0 156m 51m 4924 S 0 1.3 0:00.00 3 mysqld
1872 mysql 17 0 156m 51m 4924 S 0 1.3 0:00.00 7 mysqld
1873 mysql 15 0 156m 51m 4924 S 0 1.3 0:00.00 6 mysqld

...

ovide:[~] > cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 5
model name : AMD Opteron(tm) Processor
stepping : 10
cpu MHz : 1992.141
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm
3dnowext 3dnow
bogomips : 3989.53
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp
...
processor : 7
vendor_id : AuthenticAMD
cpu family : 15
model : 5
model name : AMD Opteron(tm) Processor
stepping : 10
cpu MHz : 1992.141
cache size : 1024 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm
3dnowext 3dnow
bogomips : 3989.53
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

J'ai deux JVM de sun qui tournent, une par processeur, et je peux
faire comme je veux, les six autres procs ne servent qu'à la
gestion de base de données. Mais je pense que les gens de chez Sun
sont des imbéciles qui ne savent pas compiler leur propre JVM et que
la machine en question est une sombre merde puisqu'elle n'a que 16
Go de mémoire pour faire tourner deux JVM. Sans doute pas suffisant
comme conf pour que les processus des JVM se mettent sur plus d'un
proc.

JKB

stephane@unices.org <stephane@unices.org> wrote:

On 2006-05-06, Michel Talon <talon@lpthe.jussieu.fr> wrote:

100 fois plus lent ça correspond à ce que j'ai mesuré sur quelques exemples.

C'est marrant, on avait fait des tests en comparant des programmes en C
et en Perl pour faire de la REGEX et il en sortait que Perl etait plus
rapide.

Oui, je sais tu vas nous ressortir ce serpent de mer stupide, quand tu fais
tourner ton programme à base de regexp tu fais du compilé sans arrêt, tu
n'interprètes presque jamais du perl, donc évidemment ça va aussi vite ou plus
vite que du C, vu que les regexp de perl ont été optimisés à fond. Moi
je fais tourner un programme qui ne fait que du perl (ou du python), qui
passe sont temps à l'interpréter, et ça c'est 100 fois plus lent.

On pourrait dire 100 fois, 1000 fois ... c'est une question de contexte
et de bonne foie pour reconnaitre que les performances brutes d'un
language n'ont rien a voir la dedans.

Vu ce que tu as compris du fonctionnement des regexp en perl je doute fort que
tu ais enfin compris quelque chose de significatif ici. Mais pour une fois
il y a une once de vérité dans ce que tu dis. La plupart des programmes sont
ralentis par les accés réseau, les accés base de données, etc. ce qui fait que
les performances brutes du langages interprété ne sont pas trés importantes.
C'est pour ça qu'on peut faire des tas de choses en python ou en perl, mais
il n'en reste pas moins que quand on veut des performances maximales, monter
à forte charge, là ça commence à jouer un rôle.

Outre ces questions python a un support assez rudimentaire des threads, ce
qui fait que chaque fois qu'on rentre dans un module écrit en C il ne peut y
avoir changement de thread. Autant dire qu'une machine avec beaucoup de
processeurs ne va pas faire gagner grand chose. Je crois que c'est une des
qualités de perl d'avoir un meilleur support dans ce domaine. Et bien sûr
java d'autant plus.

Et tu penses que tu vas gagner en credibilite en pretendant que Perl a
une meilleur gestion du multi-threading que Python ? alors meme que
creer un thread en Perl est plus long que creer un nouveau process.

J'ai dit, "je crois que" vu que je ne connais que très très peu le perl.
J'ai entendu dire que perl avait un meilleur support des threads que python,
c'est tout. En python il y a un verrou global qui fait que quand on entre
dans une extension (un module compilé en C) elle va jusqu'au bout sans pouvoir
être interrompue par un autre "thread" python. Ce qui fait que si cette
extension met longtemps à s'exécuter tout le reste est paralysé, alors que le
but du threading était justement de faire croire que le reste du programme
continuait à tourner. Par exemple un thread fait des requêtes DNS, tandis
qu'un autre gère l'affichage. Si ta requête DNS met des plombes à revenir
et bloque l'affichage, tu as l'impression que ton programme est figé, et ça
c'est désastreux.

--

Michel TALON

JKB <knatschke@koenigsberg.fr> wrote:

Je dois être un sombre crétin mais avec la JVM de Sun (je n'ai pas
recompilé d'une par parce que je ne sais pas s'il y a les sources de
disponibles et d'autre part parce que je n'ai pas que ça à faire).

Je ne prétends pas que tu es un sombre crétin, moi je t'ai montré ce que donne
la JVM de Sun, recompilée sur FreeBSD par moi même avec les défauts de
FreeBSD. C'est bien trop compliqué pour que j'aille touiller quoi que ce soit
dans cette compilation. J'avais un seul programme (resin,
http://www.caucho.com/ ) comme tu peux le voir au fait que le PID était le
même pour toutes les instances de java (oui, ça doit être comme ça pour un
programme multithreadé selon la norme, et non pas comme ci dessous), j'ai
demandé à top d'afficher les threads (option H chez moi) et ma machine
est un bête Pentium4 avec hyperthread, qui donc est vue comme un biproc par
FreeBSD. Tu as pu voir que les threads étaient répartis sur les deux procs
par le scheduler. Incidemment c'est le scheduler qui est responsable de ça et
pas java, à partir du moment où java lance des vrais threads vus comme
tels par l'OS et non pas des "green threads" qui sont des threads simulés
dans un seul processus (le genre de threads que lance par exemple python
d'aprés ce que j'ai compris).

Proc.
20603 jcollab 18 0 3568m 578m 15m S 0 14.7 0:02.60 1 java
20604 jcollab 16 0 3568m 578m 15m S 0 14.7 0:00.02 1 java
20605 jcollab 16 0 3568m 578m 15m S 0 14.7 0:00.02 0 java
20606 jcollab 16 0 3568m 578m 15m S 0 14.7 0:00.02 0 java
20607 jcollab 16 0 3568m 578m 15m S 0 14.7 0:00.00 0 java
20608 jcollab 16 0 3568m 578m 15m S 0 14.7 0:00.02 0 java

J'ai deux JVM de sun qui tournent, une par processeur, et je peux
faire comme je veux, les six autres procs ne servent qu'à la
gestion de base de données. Mais je pense que les gens de chez Sun
sont des imbéciles qui ne savent pas compiler leur propre JVM et que
la machine en question est une sombre merde puisqu'elle n'a que 16
Go de mémoire pour faire tourner deux JVM. Sans doute pas suffisant
comme conf pour que les processus des JVM se mettent sur plus d'un
proc.

Je ne pense rien de tel, je pense que quelque chose est mal configuré dans
ton installation, et que tu utilises des "green threads".
Ou alors le scheduler de Linux est trés subtil et juge qu'il n'a pas intérêt
à répartir les threads sur tous les processeurs pour des raisons de pollution
du cache, affinité processeur, etc.

JKB

--

Michel TALON

Le Sat, 06 May 2006 22:38:14 +0200, Patrice Karatchentzeff a écrit :

et attention quand Perl 6 va sortir :)

Perl 6 existe. C'est pas encore exploitable en production sérieusement,
mais on peut largement coder en Perl 6. Et certaines fonctionnalités de
Perl6 commencent à filtrer doucement dans le 5, via CPAN (voir le
merveilleux Moot par exemple).

--
"Dope will get you through times of no money better
than money will get you through times of no dope."
Freewheelin' Franklin

Le Sun, 07 May 2006 08:41:29 +0800, stephane@unices.org a écrit :

Et tu penses que tu vas gagner en credibilite en pretendant que Perl a
une meilleur gestion du multi-threading que Python ? alors meme que
creer un thread en Perl est plus long que creer un nouveau process.

Ah non, pas avec 5.8.8. Les threads ne sont plus expérimentaux dans
thread depuis un moment déjà.

--
Pluralitas non est ponenda sine necessitate.
Guillaume d'Ockham.

Le Sat, 06 May 2006 23:50:41 +0200, SL a écrit :

de rajouter le contenu et
les pages que l'on souhaite, et qui en fait un site plus ou moins
personnalisable mais déjà fonctionnel et pas trop laid ?

Oui, mais qu'est ce que ça à à voir avec ce newsgroup, au lieu de
fr.comp.infosystemes.www.* ?

Il y a des sites qui fournissent des patrons comme www.oswd.org, et des
logiciels wysiwyg pour faire du dév web genre NVU. Mais rien à faire, il
faudra mettre un peu les mains dans le HTML.

--
Sutor ne ultra Crepidam.

On 2006-05-07, Emmanuel Florac <eflorac@imaginet.fr> wrote:

Ah non, pas avec 5.8.8. Les threads ne sont plus expérimentaux dans
thread depuis un moment déjà.

Mes tests de performances datent de 5.8.5 et tres franchement, le
multi-threading dans Perl avait quelque chose de risible lorsqu'on
sous-entendait performance.

Valait encore mieux faire du multi-process et gerer les lock et les IPC
via des fichiers.

Et c'est pas un troll, j'adore Perl plus que tout autre langage, mais je
m'avance pas a le considerer bon la ou il ne l'est pas.

--
http://www.unices.org Photos, humour et autres blogueries
http://www.pbase.com/stougard/ Pfff, encore des photos