forc3 a écrit 51 commentaires

Il existe bien d'autres CMS autrement plus performant que les principaux connus,
mais la majeure différence c'est qu'ils sont difficilement déployables chez les hébergeurs...
Les langages ou les sgbd qu'ils utilisent sont plus rarement disponibles.

Un CMS très performant est par exemple [http://zotonic.com].
Développé par et pour des professionels. Ecrit en erlang et à la pointe des technologies
"2.0": jquery, websockets, twitter, django templates...

Les features: [http://zotonic.com/features] et un petite video [http://zotonic.com/page/750/video-introduction-to-zotonic]

Bonjour,

A quel horizon allez vous sortir ce nouvel agent windows ?
Sera-t-il opensource ?

Merci,

La solution existe depuis très très longtemps, cela se nomme ASN1.

Seulement les implémentations ne se valent pas et finalement certaines supportent plus de fonctionnalités que d'autres.

ASN1 est mis en oeuvre dans LDAP et SNMP par exemple.

Tant que les développeurs continuerons à trouver intéressant de faire des protocoles simples à parser pour avoir le loisir d'écrire un parseur à chaque fois, nous sommes perdus.

Je dis cela car je l'ai fait, et le jour ou j'ai été confronté à faire évoluer un protocole, j'ai compris la difficulté et c'est là que j'ai vu que cette problématique est directement prise en charge dans ASN...

Bref, ne chercher pas si loin, tout est déjà là et accessible...


cat MaListeDeFichiers | while read f; do cp -a $f ../autre/ ; done


Le problème avec ce genre de ligne est toujours le même, et c'est visiblement partout pareil:
pourquoi ne vérifiez-vous pas le code retour de cp ?

Il est si simple de générer une liste en sortie avec les fichier effectivement copiés par cp (cp retourne 0) et à la fin du script de comparer cette liste avec diff à la liste passée en entrée pour signaler les fichiers qui n'ont pu être copiés...

Truc du genre :


#!/bin/bash

BIN=${0##*/}
FILE=${1?usage: $BIN listedefichiers.txt destdir}
DIR=${2?usage: $BIN listedefichiers destdir}


rm -f $FILE.out
mkdir -p $DIR
if (( $? ))
then
echo "Repertoire impossible a creer: $DIR"
exit 1
fi

while read f
do
cp -a $f $DIR
if (( $? ))
then
break
else
echo $f >> $FILE.out
fi

done < $FILE

diff -q $FILE $FILE.out
if (( $? ))
then
comm -3 $FILE $FILE.out > $FILE.re
echo -e "Impossible de copier les fichiers:\n$(<$FILE.re)"

# Boucle infinie pour reessayer :)
# $0 $FILE.re $DIR
fi



PS: mes excuses pour les éventuels problèmes d'affichage ( > etc)

En passant,
Je trouverais super cool que inDefero balance un content-type text/plain
lorsqu'on clique sur un fichier .php !

Ca me permettrait de regarder le code directement en ligne.

C'est tellement pratique de pouvoir de faire ca en ligne .

Une petite video fort sympathique :
http://lul-disclosure.net/lulz/openbsdjizz-the_movie.html

Plus d'info sur:
http://lists.immunitysec.com/pipermail/dailydave/2008-June/0(...)

Bon jeudi :)

Je me corrige c'est Zed Shaw :)
pour ceux que cela intéresse ..

La base de donnée c'est par définition le problème de toute architecture qui veut monter en charge...

Un site c'est bien plus que ca !
C'est pas le manque de présentation sur slideshare ou sur google engEDU video qui manquent pour comprendre cela...

Ce que tu décris ici est un système distribué, et effectivement c'est le seul moyen de supporter la montée en charge et la haute dispo.
Maintenant je ne savais pas que ruby était capable d'être complètement asyncrhone et permettait de "deleguer" des operations à des processus concurrents permettant dans s'occuper de la transaction en cours pendant que l'internaute en face à dejà reçu une réponse à sa requète.

Tu oublies aussi de parler de tous les artifices nécessaires comme memcached ou xmpp pour twitter. (twitter n'est pas un modèle de stabilité voir les récents articles sur techcrunch)
Ces briques logicielles sont fondamentales pour ces services...

Bâtir de la haute dispo c'est tout simplement gérer les évènements de manière asynchrone.
Une requète à un service externe signifie que ce service retourne tout de suite un token qui va permettre à l'appelant d'être informé de la bonne fin ou pas du traitement demandé.

Qui dit asynchrone dit timeout, je ne sais s'il est tout simplement possible de demander a ror d'effectuer une requète HTTP et de sortir en timeout si en 400 ms aucune réponse n'ai arrivée. De même pour une simple requète DNS.

Une architecture scalable se construit avec des technologies capables de gérer la concurrence. Que ce soit des threads ou des processus; il n'est pas envisageable d'avoir un seul processus au déroulement purement séquentiel pour répondre à une requète.

Ne serait que mettre à jour un compteur, il est n'est pas "normal" de faire l'incrément de ce compteur dans le même processus que celui qui sert la requète. A la place il faut que le processus de traitement de la requète fasse lui même un appel à un service d'incrément de compteur (avec un timeout) et continue son travail. Le processus qui gère l'incrément à tout le loisir pour mettre à jour toutes les ressources liées. Mais en aucun cas un perturbation du réseau pour joindre une des ressources n'aura impacter la réponse à l'utilisateur.

Pour faire simple avec un concept compliqué: la scalabilité c'est ajouter ou enlever des machines de manières transparente, cela signifie que les temps d'exécution observé par l'internaute doivent toujours être semblables.
Un timeout pour toutes les opérations asynchrones et des processus dédiées pour les opérations de types entrée sortie.

Est-ce que ruby sait tirer profit des processeurs multicore ?
Est-ce que son modèle de threads ne passe pas sont temps à mettre des lock empéchant tout simplement toute notion de parallèlisation ?

"Puis aujourd'hui, les perfs ne veulent plus dire grand chose car les applications gourmandes sont éclatées en services (Amazon EC2, SimpleDB, S3, etc...). Bref, le langage est de moins en moins prépondérant face à une architecture bien pensée."

Un langage adapté, et ce n'est pas le cas de ruby.

Documente toi sur le modèle Acteur, regarde Scala, Erlang, Haskell, essaie de comprendre la raison d'être de ses langages, tu verras que ruby n'est rien d'autre qu'un n ieme langage sans réel intérêt...

Relis tout ce qu'à ecrit Zen Shaw, auteur de mongrel, et ce qu'il pense de la communauté ruby... Bref creuse le sujet de la scalabilité, car tu fais fausse route...

Génial,
J'espère que plus de développeurs vont commencer à utiliser cette technologie.
Voilà un langage qui utilise véritablement le paradigme objet et pas un substrat ridicule...

En espérant que cela remette smalltalk sur le devant de la scéne, ce langage le mérite vraiment !

Merci pour tes explications.
Elles me confortent bien dans l'idée que nous n'avions pas la même notion de connexions persistantes.

Tu me présentes des connexions qui sont réutilisables un certains temps, et ce n'est bien sûr pas du tout la définition de persistant.
(persistant à un processus mais pas du tout à une application)

Finalement tu évoques toi même que cette solution de pconnect n'est pas satisfaisante, et que par conséquent tu t'orientes vers une solution de pool.

Pour moi, cela prouve parfaitement mes dire, pconnect n'a rien de persistant.
(pour reprendre un autre commentaire, c'est une solution de bricoleurs)

"En utilisant PHP en mode module sous Apache, PHP s'arrête entre chaque page, pas le fils
Apache et c'est le fils Apache qui maintient la connexion que tu récupères à l'exécution de chaque fils PHP."

On se place dans le cas de processus ou de thread ?

Donc si nous faisions un 'ls -l' dans /proc/piddufilsapache/fd
nous devrions voir les connexions vers la base mysql par exemple ?
Cette liste sera remise à jour tout au long de la journée ?

Au démarrage de apache toutes les connexions se font d'un coup puis sont
partagées entre les sessions php ?

Et lorsque ce fils la meurt, que deviennent les connexions ?
Ce fils là ne meurt jamais ?

Je n'arrive pas a comprendre comment les connexions sont ensuite partagées ?
Un mécanisme d'ipc permet à php de donner ses structures mysql à des fils nouvellement créés ?

Je ne comprends plus rien à PHP ou alors il a grandement évolué dans sa version 5...

"Euh mysql_pconnect tu connais? "

Je crois que la relecture de la documentation t'est nécessaire...
Le pconnect ne fonctionne que pendant la durée de vie du script.

Php s'arrête entre chaque page, ainsi que toute tes connexions SQL, pconnect ou pas.

Le problème ne vient pas du manque de fonction dite persistentes, mais juste du fait que PHP vit et meurt en même temps que la requète de l'utilisateur.

En cours, il n'est pas possible d'avoir des connexions persistentes avec un php fonctionnant en mod_php. Et cela sur n'importe quelle technologie.(LDAP, RADius, *SQL, ...)

C'est super bien d'avoir des connecteurs vers pleins de technologies,
mais est-ce qu'en fin php va arriver à ne pas devoir "réouvrir toutes les connexions" vers tous ces services tiers à chaque connexion d'un internaute ?

Zend facilite énormément les choses, mais pourquoi est-ce encore impossible d'avoir à l'heure actuelle
un objet User qui tournerait dans php et qui persisterait
entre les connexion de l'utilisateur correspondant ?
A quoi ca sert un objet si sa durée de vie est nulle ?

Le cache permet d'avoir du code déjà compilé, c'est bien, l'étape suivante serait d'enfin pouvoir réutiliser des connexions ouvertes ...

Se reconnecter à Mysql pour chaque page, au LDAP ...
Reconstruire entièrement le cache memcache à chaque connexion pour pouvoir bénéfichier du consistent hashing.
( se reconnecter à tous les serveurs memcache à chaque appel de page ... c'est n'importe quoi)

Un frein majeur à l'utilisation de php c'est tout simplement que php ne dispose pas de machine virtuelle tournant en dehors du contexte apache.

Nombreux sont les sites (ou framework) qui ont recours à des crons pour faire des tâches schédulées alors que si php pouvait
être actif tout le temps ces tâches pourraient être exécutées simplement...

Si php pouvait s'installer facilement en mode machine virtuelle, il serait alors le champion toute catégories des developpements web.

Le problème reste que le langage n'a pas été prévu pour. Et qu'un changement dans ce sens serait très certainement très couteux.

Comment faites-vous alors pour contourner ce problème ?
Ces problèmes ne vous gênent pas ?

Juste par intérêt,
Le score YSlow d'une page de Drupal est de combien ?

Et des autres CMS ?

Salut,
J'aurais bien voulu connaître la motivation de quitter PHP pour aller vers Python ?
Choix technologique ?
Changement de développeurs ?

Le retour d'expérience pourrait être utile à tout le monde...

Le buzz existe déjà, mais

Erlang est un peu différent, erlang est né d'un besoin venant de l'industrie.
Ce langage a été créé pour pour répondre à des problématique bien précises.
Les plus notables sont:
- La tolérance au panne,
- La rapidité de maquettage,
- La haute disponibilité.

Les livres et documentation officielle traitant du sujet en parleront mieux que moi:
http://erlang.org/doc/getting_started/part_frame.html

Le langage est fonctionnel ce qui signifie pour nous programmeurs (en simplifié :) que les closures et la récurrence sont omniprésents. Que les travaux sur les listes ou les arbres sont courants.

Malheureusement pour parler de erlyweb je dirais que ce projet tente de recopier RoR, alors que RoR est bati sur un langage complètement différent.

Erlang c'est de la programmation concurrente, et c'est bien là toute la différence avec les autres langage objets (Python, Ruby, Php) ou pas (Php) disponibles... Erlang rejette la notion d'objet, il mets en avant la notion de clients serveurs.

De son point de vue, un objet et un serveur et ses méthodes sont simplement des requètes faites à ce serveur.

L'énorme avantage d'Erlang est aussi sa plus grande difficulté d'accès est le 'share anything paradigm'.
Aucune donnée n'est partagée, tout se fait à travers des messages.

(imaginer une rue commercante où tout les marchants crieraient pour discuter entre eux d'un côté à l'autre, le boulanger faire cuire son pain pendant qu'il réponds au boucher qui fait rôtir son poulet... Le monde est concurrent, ma femme arrive à tenir deux conversations etc.)

Les processus discutent en échangeant des messages de manière asynchrones.

Je lisais encore tout à l'heure pourquoi le projet MERB http://www.railspikes.com/2007/4/1/merb est né, à savoir, avec Mongrel il était visiblement difficile de faire de l'upload de fichier...
Ruby semblait bloquer, or ce n'est pas exactement ce qui se passait et c'est pourquoi MERB est né.

Ce que mets en évidence MERB c'est tout simplement que la concurrence n'était pas gérer du tout dans Ruby (j'exagère à peine).

Et la véritable raison à cela est tout simplement que les programmeurs actuels ne sont pas du tout capables de penser concurrence. La formation n'existe quasiment pas et la culture n'aide pas les éventuels aventuriers du domaine.
Il fait se rendre à l'évidence le modèle concurrent bien plus 'naturel' n'est pas encore à la portée de tous.

Cependant la concurrence nous allons tous devoir nous y mettre, il est tout simplement impensable à l'heure actuelle d'ignorer l'arrivée de processeurs à plusieur coeurs.
Tant que la programmation par sémaphore et par "shared memory" sera utilisée les programmes ne seront pas capables de bénéficier de toute la puissance des nouveaux processeurs.

Penser un programme de manière concurrente cela veut dire qu'on est capable de le faire fonctionner (sans réécrire quoi que ce soit) sur un processeur multicoeur mais aussi sur une grape de serveur... (erlang rends le réseau transparent, les processus ne sont pas que locaux)

Afin de peut être vous familiariser avec ces notions je vous invite à regarder la http://qcon.infoq.com/sanfrancisco/file?path=/QConSF2007/sli(...) présentation de Randy Shoup (eBay) et plus particulièrement la page 4 décrivant les stratégies adoptées par eBay:

Strategy 1: Partition Everything
– “How do you eat an elephant? ... One bite at a time”
Strategy 2: Async Everywhere
– “Good things come to those who wait”
Strategy 3: Automate Everything
– “Give a man a fish and he eats for a day ... Teach a man to fish and he eats for alifetime”
Strategy 4: Remember Everything Fails
– “Be Prepared”

Une autre excellente introduction au monde concurrent est visionnable dans une conférence http://www.google.fr/url?sa=t&ct=res&cd=1&url=ht(...) mémorable de http://fr.wikipedia.org/wiki/Alan_Kay ... (apprécier le parallèle avec le corps humain et les cellules...)

Pour les plus curieux je tiens un blog sur erlang: http://easyerl.blogspot.com/
le propos est de montrer qu'erlang est adapté à beaucoup plus de tâches qu'on ne pense, et a fortiori au développement web...

La réponse est écrite dans mon premier message,
un processus erlang prends 300 octets, et n'est pas un appel a fork() ni à pthread_create ou à clone().

Erlang utilise les thread pour se répartir sur les différents core des processeurs, mais une thread OS peut contenir 30000 process erlang...

Plus je lis vos commentaires et plus je vois qu'il circule un mythe sur erlang.

Erlang dérive des telco, c'est à dire qu'il doit assurer 99,99999 % de disponibilité.
Erlang n'est pas un language sorti d'une université, erlang est la réponse à un besoin,
et c'est fondamentalement différent des autres langages.

Ericsson avait besoin d'un langage robuste, sûre et permettant le développement rapide.

Pour les perfs, il existe le très connu:

http://www.sics.se/~joe/apachevsyaws.html

Yaws étant un serveur web écrit en erlang.

Encore pour les perfs, la meilleure implémentation de serveur Jabber n'est autre que ejabberd. Or un serveur Jabber regroupe exactement toute les problèmatiques liés au développement réseau (concurrence, asynchronisme, performance, stabilité)

Sinon erlang au passage ca tourne sur énormément de pabx ericsson, ou switch/accelerateur SSL nortel ...
Altéon également utilise erlang.

Pour terminer, il n'existe pas d'avenir pour les langages qui continue à
partager des variables, (Mutable State is Hell)
ne font pas de la concurrence de base,
ne peuvent pas être rechargé à chaud,
et ne gèrent pas les grappes de machines de manière transparentes....

Vu que je suis une burne et n'arrive même pas à coller des liens je les remets ici...

La video google:
http://video.google.com/videoplay?docid=2953846492344274158&(...)

http://www.erlang.org/


Lien vers les presentations des archis (dans le vent) web 2.0:
http://poorbuthappy.com/ease/archives/2007/04/29/3616/the-to(...)

Ah, bien comme commentaire, j'aurais aimer que tu argumentes un peu ...

En revanche j'admets tout à fait que pour la gestion des caractères sous forme de liste peut sembler être lourd, c'est le cas, mais c'est également pour cette raison que le type binary est utilisé (notation en << >>).

Maintenant il est toujours (et peut importe le language) de générer un automate pour parser un fichier XML que d'utiliser DOM, XPATH et tout ce que tu veux.

Je défis quiconque de réaliser un parser avec libxml2 pour ne citer que le meilleur, qui irait plus vite qu'un code générer à partir de flex (même pas besoin de bison/yacc) pour parser exactement les même tags...

Et oh grand bonheur, dans le code source de erlang tu peux trouver l'application megaco qui utilise justement un parseur générer à l'aide de flex, tout simplement pour des soucis de performances (et certainement de rapidité de développement pour le ou les auteurs).

ejabberd utilise libexpat pour parser son XML.

Dernier point, même si me prouve qu'à traitement équivalent erlang est plus lent, lorsque tu veux augmenter ta puissance de calcul en ajoutant des noeuds à ton réseau je peux te garantir qu'erlang au final l'emportera.

Regarde du côté du MapReduce ( de google ) et essai peut être de comprendre que la vitesse n'ai absolument pas le but ultime, le but ultime c'est d'avoir une plateforme
dans laquelle tu peux
ajouter 1 noeud, retirer 1 noeud quand tu veux et sans perturber le service,
une plateforme qui peut grossir horizontalement.

Un noeud (une machine on va dire) utilisé à 100% de sa puissance à 100% du temps est une énorme erreur.
Ce noeud ne pourra pas encaisser une charge soudaine, devient difficile à administrer (pense à toute les sondes de surveillance système et métiers) et est primordiale à la plateforme, c'est à dire que si elle tombe les autres machines de la plateforme ne pourront tenir la charge globale...

Erlang c'est pour bâtir des architectures solides dans un monde où 100% du temps seul 90% (on va dire) du matériel fonctionne...


Cadeau bonus:
études de cas

Ce lien ne parle pas d'erlang en particulier mais d'architecture, et la conclusion est que le brique qui ont été nécessaires existent ou sont triviales à implémenter en erlang...

Si le languages t'intéresse tant que ca je ne peux que t'inviter à jeter un oeil à
Erlang.

Ce langage dispose de certains avantages et des fonctionnalités que tu décris plus haut.

Non seulement il est robuste, simple et ultra productif, mais en plus il vient avec un framework très très attractifs. (OTP)

C'est un langage fonctionnel, et peut dérouter les débutants ou expérimentés aux cerveaux encore trop habitués aux autres langages.

Erlang, dispose de 'green threads' c'est à dire de process ultra légers, ce ne sont pas le même threads que dans java ni celle de pthread ou de nptl, ce sont des processus erlang.

Un processus erlang pèse 300 octets, et une machine virtuelle de base (sans paramètre de démarrage) est configurée pour faire tourner un peu plus de 32000 processus.

Il est courant d'avoir un très grand nombre de processus tournant en même temps.

Pour vous donner une idée, un crawler de page web peut tout à fait être développé de manière à avoir un processus erlang par url à récupérer. En d'autres termes chaque href contenu dans une page va déclencher un "spawn" (fonction de création de processus) d'un processus faisant une requète GET.
Donc 5000 liens dans une page va déclencher 5000 processus...

Erlang est distribué, pour communiquer la syntaxe est très simple, les processus sont identifiés par leur PID et pour leur parler on écrit ceci:

Pid ! coucou.

Cela veut dire qu'on envoit l'atome coucou au processus Pid.
Pid peut être sur la machine locale comme sur une autre machine, c'est transparent...

Erlang dispose des List Comprehension, du Pattern Matching, d'une base de donnée repliquée et distribuée (Mnesia).

Erlang dispose également de modules indispensables, tableaux (ets, dets), arbres (gb_sets, gb_trees), gestion de queue (queue), de timers (timer) et bien d'autres.

Erlang dispose de types de bases proches de ceux du javascript (pardonner cette phrase mais elle permettra à plus de monde de comprendre :p), liste et tuple.
[1,3,4,5,2] est une liste
{user, Login, Pass} est un tuple
[{a, 1}, {b,2}, {c,3}] est une liste de tuple...

Erlang c'est aussi un moyen de faire de la livraison de code à chaud, Erlang fait la différence entre les versions de codes, il est donc capable d'être mis à jour sans arrêt. No DownTime.

Erlang vaut définitivement le coup d'oeil, il est facile de dire que ce language va faire énormément parler de lui dans les années avenir, ne serait-ce qu'avec l'arrivée de processeur multicore... (pour comprendre il faut regarder en détails et arriver à comprendre qu'une variable ne peut pas changer de valeur une fois assignée...)

Une Vidéo sur le sujet, certainement le plus accessible:
google video

Certains projets commencent à être connu (ou le sont déjà):
Ejabberd (process-one)
Tsung
Eddie

Doc Erlang:
Erlang.org
Intro a Erlang (en anglais)

Et pour approfondir, n'hésiter pas à chercher sur del.ico.us ou digg ou reddit, ou encore l'excellent Lambda the Ultimate

Avec Oreon est-il de changer des paramétrages de nagios sans devoir le redémarrer ?

Est-ce que l'interface est capable de gérer plus de 10 machines ?
Le problème de l'interface de nagios sans compter les problèmes
avec son auteur principal qui refuse de prendre des patchs, est sa lourdeur
dès qu'on essaie de travailler sur un véritable parc de serveurs...

Pourquoi avoir choisis encore une fois de rendre les graph à la volée ?
Ce n'est pas moins lourd de calculer les graphes une fois toute les 5 minutes ?
Histoire de ne pas exploser la charge de la machine quand 3 personnes regardent les graphes ?

Corrige moi, mais pour que GFS soit un système de fichier partagé il faut installer le Redhat Cluster Suite.
http://www.redhat.com/software/rha/cluster/

Je pense, que GFS peut être installé certes via tes différents liens mais je doute quant à son utilisation en Cluster.

Je serais heureux de me rendre compte du contraire...

Pour répondre à ta question en une ligne :
OCFS2 est moins mature, et par expérience n'est pas stable.

En plusieurs lignes et sur d'autres points:
Du point de vue de l'installation; ocfs2 est plus rapide à installer.
Nous utilisions ocfs2 pour partager des données mais dans notre configuration les partitions étaient sur un SAN, et seules deux machines faisaient partie du cluster.

Ocfs2 lorsqu'il n'arrive plus à joindre un node, sort en panic. Le problème d'avoir seulement deux nodes c'est qu'un panic peut venir du fait que l'autre node ne réponde pas ou bien que lui même ne fonctionne plus. Donc il faut toujours avoir au minimum 3 nodes :p

Ensuite nous basculons vers une étude sur GFS car ocfs n'était pas stable pour notre utilisation (partager un fichier de près de 100 go, fichier d'indexation). Car même seul ocfs à déclencher des panic :/
(par seul il faut entendre un node seul sans partenaire)

Dernière chose OCFS2 n'était toujours pas certifié par Oracle, c'est en cours pour Oracle 10g.

Cependant d'après notre expérience, des accès sur ce fichier de 100go sont plus rapides que sur le même en Ext3.

Maintenant GFS c'est plus difficile à obtenir, il faut payer, et pour avoir une version d'évaluation il faut signer un document. Par contre c'est d'après la doc et certains echos beaucoup plus stable, c'est une question de maturité.

Je n'ai pas encore pu bencher ce filesystem, mais il y a de fortes chances que ce soit du costaud.

Du point de vue de la documentation les deux ne sont disponibles qu'en anglais (pour le moment).

Mes connaissances sont encore loin d'être très poussées, mais d'ici peu j'aurais plus d'informations et plus de chiffres :p

En parlant de OpenMP, ou puis-je tester ce truc ?
Impossible de trouver du code ou quoi que ce d'autre que leur spec et presentation...

C'est que je veux le voir tourner ce truc !