Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick - LinuxFr.org\nBenchmark (474 clics)\nTempleet (102 clics)\nZope (31 clics)\nSPIP (34 clics)\nOpenBrick (36 clics)\n# Re: Un benchmark Apache, Zope, SPIP et Templeet sur un OpenBrick\nPosté par Jiquem le 07/04/03 à 21:57 . Évalué à 4.\nWouah templeet est tellement balaise qu'il est même plus rapide qu'apache :)http://nexus.ouvaton.org/Benchmark_OpenBrick/EssaiArticle_html_m379(...)\nNon bon ok c'est pas drôle !\nPosté par Fabien Penso (site Web personnel) le 07/04/03 à 22:04 . Évalué à -2.\nBah les benchs ça vaut ce que ça vaut hein, mais bon ça montre un ordre de grandeur.\nPosté par Anonyme le 07/04/03 à 22:11 . Évalué à 10.\nPosté par Rafael Pinilla le 08/04/03 à 00:32 . Évalué à 10.\nD'origine, le DocumentRoot du VirtualHost apache pointe _directement_ sur le cache.\nC'est ça _LE_ killing feature de Templeet, ce qui le fait aller si vite.\nJe sais, c'est pas facile à envisager, c'est tellement à l'opposé des autres systèmes...\nSi perte de charge il y a, elle est due vraisemblablement due à l'évaluation des expressions régulières par les directives mod_rewrite.\nEnfin, c'est la seule raison que je vois.\nJe vais essayer de voir les perfs de drupal. Je me suis laissé dire qu'une requète SQL était lancée à chaque connexion. si c'est le cas, on revient au cas classique où c'est le petit cocode chéri du développeur qui prend la main pour décider, et perd donc du temps.\n[^] # Comparer carottes et jantes d'AUDI 80 ?\nPosté par Rafael Pinilla le 08/04/03 à 01:33 . Évalué à 10.\nNote à ceux qui poussent des cris. Je ne compare pas Zope, Templeet etc. Je les mes en ligne pour un test de charge, sans plus.\nJe rappelle à tous ceux qui liront le bench qu'il s'agit içi uniquement d'un test de charge, effectué de but en blanc parce que mon système est destiné à tourner sur une confuguration minimale. Aussi j'ai utilisé les fonctionnalités évoluées de chaque logiciel pour générer une page (de taille aussi égale que posible) mise en place par un système dynamique. Une fois cette page préparée, charge au système de la servir du mieux qu'il peut, aussi vite que possible, sans plomber la charge d'un pauvre processeur anémique. En référence j'ai choisi Apache, car c'est _la_ référence. Il fonctionne vite et bien. Il a fait ses preuves. il est livré d'origine. Il est libre. No troll please.\n[^] # Re: Comparer carottes et jantes d'AUDI 80 ?\nPosté par -=[ silmaril ]=- (site Web personnel) le 08/04/03 à 09:37 . Évalué à 4.\ntu devrai essaye caudium, honnetement\nPosté par Pooly (site Web personnel) le 08/04/03 à 08:01 . Évalué à 4.\nQuelqu'un a-t-il fait des test lorsque le DocumentRoot ne pointe pas directement sur le cache de Templeet ?\nPosté par Rafael Pinilla le 08/04/03 à 12:16 . Évalué à 6.\nOui, moi, quand, comme un crétin, je n'avais pas suivi la doc de templeet.\nCa donne du 7.3 req/s pour 145Ko/s. La _seule_ différence, c'est que mon domumentroot pointait sur /var/newww/nexus/\nJe rappelle qu'il s'agit des templates de linuxfr, les mêmes que ceux qui s'exécutent en pointant sur http://linuxfr.org/pub/(...)\nJ'étais tout fier des résultats, j'avais posté des résultats à l'arrache dans un newsgroup lost-oasis.\nMême dans ce cas, c'est plus léger et plus rapide.\nCe n'est que quand quelques habitués du chan irc en question m'ont demandé d'inclure Zope et SPIP ce week end que j'ai tenté d'étendre le bench et de rendre un truc propre. Ca devait pas me prendre plus d'une heure. Ca ma pris un un jour.\nAvec mon 145Ko/ et 7.3req/s J'ai pointé mon nez sur #templeet en donnant mes résultats. Là Fabien m'a rit au nez en arguant que j'avais _forcément_ raté une étape, car templeet ne pouvait _pas_ être si loin d'Apache.\nIl m'a mis le nez sur la doc, sur la ligne sur laquelle j'étais passé convaincu d'avoir positionné la variable $pagecache. Mais non crétin que je suis, c'est le documentroot qu'il faut pointer dessus.\nEt là: doute. Mais alors comment ça marche ??? A non mais attends, heu, ben oui ça doit marcher. J'essaie voir. Et là ça va vite, très vite.\nC'est pas de ma faute, ça va vraiment vite ce truc.\nPosté par Anonyme le 08/04/03 à 08:28 . Évalué à 10.\nPosté par Fabimaru (site Web personnel) le 08/04/03 à 22:40 . Évalué à 1.\nMoi aussi je veux bien savoir. Bizarre tout le monde parle de la mise en page de pages statiques...\nQue donnent les perfs dans le pire cas (tous les utilisateurs sont authentifiés et ont le droit à des [+] et [-] à coté de chaque commentaire) ?\nPosté par tinou le 08/04/03 à 09:46 . Évalué à 2.\nDu peu que j'en connais, Drupal est sympa, fonctionnel, et très complet.\nEffectivement, je crois qu'il utilise une requête SQL à chaque connexion, puisqu'il stocke son cache dans sa base de données, dans la table 'cache'.\nPosté par Pascal Terjan (site Web personnel) le 08/04/03 à 10:37 . Évalué à 5.\nPosté par Misc (site Web personnel) le 07/04/03 à 22:08 . Évalué à 10.\nJe pense que ce bench est pas mal, mais, il ne prouve rien, à part que templeet "c'est bien car ça cache sans avoir a rajouter un proxy avant", ce qui est un peu injuste par rapport aux autres.\nIl faut prendre en compte chaque aspect , et comme chaque benchmarck, je trouve que c'est réducteur d'occulter tout ou presque pour mesurer uniquement la vitesse.\nPar exemple, j'aurais voulu voir des solutions comme slash, ou l'utilisation d'apc.\nSavoir comment on peut tuner apache, pour encore accelerer, ou comment tuner mysql, etc.\nPosté par Anonyme le 07/04/03 à 22:16 . Évalué à 1.\nPosté par Anonyme le 07/04/03 à 22:38 . Évalué à 10.\nPosté par Pierre Tramo (site Web personnel) le 07/04/03 à 23:29 . Évalué à 7.\nSurtout que templeet ne serait vraiment pas difficile a battre, le temp de parsing d'un template est vraiment faramineux.\nPosté par Cyril le 07/04/03 à 23:46 . Évalué à 1.\nAttention, un troll semble se dissimuler dans ce post ....\nPosté par Pierre Tramo (site Web personnel) le 08/04/03 à 08:15 . Évalué à 1.\nMeme pas, fait des tests, un site avec templeet sera toujours plus lent qu'un site en php vu qu'il y a un parsing hyper lent en plus.\nTempleet compense sa lenteur par un systeme de cache mais si tu en fait un en php, templeet n'a plus aucun avantage.\nJe ferais bien un benchmark pour le démontrer(pour le peu qu'un benchmark puisse démontrer qqch) mais je suis certain que la news ne passerait jamais ici.\nPosté par Anonyme le 08/04/03 à 09:06 . Évalué à 1.\nPosté par Pooly (site Web personnel) le 08/04/03 à 09:51 . Évalué à 3.\nRemarque, comme les journaux ne sont pas modérés, à priori tu pourrais quand même le diffusé. en tous cas, je suis interessé !\nPosté par Erwan le 08/04/03 à 10:44 . Évalué à 2.\nTempleet a aussi l'avantage de simplifier d'autres taches.\nMais tu as raison: si tu reecris templeet (gestion du cache, du multilingue, des acces BD), templeet n'a plus aucun avantage. Mais faudrait un benchmark pour demontrer ca.\nPosté par Anonyme le 08/04/03 à 12:36 . Évalué à 3.\nBen pas les tâches d'écriture et de maintenance des fameux templates en tout cas.\nPosté par Ano nyme (site Web personnel) le 26/06/03 à 20:45 . Évalué à 1.\nSPIP est le roi du template. Je ne connais pas de système plus maléable et simple à déployer que SPIP.\nPosté par Rafael Pinilla le 08/04/03 à 12:45 . Évalué à 4.\nJe ne joue pas à l'El33t, je mets des A ou EE maj pour ne pas s'eméler les pinceaux entre templAte et templEEt.\nJ'ai déjà indiqué plus haut les résultats sans cache: 7.3req/s et 145Ko/s pour les templAtes (compliqués :) de linuxfr.\nEn fait, TemplEEt fonctionne globalement comme ça (j'ai tracé la chose pour ne pas mourir crétin):\nErreur 403|404 => Execution de templeet.php qui lance le chrono (facteur ralentisseur, tiens), décode l'argument:\nsi argument=rien de connu => page d'erreur:\nSinon, il lit le templAte correspondant à l'argument:\nOuverture du TemplAte en question:\nMise en cache des include éventuels (héhé)\nParsing de haut en bas du templAte.\nA chaque fonction, un appel vers ./module/nom_du_module.php , avec passage des arguments, ( un module gère de une à plusieurs fonctions mot-clé templEEt) qui bosse et revient au noyau de templEEt qui poursuit.\nA la fin du templAte, le chrono est arrété, et le footer éventuel indiquant le temps d'exécution est éventuellement indiqué.\nEn gros, c'est comme ça que ça fonctionne, et ça va plus vite que SPIP même sans aucun cache. Pire, il écrit le cache à chaque fois qu'il est exécuté dans ce cas, il me semble, vu que comme il le templAte n'est sensé s'exécuter QUE en cas de cache absent, il est inutile de vérifier. Il faudrait désactiver l'écriture du cache pour voir.\nEn fait, ça va bien plus vite que tu ne penses.\nSi un des créateurs de Templeet pense que j'ai dit des conneries, merci de rectifier.\nPosté par Fabien Penso (site Web personnel) le 08/04/03 à 12:58 . Évalué à 3.\nLe lancement du chrono ne consomme pratiquement rien, c'est juste une information qui permet de savoir si une page s'affiche plutôt rapidement, ou lentemenet, plus rapidement qu'avant, etc. Ce n'est pas le temps réel vu que le chargement de PHP dans Apache consomme déjà, par exemple, et n'est pas compris dans le chrono.\nCe que tu appelles l'argument, c'est en fait l'url demandé, tout simplement, s'il ne reconnait pas l'url, alors il affiche une erreur404, normal (mais templatisée quand même pour pouvoir la changer). S'il trouve le template, il l'évalue. Ensuite les fonctions dans les templates. Comme PHP est d'une lenteur incroyable pour lire son propre code, les modules ne sont chargés que lorsqu'une fonction s'y trouvant est appelée dans un template, on gagne réellement en rapidité comme cela. Tu n'as pas d'appel du module ou autre, c'est juste que le module est chargé la première fois qu'on en a besoin, ensuite il ne l'est plus vu qu'il est en mémoire, et la fonction marchera toujours.\nPour le cache, on peut toujours activer le cache des templates, d'ailleurs je pense qu'on va l'intégrer dans l'installeur. Ensuite le cache des pages, on peut aussi l'activer sans vraiment avoir de système de page 404, mais c'est plus lent vu qu'il faut quand même charger PHP, ce qu'il faut éviter vu que c'est une -biip- côté performance.\nPosté par Beretta_Vexee le 07/04/03 à 23:34 . Évalué à 2.\nslashcode peut en effet étre un bon competiteur, mais j'ai peure qu'ils soit plus a dans son element, avec un infrastructure plus lourde... de mémoire il integre lui aussi un systéme de cache attypique, mais aussi des contreinte temporel ou de charge, pour la mise a jour de certeinnes pages de cache ou autre.\nDe plus slashcode est plus un gestionaire de contenue t'elle qu'un PHP-NUKE qu'un systéme a vocation réellement generaliste comme SPIP, ZOPE ou Templeet.\nPosté par arnaud le 07/04/03 à 22:14 . Évalué à 3.\nLes graphiques traitant du passage de linuxfr.org à templeet (partie en PS) m'ont tout de suite attiré, domage que l'on tombe en 404 en suivant les liens....\nSi Rafael Pinilla lit ce post, peut-il remédier à ça ?\nPosté par naibeD le 07/04/03 à 22:40 . Évalué à 6.\nJe pense que c est ça que tu cherchais:\nLes résultats sont réellement impressionants ;)\nPosté par Rafael Pinilla le 08/04/03 à 00:35 . Évalué à 1.\nVoilà, c'est fait, j'en ai profité pour coller des images de dimension plus efficace.\nPosté par Encolpe DEGOUTE (site Web personnel) le 07/04/03 à 22:59 . Évalué à 10.\nZope possède un système de cache des objets qui permet de diminuer la charge et de supporter la montée en charge des demandes.\nVous devriez y jeter un oeil et refaire des benchmarks.\nPosté par pas_moi le 08/04/03 à 00:24 . Évalué à 8.\nOuf, je ne suis pas le seul à être étonné par les données de ce benchmark.\nAprès avoir regardé comment les tests ont été réalisés, j'aurais tendance à devenir grossier, surtout quand j'entends parler de graphiques parlants: je ne vois pas bien comment on peut comparer des valeurs qui ne veulent rien dire entre elles. À part la comparaison Apache/Templeet qui semble se baser sur le même document, les autres serveurs sont utilisés complètement différemment...\nEn voyant la configuration Apache du serveur Templeet, je comprends enfin d'où viennent ses performances dont tout le monde parle tant :-) Par contre, il faut savoir que Zope dispose de ce genre de mise en cache des données, même si ce cache n'est géré qu'en mémoire. Il faut aussi noter que les méchanismes d'invalidation des caches sous Zope seraient sûrement à revoir: pour l'instant, je n'ai pas trouvé comment ne retirer que certaines données d'un cache, je suis donc obligé de vider entièrement un cache même si je sais que certaines des données auraient pu y être gardées... heureusement qu'il est possible de créer plusieurs caches!\nPosté par Rafael Pinilla le 08/04/03 à 00:40 . Évalué à 5.\nSi tu maîtrises assez Zope pour m'aider à le paramétrer à son avantage, je prends. Je me suis contenté de vérifier l'activation du cache ainsi que sa taille, qui m'a semblé correcte.\nIl ne faut pas perdre de vue que la plateforme matérielle utilisée est modeste, aussi les différences sont augmentées par la lenteur du processeur.\nPosté par pas_moi le 08/04/03 à 10:34 . Évalué à 1.\nJe ne peux pas franchement dire que je maîtrise Zope, d'autant que j'ai encore quelques problèmes avec les paramètres de la ZODB, mais l'utilisation d'"Accelerated HTTP Cache Manager" associés à un frontal Apache en reverse-proxy/cache et de "RAM Cache Manager" m'a déjà permis d'atteindre des performances très raisonnables, même sur des machine de type VIA Eden. Par contre, j'ai du m'embrouiller dans certains paramètres Apache car il lui arrive de nettoyer son cache sans pour autant redemander les pages à Zope... résultat: au bout de quelques heures, Apache renvoie des documents vides :-(\nPosté par Luc Stepniewski (site Web personnel) le 08/04/03 à 10:37 . Évalué à 1.\nPosté par pas_moi le 08/04/03 à 11:07 . Évalué à 4.\nUn "RAM Cache" permet d'éviter la génération de certaines parties de documents dans Zope. Par exemple, sur LinuxFR, l'entête des pages est statique (ou presque, y'a quand même la date), mais il est quand même souhaitable de gérer les listes de liens autrement qu'à la main dans le code HTML... dans ce cas, on crée un document chargé de faire le rendu de cette partie de la page et on l'associe à un "RAM Cache" chargé de garder la page générée pendant x secondes (ce n'est qu'un exemple très très simpliste).\nUn "HTTP Cache" permet d'ajouter des entêtes de gestion de cache aux réponses HTTP du serveur Zope... ces entêtes servent à annoncer aux navigateurs pendant combien de temps les documents servis doivent être gardés en cache (c'est très utile pour les images et les CSS, entre autre). En plaçant un Apache ou un Squid devant un Zope, les documents contenant de tels entêtes peuvent être gardés sur le reverse-proxy; ainsi, la première requête sera relayée à Zope, et toutes les suivantes seront directement servies par le reverse-proxy, et ce tant que le document n'aura pas expiré du cache.\nPosté par Luc Stepniewski (site Web personnel) le 08/04/03 à 11:12 . Évalué à 1.\nPosté par pas_moi le 08/04/03 à 11:26 . Évalué à 2.\nJe pense que c'est plus prévu pour les caches du coté des clients.\nPersonnellement, je ne sais pas pour quoi c'était prévu, mais je vois à quoi ça sert :-) Je vois Zope plus comme un moteur de génération de document que comme un serveur web... bien sûr, la gestion des entêtes HTTP me ramène souvent à la réalité.\nDans le cas d'un Zope sans reverse-proxy cache, un document demandé par x clients différents n'utilisant le même proxy fera travailler Zope x fois. En utilisant un reverse-proxy cache et un "HTTP Cache", seul le premier client fera travailler Zope, les autres étant directement servis par le reverse proxy... je trouve que ça fait quand même une grosse différence au niveau de la charge du serveur Zope!\nPosté par dr le 08/04/03 à 07:19 . Évalué à 5.\nOui, surtout que l'on met rarement (voire jamais) Zope en frontal direct. Zope n'est pas fait pour cela (sans vouloir troller ;-).\nIl faut mettre Apache en frontal, ou Squid (la derniere version de Zope integre une gestion fine de la cooperation avec Squid) et tu auras le meilleur des deux mondes (Zope pour du serveur d'application, et Apache/Squid pour servir les pages résultantes).\nFais aussi attention aux url relatives/absolues afin que Zope ne recalcule pas ses objets a chaque fois.\nSi ton site est statique, ou ne bouge que de temps en temps, c'est encore plus efficace.\nPosté par Sébastien Munch le 08/04/03 à 07:47 . Évalué à 8.\nsurtout que l'on met rarement (voire jamais) Zope en frontal direct.\nJe dois avouer que j'ai vu beaucoup de cas où Zope était en frontal...\nMettre Apache devant fait tellement gagner que ça ?\nMême si le serveur est une toute petite configuration ? Ou alors *surtout* dans ce cas-là ?\nCa m'intéresse, car mon OpenBrick a un p'tit Zope dessus, alors si je pouvais l'accélérer facilement, ça ne me dérangerait pas...\nPosté par pas_moi le 08/04/03 à 11:37 . Évalué à 2.\nBoarf, on voit aussi des IIS et des Exchange branché directement sur Internet... ce n'est pas pour autant que c'est une bonne idée :-)\nÇa peut faire énormément chutter la charge du serveur Zope, mais ça demande un peu de travail (ie: ajouter Apache ne fait généralement pas gagner de perf. s'il n'y a pas un minimum de gestion de cache déjà en place sur Zope).\nJe n'ai pas utilisé ce document mais en le survolant rapidement, il me semble présenter une bonne technique de mise en cache: http://www.nexedi.org/Members/jp/faq/accelerate-zope.stx(...)\nCela n'empêche pas de se renseigner sur la gestion des caches HTTP par les navigateurs et les différents proxys :-)\nPosté par Luc Stepniewski (site Web personnel) le 08/04/03 à 09:55 . Évalué à 0.\nPosté par dr le 08/04/03 à 10:05 . Évalué à 1.\nOui pour tout (sauf pour les clients ;-)\nMais le Zserver/medusa ne semble pas adapté a supporter un DOS.\nD'ou l'usage de Apache en mod_proxy ou Squid en frontal.\nOn n'utilise Apache que pour ca actuellement.\nMais bon ... l'important c'est bien la puissance fonctionelle de Zope comme paradigme (ouhhh .. ca sonne bien ça ;-)\nPosté par Luc Stepniewski (site Web personnel) le 08/04/03 à 10:32 . Évalué à 1.\nPosté par dr le 08/04/03 à 10:49 . Évalué à 1.\nFUD .. non non !!\nJe m'abreuve aux meilleures sources (shane@zope.org)\nNous avons aussi besoin de SSL pour l'admin, le provider a un Apache général, etc ... d'ou l'usage d'apache.\nOn est vraiment dans un cas ou effectivement tout est dynamique et personalisé (tu le connais bien ;-)\nMais j'ai noté avec attention tout ce que tu dis, et on va regarder ca de plus pret quand on va faire évoluer notre application.\nDe toute facon avoir ZEO est indispensable effectivement en cas de montée en charge.\nA une prochaine, luc.\nPosté par Luc Stepniewski (site Web personnel) le 08/04/03 à 11:03 . Évalué à 1.\nPosté par dr le 08/04/03 à 11:16 . Évalué à 1.\n> Unfortunately, AFAIK the current SSL support for ZServer leaks memory\nCe qui a été un élément de choix pour nous car en production (on a des uptimes de plus de 70 jours sans probleme, et encore c'est pour des questions de reboot zope du a des maj de produits ;-).\nMaintenant on est quand meme sur de la maltraitance d'insecte ;-) quand on mesure TOUS les avantages fonctionnels de Zope comme tu l'as si bien dit.\nBEAUCOUP plus important en termes de sécurité, Zope a un modele de sécurité natif, ce qui évite de découvrir des failles de sécurité dues a la programmation ou des ajouts de modules pas prévus pour cela dans les autres plate-formes. Et ca c'est priceless !!\nDonc au final on est tous d'accord : Zope en plus d'etre fonctionellement performant, il est rock solid.\nPosté par Luc Stepniewski (site Web personnel) le 08/04/03 à 11:08 . Évalué à 2.\nPosté par Rafael Pinilla le 08/04/03 à 12:20 . Évalué à 1.\nChaque document fait 18.2 Ko. Quelle qu'en soit la provenance\nC'est à un pouillème la même taille.\nPosté par pas_moi le 08/04/03 à 15:45 . Évalué à 3.\nChaque document fait 18.2 Ko\nC'est bien là le seul point commun au niveau des tests effectués.\nOn sait très bien qu'en demandant x fois le même document à Templeet il ne sera généré qu'une seule fois et ensuite il sera toujours renvoyé par Apache donc je ne vois pas comment on peut appeler ça un test de Templeet.\nÀ la limite, ils auraient comparé la vitesse de génération d'un même document dans les différents langages de template de ces outils, ça aurait pu commencer à vouloir dire quelque chose (et encore, on peut toujours critiquer la façon de coder dans chaque langage) mais là je soutiens que c'est du n'importe quoi...\nPourquoi ne pas tester l'adhérence sur sol humide (toujours le même taux d'humidité) d'un char Leclerc à 10km/h, d'une Ferrari à 200km/h (en seconde, quoi) et d'une BX à 160km/h?\nPosté par Gruik Man le 08/04/03 à 19:35 . Évalué à 1.\nCa va à 160km/h une BX?\nPosté par Fabimaru (site Web personnel) le 08/04/03 à 22:27 . Évalué à 2.\nCa dépend du référenciel\nPosté par didbaba le 09/04/03 à 14:19 . Évalué à 1.\nNon mais un leclerc ça va à 80 km/h.\nPosté par XHTML/CSS inside (site Web personnel) le 07/04/03 à 23:02 . Évalué à 7.\nPour être un utilisateur fréquent d'un portail sous Zope (http://www.univ-savoie.fr/Portail(...) pour ne pas le citer), ces résultats ne m'étonnent pas trop, Zope est un peu lourd sur les bords. (combien de fois j'ai entendu "p..... de portail qui rame !")\nMais bon, il a aussi d'autres avantages...\nEn tout cas, je ne pensais pas que templeet était aussi bon.\n(je sais ce ne sont que des benchs, mais quand même)\nPosté par _alex le 08/04/03 à 01:04 . Évalué à 5.\nPar contre tu en as pour un moment à refaire ce portail en Templeet. Mais pour linuxfr Templeet ca va tip top.\nZope, SPIP et Templeet ne sont pas fait du tout de la même façon, tout dépend de ce qu'on veut faire avec.\n(sinon manque la solution programme en C optimisé pour un site en particulier)\nPosté par dr le 08/04/03 à 07:33 . Évalué à 10.\nJ'avais mal lu le texte du bench. Tu veux mettre en place un CMS !\nC'est pas trop pertinent de comparer Apache (qui sert des pages) et Zope (qui a un modele de sécurité natif, qui accede aux objets en ftp, http, webdav, xml-rpc en natif, qui fait du undo sur les objets (!), qui sépare clairement logicue, contenu et présentation, qui se connecte aux sgbdr sans rien changer a la logique ou a la presentation, qui dispose de Workflow génériques en natif, et j'en passe) pour un CMS.\nCombien de temps va tu passer a mettre en place une solution qui soit un __vrai__ CMS comme Collaborative Portal Serveur www.cps-project.org, voire comme Plone www.plone.org ou Silva (qui tournent tous les 3 sous Zope et qui concernent des publics et fonctionalités différentes) ?\nA moins que ce que tu nomme CMS soit plus un site de news/forum de type linuxfr, auqual cas Zope n'est pas le plus adapté car bien trop puissant fonctionellement et beaucoup plus adapté a un site ou tout est computé a la volée (pour du CMS justement) ;-)\nPosté par Pascal Terjan (site Web personnel) le 08/04/03 à 09:01 . Évalué à 3.\nbeaucoup plus adapté a un site ou tout est computé a la volée (pour du CMS justement) ;-)\nHeu je ne vois pas le rapport. Si le contenu ne change pas, pourquoi recalculer sa présentation ?\nPosté par dr le 08/04/03 à 09:11 . Évalué à 1.\nJe n'ai pas du etre clair ;-)\nDans du CMS les pages sont très dépendantes de la personne qui consulte, du modele de sécurité des espaces, du contexte, du mode d'acces, des roles et autorisations, des actions possible et en cours, de l'etat du document dans des cycles de workflow, de l'age du capitaine, etc... Donc tout doit etre calcule a la volée.\nQuand le contenu ne dépend pas de tout ca, effectivement il n'y a pas besoin de recalculer systematiquement.\nDonc "si le contenu ne change pas, on ne recalcule pas sa représentation (ni son contenu ce qui est encore différent)"\nPosté par Alberto le 08/04/03 à 09:28 . Évalué à 4.\nBof, ca doit dependre du CMS. Il faudrait regarder la distribution des documents consultes, des etats des documents... Un meme document dans un meme etat (workflow) peut tres bien etre consulte par 50 personnes ayant les meme droits ! Pourquoi generer plusieurs fois la page ?\nA mon avis, dans de tres nombreux cas on est dans un etat intermediaire (il faut garder la possibilite de generer dynamiquement mais dans de nombreux cas c'est inutile car deja genere). Imagine un journal (pex lemonde) je suis sur que 90% des hits vont sur 10% des pages ! Un peu comme quand 90% du temps de calcul est passe dans 10% du code. Bref, je ne crois pas a la necessite (pour un gros CMS, si il y a 20 poilus ca ira de toute facon..) de recalculer systematiquement les pages !\nUne petite question. Est-ce qu'il est possible de cacher des bouts de pages html. Et de recalculer que les bouts qui ont change. J'imaginais une page avec l'heure (linuxfr a la date, pourquoi pas l'heuere).\nPosté par dr le 08/04/03 à 09:34 . Évalué à 2.\nOui. Oui. On parle bien de la meme chose !\nPar contre avant de __rendre__ la page ou les bouts de page, il faut bien computer les conditions, afin de voir ce qui doit changer ou pas.\nEt quand tu es dans du CMS avec de tres nombreux parametres potentiels, c'est cela qui peut prendre du temps. Pas forcement le rendu de la page.\nPosté par tene le 07/04/03 à 23:09 . Évalué à 9.\nJe pense que ce bench prouve une et une seule chose: Comme toujours en info, une cache ça accélère beaucoup les choses!\nLe reste, amha, ne compare pas des choses équivalente... (on parle de langage, de système de cache, de site, ... etc).\nCeci dit, c'est chouette de se dire que la cache de templeet est efficace... j'espère que ça motivera certaines personnes à penser leur page dynamique de façon à être "cachable"... ce qui n'est pas toujours évident... (parce que certains sites sont affreusement lent!)\nPosté par Infernal Quack (site Web personnel) le 07/04/03 à 23:13 . Évalué à 10.\nSi je peux me permettre c'est n'importe quoi ce benchmark.\nPourquoi pas comparer un chat, un pigeon et un poisson rouge ?\nLe scoop : le poisson rouge nage plus vite :)\n- Templeet est un moteur de template qui implémente un gestion de cache.\n- Zope est un serveur d'application en python.\n- Spip est un gestionnaire de contenu.\n- Apache est un serveur web\nBref ils se complètent plus qu'ils ne sont concurrents.\nOn pourrait même imaginer porter SPIP et Templeet en python et faire un système multi-couche\nSPIP-like (pour la gestion du contenu)\nTempleet (pour la gestion de cache)\nZope (moteur applicatif)\nApache (serveur de page statiques)\nPosté par feth le 07/04/03 à 23:27 . Évalué à -4.\nEt la marmotte elle ferait les requettes de ping pong...\nPosté par Xavier Antoviaque (site Web personnel) le 07/04/03 à 23:56 . Évalué à 4.\nPosté par atlexx le 08/04/03 à 09:10 . Évalué à 3.\nPosté par Erwan le 08/04/03 à 09:22 . Évalué à 3.\nEnfin bon, de la a comparer Apache a SPIP, sachant que SPIP ne peut pas se passer d'un serveur web, c'est tres fort !\nEt pourquoi ne pas comparer les performances de Linux avec celles du Pentium 4 ?\nPosté par iug le 08/04/03 à 10:04 . Évalué à -1.\nJe pense que l'analogie c'est plutôt comparer un langage de programmation avec du code assembleur. Ce qui n'est pas con du tout. En tout cas moins que le commentaire consensuel débile "ces softs sont complémentaires, il faut pas les mettre en opposition".\nPosté par Nicolas Boulay le 08/04/03 à 10:40 . Évalué à 0.\nDisons que SPIP n'ayant pas de contenu tellement dynamique, il devrait directement attaqué du HTML statique et les pages modifiant du contenu modifient ces pages. Même pas besoin du truc de l'erreur 404.\nPosté par Manico le 07/04/03 à 23:41 . Évalué à 1.\n"Je pourrais effectuer des mesures équivalentes avec d'autres CMS comme *Nuke ou Drupal, cependant, comme je n'en connais aucun utilisant le même système de gestion du cache que celui à la base du concept de Templeet, je n'essaie même pas."\nUn peu de grain a moudre, zionsys, http://www.zenzile.net/theme24.php(...) (qui est en train de changer de nom mais c'est autre chose) utilise le meme principe, selon la configuration avec ou sans interaction avec php (cache en lecture directe ou cache avec relecture pour des elements dynamiques).\nPosté par Antoine le 08/04/03 à 00:36 . Évalué à 10.\nJe reprendrai la même remarque qu'un autre intervenant : certes Templeet est vainqueur et largement. Mais pour obtenir le même niveau de performances avec un autre outil (même cette grosse daube de PHP-Nuke, oui oui), il suffit de... mettre un proxy devant. C'est en effet ni plus ni moins le fonctionnement de Templeet. Ce qui n'enlève rien à son mérite, d'ailleurs, si c'est ce que l'on cherche : témoin les stats faramineuses de linuxfr, sur une machine relativement modeste ; je pense que SPIP, sur une machine équivalente, commencerait à avoir du mal (néanmoins SPIP assure deux millions de pages par mois pour le Monde Diplomatique, ce qui n'est pas rien non plus).\nSur les chiffres absolus, je suis un peu surpris, mais il est vrai que le processeur d'un OpenBrick ne doit pas être un foudre de guerre (pour ma part, sur un Athlon XP 2000 avec PHPAccelerator, j'obtiens une centaine de requêtes par seconde sous SPIP, et probablement plus de mille avec Apache/Templeet). Néanmoins, l'utilisation d'une plateforme légère ne me semble pas pertinente pour une solution à base de cache (que ce soit SPIP, Templeet ou autre) où la disponibilité de la machine est surtout cruciale lors du recalcul d'une page - il vaut mieux une machine mutualisée puissante servant N sites plutôt que N machines dédiées faiblardes servant chacune un site. De plus, l'expérience semble montrer (d'après le retour sur les listes de discussion) que le problème pour certains utilisateurs "moyens" est la durée de recalcul lorsqu'une page n'est pas en cache - certains hébergeurs très lents du type Free ou Online ont tendance à dépasser le délai imparti à PHP - plutôt que le débit en pages par seconde une fois que l'on passe par le cache. Mais ça dépend bien sûr des applications.\nSur le fond, il est évident que les performances sont du côté des solutions intégralement statiques type Apache ou Templeet (il aurait été intéressant d'ajouter un PHPNuke, pour admirer le carnage ;-)). Maintenant il faut ajouter que ces solutions n'apportent pas forcément un niveau d'intégration très poussé des fonctionnalités désirées par le webmestre. Tout dépend si l'on a envie de coder soi-même des choses à la main, ou si Templeet propose des frameworks plus "haut niveau".\nPour SPIP, j'ajouterai que le niveau de performances dépend des fonctionnalités activées, à savoir : syndication automatique, moteur de recherche. En effet ces fonctionnalités entraînent des calculs réguliers indépendamment de la mise en cache des pages retournées par le serveur.\nPosté par Fabien Penso (site Web personnel) le 08/04/03 à 00:44 . Évalué à 3.\nnéanmoins SPIP assure deux millions de pages par mois pour le Monde Diplomatique, ce qui n'est pas rien non plus\nPour mon information, sur quelle machine, et avec quel type de charge ? C'est important quand même :)\n[^] # Type de machine ?\nPosté par Rafael Pinilla le 08/04/03 à 01:37 . Évalué à 1.\nType de machine ? A 2 Millions de pages/mois, ça fait du 0,7 page/sec. Ca tiendrait sur un OpenBrick :) (3.5p/s)\nNon, sans plaisanter, il faut voir avec les pics, mais il doit falloir mettre des mips en pagaille pour que la charge ne monte pas.\nPosté par Antoine le 08/04/03 à 11:47 . Évalué à 2.\nLa machine est un bi-processeur à 1 GHz avec 2 Go de mémoire. La charge est de l'ordre de 0,5 en moyenne (elle oscille grosso modo entre 0 et et 1,5), mais ce n'est pas très pertinent car d'autres bidules sont hébergés dessus (sites Web, mailing-listes). D'autre part le système de statistiques de SPIP est activé, qui bouffe un peu de ressources (connexion systématique à MySQL).\nUn autre critère est d'aller voir le site du Diplo (http://www.monde-diplomatique.fr(...)) et de constater que la navigation est fluide (hormis le sale bandeau de pub sous-traité à une régie externe ;-)) : ça ne donne pas une impression de "site dynamique" un peu poussif. La fréquentation est montée à trois millions de pages sur un mois dernièrement (Irak oblige).\nPour le reste, un "Apache Bench" depuis une machine bien connectée permet de se faire une idée plus précise des temps de latence (par exemple en comparant avec un fichier statique hébergé sur le même serveur, une image par exemple).\nPour répondre au commentaire du dessous : on ne peut pas reprendre un cumul mensuel et dire que cela représente N requêtes par seconde en continu. Les consultations Web sont très dépendantes de l'heure et du jour, il faut être prêt à tenir des charges de dix pages par seconde (plus pour Linuxfr) tout en assurant de préférence un envoi rapide des pages demandées.\nPosté par jeanmarc le 10/04/03 à 01:21 . Évalué à 1.\nSelon moi, dans la vraie vie, ce n'est pas du tout important. A quoi ça sert d'annoncer 6 millions de requêtes/s en passant à templeet si à côté il faut tout reprendre à zéro, prendre une équipe pendant 6 mois avec une solution qui reste marginale?\nDans la vraie vie, on préfère quand même acheter une machine puissante (même surdimensionnée) et disposer d'un applicatif solide et facilement maintenable plutôt que tuner dans tous les coins pour atteindre le nirvana du meilleur rapport puissance/vitesse à tout prix.\nPour un petit projet personnel, ça pourrait avoir un intérêt.\nPosté par Sébastien Munch le 08/04/03 à 07:51 . Évalué à 2.\nl'utilisation d'une plateforme légère ne me semble pas pertinente [...] il vaut mieux une machine mutualisée puissante servant N sites plutôt que N machines dédiées faiblardes servant chacune un site.\nOuais, mais c'est tellement bien de pouvoir administrer toi-même ta machine ;)\nPosté par jmh le 08/04/03 à 01:49 . Évalué à 7.\nAu niveau technique templeet semble tres bien. Par contre, sans vouloir faire de trop gros troll, personnellement je trouve la syntaxe de Templeet vraiment affreuse. A ce tarif la, autant ecrire des fonctions directement en PHP :)\nVous connaissez la specification TAL? C'est la specification pour les templates "nouvelle formule" utilises par zope. C'est vraiment tres elegant AMHA.\nUn bon pote a moi a fait une implementation PHP:\nQuand a moi, je maintiens une version Perl sur CPAN:\nTout ca mis a part, petite question sur templeet... Vu que apparemment le cache == le document root d'apache, qu'est-ce qui vient invalider le cache? Un chtit script dans la crontab?\nPosté par Pascal Terjan (site Web personnel) le 08/04/03 à 09:04 . Évalué à 5.\nLe cache n'a besoin d'être invalidé que lorsque le contenu change, c'est donc fait lors d'une modif.\nPosté par jmh le 09/04/03 à 10:59 . Évalué à 2.\nDans ce cas la ca devient vraiment limite...\n* Par exemple, si tu veux importer des feeds RSS / XML dans ta page? Il faut bien trouver un moyen d'invalider ca!\n* Si tu veux avoir une structure hierarchique et une bread-crumb-trail? Par exemple, tu as la page Accueil / About / Contact. Quelqu'un edite le titre de 'About' et le change en 'A propos'. Il faudra bien que la bread crumb trail sur ta page Accueil / About / Contact devienne Accueil / A propos / Contact.\nBref, purger le cache lors d'une modif c'est bien, mais ce n'est pas toujours applicable. Reste toujours l'option de mettre un script de nettoyage dans la crontab :)\nPosté par Jérome K le 09/04/03 à 01:34 . Évalué à 1.\nMoa j'utilise openTal en python\nPosté par Code34 (site Web personnel) le 08/04/03 à 04:37 . Évalué à 10.\nEst ce que quelqu'un aurait un lien vers un howto pour les débutants qui explique comment se servir de templeet ?\nJ'ai installé templeet, il y a quelques jours et je me suis posé la question: "mais après je fais quoi ????"\nAu départ, je pensais que Templeet était un cms comme spip, il n'en est rien, c'est un langage de développement.\nJ'ai lu sur la liste de diffusion qu'avec templeet, on peut faire un site efficace en 5 minutes si on est agueri. Je suis totalement néophyte, et excusez moi je ne comprends rien.\nTempleet a sans doute des qualités indégnables en terme de performances et en terme de qualité de code (ce site en est d'ailleurs une parfaite illustration).\nPar contre pour les débutants comme moi c'est un peu raid de s'y mettre, car ce projet est très peu documenté. Je vais reessayer de me faire la main avec le weblog en exemple, mais ça serait assez bien un document qui explique comment faire une structure de page minimun.\nAu départ, je cherchais un cms performant pour publier plusieurs sites sans me soucier du développement php car par experience creer un site php c'est beaucoup trop de temps de perdu, et ça n'est pas rentable.\nJe suis convaincu qu'il est inutile de recreer ce qui existe déjà et qui est sans doute fait par des personnes plus expertes que moi.\nJ'ai donc cherché du coté de spip, mais apparamment spip c'est très limité en terme de présentation. Je vais peut etre trollé, mais c'est mon avis, je trouve l'organisation générale des sites spip arnachique.\nJ'arrive jamais à me retrouver dans les rubriques, la logique de navigation est hasardeuse ... Je suis consciens que spip permet sans doute de faire des sites bien organisés pour peu qu'on y passe le temps, et que ce probleme est sans doute grandement du aux webmestres, mais j'ai pas encore vu d'exemples qui se sont conciliés à mon gout.\nAu contraire, apparamment les sites spip utilisent tous à peu près la meme désorganisation, ce qui me laisse penser (peut etre à tord) qu'il est impossible de creer autre chose qu'un site bazard, ou trouver autre chose que sur la page principale releve de l'exploit. Les bons exemples, je ne les ai peut etre tout simplement pas identifié comme des sites spip.\nLe simple fait de me dire que je vais devoir passer encore des heures à apprendre à developper un langage supplémentaire au dessus du php pour finalement arrivé à un resultat qui ne me satisfera pas me repousse.\nFinalement, je me suis penché sur le cas ez3. L'interface du site générale est moderne et sobre, le module d admin assez élaboré...\nMais j'ai vite déchanté en voyant les performances plus que douteuses de cette application en local (+ de 3 secondes pour m'afficher une page sur un xp2600), sans parler d'une application sous licence dual gpl qui arbore un démo version dans le coin en haut à droite...\nMon probleme reste insoluble jusqu'a maintenant. J'en arrive à mes questions:\nEst ce que templeet conviendra à ce que je cherche, c'est à dire développer un site performant, avec une bonne navigation, un module d'admin rapidement sans me lancer dans un langage abscons ?\nEst ce qu'il existe un cms libre , sobre, performant, avec une navigation organisée et logique, un module d'administration complet, voir une boutique ?\nJe dois juste fournir à un client, un site clef en main qui lui permette de publier ses articles, vanter ses produits etc [..] sans perdre de temps sur le projet.\nPosté par Sébastien Munch le 08/04/03 à 07:44 . Évalué à 2.\nEuh ... Zope + CMF + Plone (ou alors équivalent, je ne connais que très peu les CMS sous Zope) ?\nPosté par Pierre Tramo (site Web personnel) le 08/04/03 à 08:29 . Évalué à 7.\n>J'ai installé templeet, il y a quelques jours et je me suis posé la question: "mais après je fais quoi ????"\nTout vu que c'est un langage de template, pas plus.\n> Au départ, je pensais que Templeet était un cms comme spip, il n'en est rien, c'est un langage de développement.\nIl faut que tu prene le module linuxfr qui doit traimer quelques part sur le cvs ou\npomper ce qui est dans http://linuxfr.org/template/(...)\n> Je dois juste fournir à un client, un site clef en main qui lui permette de publier ses articles, vanter ses produits etc [..] sans perdre de temps sur le projet.\nSi tu dois aussi penser à celui qui doit le maintenir, tu ne prendras jamais templeet\nPosté par Pierre-Yves Dubreucq le 08/04/03 à 09:56 . Évalué à 2.\nOuai et bien j'ai eu le meme problème j'ai du faire un site facilement administrable, donc avec Templeet, je me suis retrouvé embetté a l'idée de voir mon patron voulant le mettre a jour et m'appellant à n'importe quel moment, voulant eviter ca, j'ai choisi Zope, car pour ma part j'ai pas trouve SPIP si intuitif et facile que tous le monde dit, alors que la plate-forme ZOPE/CMF/Plone, m'est plus facilement devenu compréhensible, certes il faut avoir des notions de développement web, et de language objet, mais bon apres bonne apprentissage, je suis sur qu'il y a moyen de faire un truc bien, à suivre...\nEn tous cas merci pour cette étude, forte instructive ;)<ii\nPosté par dinomasque le 08/04/03 à 09:46 . Évalué à 2.\nAs tu fait ton propre squelette pour SPIP ?\nLa syntaxe est très facile à apprendre et permet de faire tout ce que l'on veut.\nLe squelette par défaut est parfaitement dégueulasse, forcément si on s'arrête à lui ...\nVa donc voir du coté de http://www.stars-oubliees.com(...) pour constater les prouesses rendues possibles par SPIP.\nPosté par wikiclub le 08/04/03 à 10:14 . Évalué à 2.\nVraiment, Vraiment, tu fais ce que tu veux avec SPIP.\nJe le connais bien maintenant et je t'assure que celui-ci te permet de réaliser un site nikel avec une arborescence propre et logique.\nPar exemple, je me demande si le site http://openweb.eu.org/(...) ne tourne pas sous SPIP.\n"Update :Heu, j'ai regardé, en fait non, ils utilisent http://www.cafelog.com/,(...) dommage, ils perdent en performance ..."\nEn tout cas, si ce n'est pas le cas, c'est complètement possible de reproduire celui-ci au pixel près avec la même logique de navigation.\nPour cela, il faut utiliser la mise en rubrique des articles et SURTOUT les mots clés spip qui te permettrons de faire ce que tu veux, comme la double entrée "Thèmes" et "Décideur, débutant ...."\nD'ailleur, je n'ai pas enore pris le temps de contacter les responsables de http://openweb.eu.org/,(...) mais je trouve qu'il serait génial d'offrir OpenWeb en squelettes SPIP, site BEAU (!!!) et conforme au XHTML strict.\nSi il y a des volontaires .....\nPar contre, je ne saurais me prononcer sur les performances de SPIP.\nALors, essaye à nouveau SPIP et lit le tutoriel avancé ici : http://www.uzine.net/rubrique154.html(...)\nPar contre, il n'y a pas (encore) de module boutique\nPosté par Pooly (site Web personnel) le 08/04/03 à 10:17 . Évalué à 1.\nemarque pour l'arborescene propre et logique, je suis pas trop trop d'accord avec toi.\nSi avoir des URL comme ça: http://www.onetrip.net/html/article37.html(...)\nc'est vrai que c'est plus clair que : http://www.w-fenec.org/metal/sepultura.html(...)\nBon, après chacun son avis...\nPosté par Code34 (site Web personnel) le 08/04/03 à 10:33 . Évalué à 1.\nEffectivement, merci pour tout ces bons conseils, il me semble que j'avais sous évalué les possibilités de spip.\nJe viens de trouver des documents sur le site officiel que je n'avais pas vu, et spip pourrait tout à fait correspondre à ce que je cherche.\nPosté par Julien Duponchelle (site Web personnel) le 08/04/03 à 10:34 . Évalué à 1.\nc'est en cours un article sur le sujet est déja paru sur SPIP-CONTRIB\nPosté par Pooly (site Web personnel) le 08/04/03 à 10:59 . Évalué à 1.\nPosté par Julien Duponchelle (site Web personnel) le 08/04/03 à 18:05 . Évalué à 1.\nPosté par Pooly (site Web personnel) le 08/04/03 à 09:56 . Évalué à 2.\nMa grande question c'est quand même, pourquoi le benchmarke a-t-il fait l'impasse sur daCode... ???\nParceque sinon SPIP et daCode, même combat... Ca aurait été interessant de mesurer leur performances.\nPosté par Jul (site Web personnel) le 08/04/03 à 13:04 . Évalué à 2.\nouaip, même si je savais que spip était plus lent, je l'utiliserais toujours : ce qui est important pour un outil c'est l'utilisation que l'on en fait, et l'utilisation raisonnable de ressource par l'outil.\nPar exemple sur libroscope nous utilisons SPIP, hors effet linuxfr nous tournons à 30 visteurs différents par jour nous sommes donc dans un cas ou le choix d'un serveur plus rapide est pertinent.\nEt perso, je suis peu intéressé par le nombre de lecteur que nous pouvons avoir mais plus par ce que nous essayons de construire. Honnêtement avoir à générer plus de 10 connections secondes c'est bon pour un slashdot ou un linuxfr, mais pour 80% des cas c'est un peu inutile. Et les facilité d'édition offertes par SPIP sont plus cruciales pour moi que la vitesse de réponse à charge "élevée".\nL'important pour moi c'est peut être ridicule mais dans beaucoup cas pour un site web c'est de générer et gérer le contenu.\nC'est un bench intéressant malgre tout : on y apprend que pour 99% des utilisateurs de systèmes de publications la technologie n'est pas un frein. Moi ça me convient.\nPosté par Fabien Penso (site Web personnel) le 08/04/03 à 13:09 . Évalué à 1.\nHonnêtement avoir à générer plus de 10 connections secondes c'est bon pour un slashdot ou un linuxfr, mais pour 80% des cas c'est un peu inutile.\nRaisonnement habituel, et pourtant très stupide, malheureusement. En effet pouvoir gérer 10 connections/secondes ça veut aussi dire que pour les 30 pelerins par jour qui viennent sur ton site, les pages s'afficheront beaucoup plus rapidement. Quoi de plus chiant qu'un site dont les pages sont lentes, alors qu'un site dont les pages sont instantannées, quel bonheur!\nPosté par atlexx le 08/04/03 à 14:02 . Évalué à 2.\nPosté par jeanmarc le 10/04/03 à 01:45 . Évalué à 1.\nTout à fait d'accord! Vu la main mise du commerce sur le net, quand on tombe sur un site avec un contenu intéressant, on prend le temps de le lire, rapide ou pas.\nEncore d'accord :-) A quoi ça sert de bouriner comme un dingue quand l'internaute navigue avec un pauvre 33.6? Il ne faut pas oublier que tout le monde ne posséde pas un tuyau gigantesque vers le net. Beaucoup de gens naviquent toujours par modem vous savez... D'autres n'ont pas internet à la maison et navique à 30 sur un netissimo1 au boulot :-)\nRésultat des courses: d'abord un contenu intéressant et si le site est aussi rapide, c'est du bonus.\nPosté par Jul (site Web personnel) le 08/04/03 à 19:41 . Évalué à 1.\nHonnêtement, j'aime bien la diversité, et je pense juste que templeet est un outil adapté a une certaine façon de concevoir la gestion du contenu, SPIP à une autre.\nJe suis aussi content de constater que pour des besoins représentant 80% des cas de figures *toutes* les solutions libres testées sont acceptables. Ce qui veut dire que l'on peut se concentrer sur la façon de gérer le contenu plus que sur l'outil.\nFabien, ne penses tu pas que la chose la plus chouette qu'offre le libre aux personnes voulant d'exprimer sur internet, c'est le choix des outils sans se prendre la tête ?\nPS entre nous j'aime bien templeet.\nPPS chouette publicité pour openBrick. Ils ont testé des logiciels de spam avec ? ça pourrait être sympa comme ça pour leur prochaine campagne ils auront déjà le matos pour la faire eux même.\nPosté par Nicolas Boulay le 09/04/03 à 10:12 . Évalué à 1.\nAu fait, enrober SPIP dans templeet juste pour profiter du cache ne doit pas être trop dure. Il faudrait "juste" faire une translation d'url. Genre cache static par defaut et redirection sur le moteur SPIP quand la page n'existe pas (et destruction du cache templeet lors de modif, de toute façon cela ne peut pas ralentir l'application).\nPosté par Antoine le 09/04/03 à 13:02 . Évalué à 1.\nNon, ce n'est pas possible, enfin pas entièrement. SPIP fait un tas de traitements y compris quand une page est dans le cache, pour diverses fonctionnalités (syndication, indexation, newsletter...). De plus il y a un système d'inclusion impliquant l'utilisation de PHP dans les pages cachées. Bref à moins de se priver volontairement d'un certain nombre de fonctionnalités ou d'utiliser des ruses de sioux spécifiques à une structure de site particulière (comme le fait probablement linuxfr avec templeet), un site SPIP ne peut pas être transformé en pages entièrement statiques.\n[^] # Impasse sur daCode ?\nPosté par Rafael Pinilla le 08/04/03 à 13:12 . Évalué à 2.\nJ'ai une install de daCode qui tourne (avec la même page que celle servie par TemplEEt (la base MySQL de référence vient de là même), mais je suis infoutu de tout paramétrer pour que le cache de _pages_ fonctionne. Le cache de boxes fonctionne, mais pas les pages de base. J'ai fouillé tout ce que j'ai pu, je n'y suis pas parvenu. Je lache pas l'affaire pour autant. Je placerai une mise à jour avec drupal dès que possible.\nDonc, daCode sans cache, c'est de l'interprété de base, et c'est donc lent.\ndaCode utilise les fonctionalités objet de PHP, et ça c'est lent. Propre, mais leeeeeeennnnnt.\n[^] # Re: Impasse sur daCode ?\nPosté par Fabien Penso (site Web personnel) le 08/04/03 à 13:21 . Évalué à 0.\nPropre, l'objet, bof... Je trouve que le côté modulaire de Templeet est 100 fois plus propre que celui de daCode. Mébon...\nPosté par Benoît Sibaud (site Web personnel) le 08/04/03 à 13:48 . Évalué à 1.\nC'est parce que les développeurs originels de daCode sont plus mauvais que les développeurs originels de Templeet... hmm mais y a le même nom dans les deux... [/troll]\nbon j'ai du code à optimiser moi, alors ->\nPosté par Erwan le 08/04/03 à 13:56 . Évalué à 1.\nC'est parce que les développeurs originels de daCode sont plus mauvais que les développeurs originels de Templeet... hmm mais y a le même nom dans les deux...\nC'est ptet aussi que les developpeurs ont appris en faisant DaCode, et avec ces connaissances ils ont pu faire mieux...\nA noter qu'il ne faut pas comparer DaCode a templeet mais au module linuxfr de templeet, ce qui est bien different.\nPosté par Pooly (site Web personnel) le 09/04/03 à 08:05 . Évalué à 1.\nCela dit, il est possible de passer par le cache de page daCode de tel manière à faire servir des pages statiques directement par apache. Les pages etant stocké dans cachehtml/ par exemple, il suffit de le remonter d'un niveau et de modifier la classe Cache.\nAprès, les performanaces doivent accélérer de manière significatives :)\nL'approche objet, c'est lent, moi je pense qu'il faut voir et que ca dépend du nombre d'object chargé et de l'utilité des variables initialisé à la construction :)\n# Attetion au piège!\nPosté par _PinG _ le 08/04/03 à 10:37 . Évalué à 4.\nIl faut bien comprendre la signification de ce Bench...\nIl ne compare ni les fonctionnalitées, ni la souplesse, ni même les CMS... Il ne compare que les systèmes de caches. Et il permet de noter une très nette différence entre quelques technologies de cache disponibles aujourd'hui.\nEn effet, je n'ai rien contre Templeet (que j'aprécie), mais c'est plus son cache que le reste qui fait la différence. Et un cache du même type (ie même technologie) aurais significativement les mêmes résultat. Templeet peut donc se féliciter d'avoir un des (sinon le) meilleur systèmes de caches disponibles aujourd'hui...\nJe parles en conaissance de cause, j'ai déjas implémenté cette technologie (pages statiques, génération dynamique sur redirect du 404, daemon pour vider le cache selon divers critères) en perl pour différents sites, et la différence est énorme... Le plus impressionnant fut de passer un gros site (plus de hits que LinuxFR) d'un système sans cache (tout le site était géré par un gros script perl de plus de 5500 lignes et des squeletes) où la charge de passait jamais en desous de 8 sur un bi-p3 700MHz 768Mo de ram à un système de cache (quasi-similaire, légèrement adapté à certaines contraintes) où le gros script n'est (quasiement) jamais appellé, ce qui descend la charge à moins de 1 contament sur la même machine (sauf pics dus à diverses opérations externes au site, genre recompil de kernel :D)\nPS : pour relativiser le cache il faudrait connaitre le délai de chaque test, le délai d'expiration de la page, MAIS AUSSI le nombre de hits qui expirent la page, car certains systèmes considèrent une page expirée après un certain nombre de hits, ou un certain évènement...\nPosté par Nicolas Boulay le 08/04/03 à 10:52 . Évalué à 2.\nJe comprendrais jamais pourquoi l'invalidation du cache n'est pas relier à la modification des données qu'il contient.\nMais quel est l'interret du "daemon pour vider le cache selon divers critères" ? Pourquoi l'application ne peut pas se rendre compte que telles pages en cache vient d'être modifié par une entrée du système et doit être regénérer (ou simplement effacé du cache) ?\nPosté par Olivier Jeannet le 08/04/03 à 12:42 . Évalué à 1.\nMais quel est l'interet du "daemon pour vider le cache selon divers critères" ? Pourquoi l'application ne peut pas se rendre compte que telles pages en cache vient d'être modifié par une entrée du système et doit être regénérer (ou simplement effacé du cache) ?\nJe comprends ta remarque (on invalide une page en cache quand elle est modifiée, la logique est simple), mais comment fais-tu si ton cache a une capacité limitée ? Genre 500 Mo sur le disque, donc dès que ça arrive à 490 Mo tu vires les 10 Mo les plus vieux (ou autre algo).\nPosté par Nicolas Boulay le 08/04/03 à 12:52 . Évalué à 1.\nEvidement, si tu as un problème de place, tu fais du LRU (comme n'importe quel cache). Mais cela ne suffit pas du tout pour assurer la cohérence du cache. Ce "ménage" peut être fait lors de la génération de page (hors cache donc).\nSPIP mets des dates sur ses pages en cache. Genre une page à une durée de vie de 1h donc toutes les heures, la pages est effacé et regénéré mais cela se fait à la lecture et non à l'écriture. En plus, le site à toujours une latence d'une heure (c'est pas top notament pour les testes à moins de purger le cache à chaque fois). Pourquoi est-ce qu'il ne détruise pas la/les pages en cache lors de la mise à jour ?\nPosté par Yann Cochard (site Web personnel) le 08/04/03 à 13:06 . Évalué à 1.\nPourquoi est-ce qu'il ne détruise pas la/les pages en cache lors de la mise à jour ?\nCa m'etonne car c'est vraiment ce qui semble evident. Par exemple sur mon site, il y a une encyclopedie avec des fiches sur les plantes, que les auteurs peuvent modifier. Les donnees sont classiquement stockees dans un base MySQL. Lors d'une requete, si le fichier de cache n'existe pas, il est genere, puis charge. Sinon il est juste charge.\nSi un auteur modifie une fiche et donc les donnees stockees dans la base MySQL, le fichier de cache correspondant est efface. Il sera regenere lors de la prochaine visualisation de la fiche.\nC'est bien ca que tu voulais dire ?\nPosté par Nicolas Boulay le 08/04/03 à 13:15 . Évalué à 1.\nSi tu n'as pas de problème de place, c'est ça. Comme tu n'as pas de problème de place, tu peux aussi générer la page au lieu de juste l'effacer. Ainsi, tu peux faire pointer ton site sur du pure HTML static et avoir les performances de templeet.\nPosté par _PinG _ le 08/04/03 à 15:57 . Évalué à 1.\nAlors, je vais répondre à tes questions aussi clairement que possible :\n*/ Je comprendrais jamais pourquoi l'invalidation du cache n'est pas relier à la modification des données qu'il contient : C'est le cas de certains systèmes de cache (templeet par exemple, mais aussi mon système de cache dont je parles dans le post précédent...). Mais certaines données sont volatiles dans la durée, ou selon d'autres critères (nombre d'affichages, ...), c'est le cas -par exemple-d'une page d'accueil de news qui ne présente que les news du jour (Ce que l'on apelle "a la une" ou "édition quotidienne"). De plus, dans certains cas (particuliers), le déploiement du cache est indépendant du code du site, auquel tu n'as pas toujours accès, ou que tu n'as pas forcément le droit/l'envie de modifier... Dans ce cas, c'est le lifetime de la page qui sert à remetre à jour le cache... Un autre concept auquel il faut pensser est la publicité... Si tu dépends d'une régie un peut chiante, tu doit parfois renouveler par toi meme le cache régulièrement (problèmes d'autopromo, de remplissage, de script de pub mal foutu, ...).\n*/ Mais quel est l'interret du "daemon pour vider le cache selon divers critères" ? : Je pensse que tu n'as pas compris le fonctionnement de cette nouvelle génération de systèmes de cache. Le client est dirigé automatiquement vers la page statique en cache sans aucune intervention d'aucun script (seul mod_rewrite selon les cas entre en jeu) qui bouferais des ressources à tout casser. Si le serveur ne peut fournir cette page, alors il doit renvoyer une erreur 404. C'est là que toi, tu remplaces l'erreur 404 par ton script ou ton cgi qui vas générer la page dans le cache (le cas échéant, cad si vraiement elle existe hein, sinon il renvoie vraiement un 404) et la renvoyer au client. Donc si le fichier existe dans le cache, meme si il est expiré (parceque certaines contraites te forcent à mettre un délai de vie à certaines pages), comme aucune requète client ne vas déclencher d'execution de script pour cette page, elle ne sera jammais renouvelée. D'où le daemon, ou le script lancé régulièrement par cron (ce qui reviens au meme ;)), qui permet de faire le ménage dans le cache... Ca permet aussi de gérer certains critères bien lourds comme des problèmes d'espace disque... Oui on est sur un serveur, donc oui on met en face les ressources qu'il faut, mais si -pour je ne sait quelle raison- un client veut son cache en tmpfs (mémoire vive), bah 2Go en mémoire vive, ca fait mal :/\n*/ pour le problème de savoir si le cache doit etre regénéré au fur et à mesure ou il est invalidé, ou si on efface simplement le ficheir du cache, c'est très complexe... En effet, si tu efface, le premier client qui redemanderas la page se veras servir de facon plus lente que d'habitude (attention, tout est relatif, cad que dans le pire des cas, ca ne seras pas plus lent qu'une page dynamique standart), par contre, pour les pages peut demandées, ca permet d'économiser du disque et de la charge... Par exemple, pour le gros site dont je parlais, le cache représente 4.1Go de html (bon, c'est vrai que certaines pages sont lourdes en HTML parceque mal faites, mais bon, je gère pas les squeletes moi...) pour 210000 pages en cache environ... D'un autre coté si tu le génères en bg, tu t'exposes au fait de générer des pages qui ne seront pas consultées, ou du moins pas avant quelques temps... Donc tu boufes du CPU et du HDD pour rien...\nPosté par Nicolas Boulay le 08/04/03 à 17:23 . Évalué à 2.\n1) dans ton entrée du système, tu as donc en plus la date du jour ou des compteurs internes à l'application.\n2)3) J'ai très bien compris l'utilisation du 404, merci :) (depuis le RMLL d'ailleurs).\nEn fait tu as plusieurs cas que j'ai un peu mélangé.\nLe cas du web dynamique par "confort" : typiquement SPIP. Le coté dynamique permet une mise à jour facile. Le coté lecture pourrait être 100% static car les pages sont peu nombreuses (ou au moins la première page du site, la plus consulté).\nIl y a le cas du contenu/visualisation très dynamique type linuxfr (ou ton site ?) où il existe des pages différentes pour chaque client. Là, la génération ne peut pas être exaustif (trop de page, une modification entraine la modification de 100 pages, etc...) alors le traitement avec le 404 est bien adapté.\nEt le dernier cas : plus de modif que de visualisation : aucun interret de faire le boulot à l'avance.\nTout ce qui est problème de taille de cache, peut se régler en cron ou lors de la génération des pages (cron ne te garantit pas que tu va pas péter le quota disque entre 2 lancements).\n(au fait, il parait que la couche disque de linux est tellement performante que l'on ne gagne quasiement rien à utiliser tmpfs)\nPosté par _PinG _ le 08/04/03 à 17:58 . Évalué à 1.\n*/ ouep, tu gères certaines choses qui vont modifier le contenu (ou le contenant ;) ) des pages, donc il faudra regénérer le cache si ces choses bougent... Personellement, je stoque certaines choses concernant les pages en cache dans une table de hachage stoquée sur le disque (come j'ai la chance de travailler en perl, j'utilise des dbm*), je met à jour les infos à chaque fois qu'une page est générée, et le daemon lit dedans pour décider quoi faire... Mais j'ai aussi certaines actions (quand on rajoute/modifie un enrengistrement dans certaines tables) qui mettent à jour le cache par évènements, histoire d'optimiser un peut... Mais ca n'est pas réalisable pour tout.\n*/ sinon oui, le site dont je parles est comparable avec Linuxfr sur le fait qu'il est hautement dynamique, mais aussi sur le fait qu'il a une grosse DB de données antérieures (que les clients peuvent rapeller), qu'il a beaucoup de hits (plus de 2* plus que LinuxFR à prioris), et qu'il a des affiliés (dont des gros noms) qui affichent le même contenu mais avec leur propre 'skin', et ce depuis ce serveur...\n*/ pour la taille du cache, personellement j'avais penssé (si le problème se présentait) à un daemon qui surveille la création de fichiers dans le répertoire grace à imon/fam/cequetuveux... C'est un peut lourd, puissequ'il vérifie à chaque fois qu'un fichier est créé dans le répertoire du cache, mais au moins, tu peut pas te faire rouler, et tu gères bien ;)\n*/ VFS/FS : C'est vrai que la lecture est très performante sous linux (surtout sur un serveur, qui a du raid, ou du SCSI, ou au moins du bon IDE optimisé avec hdparm), mais franchement, tu peux pas me faire croire que la lecture (ou pire : l'écriture) est aussi rapide sur un HDD que dans la ram. Le paliatif que j'ai trouvé, c'est de foutre le cache de ce site sur une partoche reiserfs, où la lecture est très rapide, et où la quantitée de fichiers dans le répertoire n'est pas un obstacle... Et je sent très clairement des différences de perfs entre ext2/3 et reiser...\nPosté par Nicolas Boulay le 09/04/03 à 09:31 . Évalué à 1.\nBah, si ! :)\nEn fait, le system de fichier de linux utilise un max de cache en RAM d'où le très faible gain en vitesse avec tmpfs. Il existe même un patch de linux qui vire le timout d'écriture sur disque (il flush ses caches en 3 secondes au maxi sauf si il y a un sync évidement), cela permet de mieux dormir à certaine personne car le HD finit par s'éteindre. Et tu as de fait, l'équivalent d'un tmpfs.\nReiser va (beaucoup) plus vite que ext sur les "petits" fichiers, sans doute que tes fichiers html rentre dans cette catégorie.\nPosté par _PinG _ le 09/04/03 à 14:50 . Évalué à 1.\noui, surtout depuis les derniers noyeau, mais principalement pour les fichiers beaucoup utilisés... Hors ce qu'il y a d'interessant avec le tmpfs (en plus de la vitesse d'écriture), c'est la disponibilité du fichier instantanément en Ram, cad qu'un fichier qui n'est pas demandé souvent (on vas dire qui n'as pas été demandé depuis une heure pour être presque surs ;)) est quand même dispo instantanément. Exit les temps d'accès disques... Et si tu multiplies ca par 100 ou par 1000, bah ca fait la différence. De toute facon, je ne pensse pas que cache 'statique' serveur tmpfs soit nécessaire, mais bon, chacun fait ce qu'il veut ;) Sinon, reiser est plus rapide de facon générale, BEAUCOUP plus rapide sur les petits fichiers (oui, on peut dire que les pages HTML rentrent dans cette cat...), et ENORMEMENT plus rapide pour les répertoires qui ont beaucoup de fichiers (un cache HTML par exemple, surtout si il est à un seul niveau...). Et je te promet que sur le site dont je te parles, reiserFS a fait une très nette différence pour le cache... J'ai l'exemple d'un gros serveur de mail aussi qui doit son salut à reiserFS...\nPosté par Benjamin (site Web personnel) le 08/04/03 à 14:01 . Évalué à 2.\nHostnameLookups off ?\nEt pour les autres c'est ON ?\nSi c'est le cas, tu prends tout ton benchmark, tu prends la poubelle d'à-côté, et tu jette l'un dans l'autre ;)\nune requete DNS par page vue ca peut très lourdement perturber notre ami apache, et ca a un impact non négligeable sur les performances...\nsurtout si tu as testé en local et que ton ip de client ne se résolvait pas...\nPosté par gnap gnap (site Web personnel) le 08/04/03 à 22:51 . Évalué à 1.\nBenjamin, a priori, le defaut avec apache 1.3 c 'est off\n( http://httpd.apache.org/docs/misc/perf-tuning.html(...) )\nCeci dit, même si c'était on, si l'on compare les differents systèmes tels qu'ils fonctionnent par défaut, le bench est toujours valable. Mais à nuancer puisqu'on pourrait mettre en avant le fait que les confs des autres ne sont pas optimisées.\n[^] # HostNameLookup Off\nPosté par Rafael Pinilla le 10/04/03 à 11:47 . Évalué à 1.\nJuste pour info, voici ce que m'a affiché le footer du thread.\nCette page a été générée par Templeet en 15.5268s (dont 1.7378 de SQL). (Voir le source du template)\nComme quoi, quand la page est complexe, les requètes Mysql sont nombreuses et la génération de la page cachée plus longue ;)


uv Archives - Sub sole\nArchives par mot-clé : uv\nDe l’utilité d’un filtre UV (ou pas)\n7 août 2010 benoitbalon\nPour les amateurs comme pour les experts en photographie, il est coutûme de mettre quasi-systématiquement un filtre sur ses objectifs. Ce conseil, qui ne manque pas d’alimenter les blogs et les forums sur la toile, est justifié par plusieurs raisons :\nun filtre UV apporte du contraste dans les lointains et dans le ciel, en atténuant les rayons ultra-violets\nprotéger son objectif des salissures, des rayures et des éventuels chocs sur la lentille, permet de ne pas l’abîmer et d’allonger sa durée de vie\nPourtant, un filtre n’a pas que des avantages, surtout s’il s’agit d’un filtre un peu trop bas-de-gamme ! Ainsi, un phénomène de flare pourtant courant et souvent bien maîtrisé, peut rapidement devenir handicapant lorsque les conditions de luminosité font intervenir des sources lumineuses intenses.\n50mm f/1.8 1/400s sans filtre UV\n50mm f/1.8 1/400s avec filtre UV\nCi-dessus est pris l’exemple d’une lampe, photographiée d’abord sans filtre puis avec filtre, avec des conditions de prise de vue identiques. Dans la deuxième photographie, on distingue nettement le halo en-dessous de l’ampoule. La présence d’un filtre peut donc avoir une incidence sur la qualité de vos clichés, voire même gâcher une partie de vos photos de vacances ou de musée ! A travers cette remarque, vous ressentez peut-être le vécu de l’auteur…\nMission to Mars ? (©Adeline)\nLe second exemple ci-dessus avec un filtre Hoya Skylight 1B, permet de constater encore une fois ce reflet parasite. Plus besoin d’aller sur Mars pour voir deux satellites naturels… Avec pour source lumineuse le Soleil, on pourrait aussi se retrouver à graviter autour d’une étoile binaire, pourquoi pas ?…\nJe n’ai pas dans l’optique… de vous assommer avec des rayons incidents, des rayons réfléchis et des rayons réfractés dans tous les sens. Un tel schéma avec des lignes de calculs totalement indigestes, n’aurait aucun intérêt… Hé puis je n’ai pas les connaissances pour ça ! Mais la raison de ce phénomène peut s’expliquer simplement.\nRéflexion d'une source lumineuse derrière le filtre UV\nLe schéma ci-dessus montre sur la gauche une source lumineuse, dont la lumière traverse notre filtre incriminé, avant de traverser les lentilles de l’objectif à droite. Une partie de cette lumière est réfléchie à chaque fois qu’elle traverse un élément, et lorsqu’elle atteint le miroir et le capteur de votre appareil photo. Puisque cette lumière est réfléchie, elle part donc dans l’autre sens pour sortir de l’objectif. Et c’est à ce moment que le filtre peut poser problème : la lumière va de nouveau se réfléchir dessus pour re-partir dans l’objectif (les flêches représentées en rouge), et ainsi massacrer votre portrait de la lumineuse tante Simone. Chose intéressante à souligner, ce phénomène est d’autant plus visible que l’ouverture focale de l’objectif est importante ! Pour les photos un peu plus haut dans cet article, j’ai pris soin d’ouvrir au maximum, à f/1.8, sans quoi ce halo parasite aurait été moins visible.\nTout d’abord, pour limiter ces phénomènes de « flare », il faut malheureusement faire une croix sur les filtres UV pas chers ! Si les fabricants sortent de larges gammes de filtres, c’est évidemment pour proposer des produits de mauvaise qualité au premier prix (entre 8 € et 12 € par exemple, soit-disant pour protéger la lentille), et des produits de meilleure qualité bénéficiant de traitements anti-reflets toujours plus sophistiqués (et là, au vu de certains prix, on peut se tirer une balle). Il n’est pas non plus question de se ruiner, et il est plus judicieux de trouver un compromis. Dans une fourchette de prix commençant à partir de 20 € ou 25 €, des marques sérieuses comme Hoya proposent des filtres UV avec des traitements anti-reflets sur les deux faces, et c’est justement ce qui va permettre de réduire significativement le flare, là où les filtres bas-de-gamme ne sont traités que sur une seule face, la face extérieure.\nAcquérir un filtre de meilleure qualité ne suffit pas forcément, aussi faut-il prendre un certain nombre de choses en considération :\nD’un point de vue optique, les filtres ont un intérêt surtout en extérieur, pour les photos de paysages (le ciel, l’eau, les lointains…). En intérieur, ils ont déjà moins d’intérêt…\nD’un point de vue mécanique, les filtres permettent, bien entendu, de protéger un peu la lentille de votre objectif (poussières, rayures, traces de bras des gens qui vous bousculent dans les musées –ça aussi, c’est du vécu :evil:–). Le capuchon de l’objectif aussi, permet de protéger la lentille ; donc de toute façon, si le reflex ne sert pas, le capuchon doit être mis, filtre ou non.\nL’utilisation d’un pare-soleil aussi, peut apporter une protection de la lentille en plus de neutraliser une source lumineuse telle que le soleil pour atténuer le phénomène de flare « classique » en extérieur (et qui se résume par un « voilage » de la photo).\nDans le cas de photos avec une forte lumière ambiante (à l’extérieur en plein jour, en intérieur très lumineux…), il y a moins de risques de rencontrer ce problème particulier de flare. Toutefois, si cela arrive, il est possible d’atténuer ce flare en diminuant l’ouverture focale, tout en conservant une vitesse d’obturation acceptable (appareil au poing, car au trépied on craint moins les flous de bougé).\nDans le cas de photos avec une faible lumière ambiante mais des sources lumineuses importantes (les feux d’artifices, le sapin de Noël des gosses…), cela peut encore se produire. Il faut donc quand-même garder un oeil sur l’écran pour observer le résultat. En cas de pépin, vous aurez prévu le coup en emmenant la boîte du filtre, pour le ranger purement et simplement. De toute façon, les limites de la vitesse d’obturation se feront vite sentir avec une ouverture focale moindre, donc vous n’aurez peut-être pas le choix…\nSuite à une judicieuse remarque qui m’a été faite, voici une dernière illustration mettant en évidence le réel impact que peut avoir un filtre de mauvaise qualité, ainsi que l’impact minime d’un filtre de qualité supérieure.\nComparaison de deux filtres UV\nBon… C’est bien beau de donner des conseils, mais maintenant il va falloir que je les applique ! 🙄


Manager et cloud computing : Olivier Lefebvre - Informatique & High Tech - olivierlefebvre.fr\nLe site olivierlefebre.fr est le site personnel d'Olivier Lefebvre. Olivier Lefebvre, né en 1974 à une expérience de 15 ans dans le domaine de l'informatique. Il aime les nouveaux challenges notamment en contribuant à la croissance d'entreprises qui souhaite accéder à de nouveaux marchés et se démarquer de la concurrence. De formation technique et scientifique. Ses principales compétences s'articulent autour de capacités managériales, de gestion, doté de compétences techniques et fonctionnelles, d'une aisance de communication et de rédactionnel. Ces compétences sont complété par une approche personnalisée de la communication et du marketing, éprouvée pendant plusieurs années au sein de l'entreprise GOSIS SA. Business unit manager, rigoureux et performant, olivier lefebvre maitrise les budgets, business plan, objectifs de chiffre d'affaires, marge et rentabilité\nCabinet de conseil IT : Nexworld\nNexworld est un cabinet de conseils en IT et architecture SI, nos services tournent autour de plusieurs axes : Le Mobile Computing, l'architecture SI, les Objets Connectés, le Big Data et le Cloud Computing.


Oiseau du mois : Pic vert | COWB\nOiseau du mois : Pic vert\nPosté le 31 mars 2017 par COWB\nDu tronc d’un pommier, un gros oiseau vert et jaune s’est détaché et gagne d’un vol onduleux un arbre plus éloigné contre lequel il se plaque. Sa tête couronnée d’écarlate, au regard fixe, il joue à cache-cache derrière son paravent. A la tache rouge encadrée de noir de ses moustaches, on reconnait un mâle. La femelle est identique mais n’a pas de rouge à la moustache.\nD’une taille voisine à celle du Geai des chênes, le Pic vert est le plus connu de sa famille. La coloration générale de son plumage est d’un vert foncé sur le dos et d’un vert un peu plus clair sur le dessous du corps. Le croupion est jaune, la calotte rouge et le pourtour de l’œil noir.\nOn trouve le Pic vert le plus souvent dans les bois de feuillus clairsemés, les bois de conifères, les parcs agrémentés d’éléments de futaies et de pelouse, les vastes jardins confinant des prairies et les vieux vergers, tous des endroits où il est hôte nicheur.\n© Jaap Hoogenboom, Calendrier de l’oiseau, LRBPO, 1998\nSouvent, on l’entend avant de le voir car il signale de loin sa présence par sa voix retentissante, une rapide succession de notes assez dures, avec quelques variations dues à l’énervement agressif ou à l’inquiétude. Mais la manifestation la plus sonore est son chant, un véritable ‘rire’ claironnant rendu célèbre par le dessin animé Woody Woodpecker.\nLe pic est l’oiseau symbole de la forêt et, pour tous, l’arbre est au pic ce que l’eau est au canard. Pourtant, le Pic vert est nettement plus campagnard que forestier, affectionnant le bocage ou les grands parcs plantés de vieux arbres, avec possibilités de nicher dans une cavité naturelle, et conditionné par la présence de fourmilières. Bien qu’il travaille souvent les troncs pour y rechercher insectes et larves xylophages et qu’il passe une bonne partie de sa vie sur les arbres, le Pic vert se nourrit principalement à terre. Il fréquente souvent les prés à l’herbe courte, visitant même les pelouses rases des jardins, où il recherche, davantage que les autres pics, les fourmis et leurs larves. Il s’y déplace alors par petits bonds avec aisance, la tête levée, fouillant la terre de son long bec puissant, se servant de sa longue langue gluante, qui peut atteindre cinq fois la longueur de sa tête, pour pénétrer plus aisément les profondeurs des fourmilières. Il mange aussi, parfois, limaçons, escargots, vers de terre, graines et fruits. Il visite aussi la couche humide de l’humus recouverte de feuilles mortes, les souches et les pieux vermoulus et va parfois jusqu’à percer les ruches pour parvenir aux abeilles.\nTrès territorial, il voit en tout congénère un indésirable qu’il faut chasser. Si l’intrus ne réagit pas à la série de cris émis par le propriétaire des lieux, il se verra menacer par un éventuel combat mimé préalablement.\nSon aire de dispersion s’étend sur toute l’Europe continentale, sauf au nord de la Scandinavie. C’est un oiseau nicheur assez commun en Belgique (quelque 5 000 couples) mais plus rares en Hautes Fagnes et dans les régions poldériennes dépourvues d’arbres.\nSi les jeunes se dispersent dès le début d’août, les adultes ayant repris leurs distances, vagabondent sur un territoire plus étendu mais restent sédentaires. Il est très sensible aux hivers rigoureux qui peuvent leur être fatal.\n← Oiseau du mois hiver 2017 : Garrot à oeil d’or\nSemaine Bruxelloise de la Nature →


13 offres - Cadre de santé - Vannes (56)\n...150¤ brut Des avantages et services utiles au quotidien : santé, vie pratique, logement, comité d'entreprises. Postulez en répondant... cette annonce, ou contactez Maria au 02.22.76.06.06. Dans le cadre de sa politique diversité, Manpower étudie, à compétences...\n...intérim médical, formation et conseil dans le secteur de la santé. Aile Médicale est une filiale du Groupe SYNERGIE, 1er groupe... repas sur fiche. Vos missions : -Suivre le patient dans le cadre d'une prise en charge globale de l'hôpital jusqu'à l'installation...


Vous êtes dans :Accueil»Monde»Moyen-Orient»Mahmoud Abbas annonce la suspension de tous les accords signés avec Israël\nLe président palestinien Mahmoud Abbas a annoncé, jeudi soir, la suspension de l’application de toutes les conventions signées avec Israël.\nAbbas s’exprimait suite à une réunion des dirigeants palestiniens à Ramallah.\nIl a ajouté que les mécanismes nécessaires à l’application des décisions du Comité central de l’Organisation de libération de la Palestine (OLP) seront mis en place.\n« Nous n’allons pas céder au dictat du fait-accompli à Jérusalem et autres territoires », a-t-il insisté.\nAbbas a appelé la communauté internationale « à assumer ses responsabilités, par la prises de mesures concrètes sur le terrain pour empêcher les violations israéliennes dans les territoires palestiniens, notamment la démolition de bâtiment à Oued Homs, près de Jérusalem ».\n« Il n’y aura ni paix, ni sécurité, ni stabilité dans notre région et dans le monde tant que notre peuple n’aura pas obtenu ses droits », a-t-il laissé entendre, soulignant que « tôt ou tard, l’occupation sera vaincue et notre pays aura son indépendance ».\nAbbas a noté que le moment était venu pour appliquer la convention du Caire de 2017 conclue sous l’égide de l’Egypte.\nPour rappel, la Comité central palestinien a décidé en octobre 2018 de mettre fin à tous les engagements de l’OLP et de l’autorité palestinienne par rapport aux accords conclus avec Israël.\nLe Comité central a décidé de suspendre également la reconnaissance de l’Etat d’Israël, jusqu’à ce qu’il reconnaisse l’Etat de la Palestine et ses frontières de juin 1967 et dont la capitale est Jérusalem-est.\nPartager cet article? https://turquie2023.com/1EkHC0


Il s'appelle vincenzo barracato, de qule chanteur belge connu est-il le fils? - Questions/Réponses - Elleraconte.com\nIl s'appelle vincenzo barracato, de qule chanteur belge connu est-il le fils?\nIl vient de se lancer dans la chanson et c'est pas mal du tout son nom de scène beenzo et je préfère pour ma part les chansons du fils à celles du père\nFrédéric François !!!!!\nQuestion : Il s'appelle vincenzo barracato, de qule chanteur belge connu est-il le fils?\nDe francesco barracato connu sous le nom de frederic francois\nJe ne savais pas que Frédéric François était d'origine italienne, il faut dire que c'est un chanteur qui ne m'a jamais beaucoup intéressée, je suis curieuse d'entendre les chansons du fils qui ne doit pas avoir trop de mal à faire mieux que son père, enfin ce n'est que mon avis ...\nMerci à toi... bonne soirée. biz


Hamonville (54470) : Résultats de l'élection présidentielle 2022 - en direct\nRésultats de l'élection présidentielle 2022 à Hamonville (54470)\nComment ont voté les citoyens de Hamonville lors du second tour de l'élection présidentielle 2022 ?\nÀ l'occasion du second tour de l'élection présidentielle 2022 à Hamonville, une large majorité des votants ont plébiscité Marine LE PEN (RN), qui a remporté 68,66 % des voix. Le président sortant Emmanuel MACRON (LREM) a quant à lui récolté 31,34 % des suffrages.\nRésultats détaillés, chiffres de l'abstention... Pour tout comprendre sur le second tour de l'élection présidentielle 2022 à Hamonville, consultez notre infographie.\nRésultats à l'élection présidentielle 2d tour : Hamonville\nMarine LE PEN, RN, 68.66%\nParticipation et abstention à l'élection présidentielle : Hamonville\nCarte des résultats à l'élection présidentielle 2d tour : Hamonville\nQui est majoritaire à Hamonville lors du premier tour de l'élection présidentielle 2022 ?\nÀ l'occasion du premier tour de l'élection présidentielle 2022, les inscrits de Hamonville plébiscitent majoritairement Marine LE PEN (RN), qui remporte 44,12 % des voix. Elle progresse d'environ un demi-point par rapport à son résultat du scrutin de 2017. Crédité de 19,12 % des suffrages exprimés, le candidat LFI Jean-Luc MÉLENCHON arrive en deuxième position. Il progresse de près de huit points depuis sa candidature de la précédente élection présidentielle. Le président sortant Emmanuel MACRON (LREM) récolte l'approbation de 11,76 % des votants. C'est environ sept points de plus que ce qu'il avait reçu cinq ans auparavant.\nRésultats détaillés, chiffres de la participation... Découvrez toutes les infos sur le premier tour de l'élection présidentielle 2022 à Hamonville grâce à l'infographie ci-dessous.\nRésultats à l'élection présidentielle 1er tour : Hamonville\nJean-Luc MÉLENCHON, LFI, 19.12%\nCarte des résultats à l'élection présidentielle 1er tour : Hamonville\nHamonville : qui était en tête à la dernière élection présidentielle ?\nLors du second tour de la dernière élection présidentielle, Marine LE PEN (FN) était majoritaire à Hamonville, créditée de 65,52 % des voix exprimées. C'était 41,58 points de plus que ce qu'elle avait reçu en 2012. Le candidat LREM Emmanuel MACRON était crédité de 34,48 % des votes. C'est 31,62 points de moins que ce qu'il a remporté à l'échelle de la France.\nQuelle était la tendance au premier tour à Hamonville lors de la dernière élection présidentielle ?\nLe résultat du second tour de Hamonville est allé dans le sens de celui du premier : Marine LE PEN s'était déjà classée à la première place avec 43,55 % des suffrages, quand Emmanuel MACRON en avait récolté 4,84 %. Le report de voix a pourtant été défavorable à la candidate Front National, qui a profité du report de 11 suffrages tandis que son adversaire La République En Marche en a obtenu 17 de plus.\nL'extrême droite était majoritaire et avait reçu l'approbation de 43,55 % des votants à l'occasion du premier tour. La droite, créditée de 25,81 % des votes, avait figuré en deuxième position. La troisième position était revenue à la gauche radicale, qui avait réussi à mobiliser 11,29 % des votants. Grâce à 4,84 % des votes, la droite souverainiste était arrivée à la quatrième place. Le centre droit avait récolté un score de 4,84 %. 4,84 % des votants avaient voté à gauche. En réunissant 4,84 % des suffrages exprimés, les forces indépendantes avaient figuré en septième position.\nLes électeurs de Hamonville se sont-ils déplacés pour la dernière élection présidentielle ?\nEn 2017, 82,5 % des électeurs sont allés voter. Cela correspondait à une mobilisation 2,5 points plus élevée que celle du tour précédent.\nEn 2012, 72 inscrits sur 89 avaient mis un bulletin dans l'urne, ce qui correspondait à un taux de participation de 80,9 %. Cela correspondait à une baisse de la participation de 1,12 point par rapport à celle du premier tour.\nLes électeurs de Hamonville ont-ils voté blanc lors de la dernière élection présidentielle ?\nOn dénombrait 10,61 % de votes blancs et 1,52 % de votes nuls parmi les suffrages de la ville en 2017. À l'occasion du premier tour, on avait constaté des taux de votes bancs et nuls égaux, à hauteur de 1,56 %.


Gentil renard........ - Page 2\nle Sam 29 Déc 2007 - 10:28\nt a raison adeline\nc est comme 1 point dangereux sur la route il faut qu il y est des morts pour pour le modifier.\nle Lun 31 Déc 2007 - 16:50\nLa sécu, surtout les décideurs, ce sont tous des branquignolles. je m'explique.\nIls ne savent pas INVESTIR DANS LA SANTE\nIls BOUCHENT LES BRECHES de la santé humaine en CREUSANT DES TROUS financiers!!!\nLes exemples ne manquent pas, j'en prends un :\nLa mauvaise circulation, par exemple, ça se soigne mais dans le temps, exemple de traitement de fond. Les médicaments ne sont pas des plus chers, et on ne fait rien pour inciter à traiter sa circulation sanguine, rien n'est remboursé, donc ça leur coûte que dalle, pourtant c'est vital>>>>>donc ils mettent pas un sou pour ça, c'est pas pour autant qu'on encourage les gens dans ce sens.....\nEt au final que se passe-t-il? L'absence de ce traitement cause, entre autres toutes les maladies cardiovasculaires, lourdes à soigner, que ce soit avec succès ou en terminant grabataire ou légume, à croire que ça coute rien de gérer une personne dans cet état, alors qu'on peut éviter..... à condition de faire le nécessaire depuis 20 ans auparavant.\nPayer des médicaments pour éviter ça ne serait pas une connerie à mon avis, mais je crois qu'il ne voient pas plus loin que le bout de leur nez.\nPrévenir pour guérir, quel beau dit-on!! Mais ces bourricots là pourquoi ne l'utilisent-ils pas pour la propre santé de leur caisse?????\nAlors leur demander de faire de l'information ou de la prévention, faut pas y compter, ça coûterait trop... Sans prendre soin de calculer combien ça coûte en faisant rien... Bien plus en réalité.\nLeur demander d'informer les gens qu'en mangeant certains fruits sans précaution est dangereux, leur expliquer ce risque, là faut pas rêver\nPar contre pour vous envoyer des pubs à la con avec chaque envoi, à croire que ça coûte rien!!!! Et les pubs c'est pas bon pour la santé de la planète!!!: Là encore ils sont nuls!!!!\nOutre éviter les problèmes de santé des citoyens, ils éviteraient aussi les problèmes de santé financière de leur caisse.lol!:\nLà il faut croire que ça les dépasse.....\nTout ça un soir de réveillon!!!\nVivement 2008, soins gratos\nle Lun 31 Déc 2007 - 17:00\nDis toi une chose les hommes politiques sont élus pour 5 ans donc c'est leur seul objectif =5 ans quel que soit leur parti;les projets à long terme,ce n'est pas leur problème,ce sera au suivant de s'en occuper etc.....\nle Lun 31 Déc 2007 - 17:46\nTout à fait, les réformes de fond, ne peuvent être menées que par des gens qui connaissent bien le sujet. Quand ils connaissent, il sont près de la sortie !!!!!\nle Mar 1 Jan 2008 - 18:04\nRemarquez, à la fin du film on voit bien que le renard ne peut devenir un animal de compagnie vu qu'il devient fou et se jette de l'étage.\n'Fin à ce qu'on m'a dit !\nJe vais plutôt aller voir "Je suis une légende" ou bien encore "Hitman" que ce film demain avec des amis...\nle Mar 1 Jan 2008 - 19:02\nJe n'irai jamais voir un tel ramassis de sensibleries impropres à la Nature elle-même!\nJe prêche intensément contre toutes formes d'anthropomorphisme, de sentimentalisme et de bébéphilie dont SEULS les humains sont dotés!\nC'est exactement le genre de fiction que les escrolos ramènent et qui contribue par la suite à perturber l'équilibre de la biodiversité... Fi ! Nos très chers anti-chasse ne jurent que par le cinéma et des animations fictives pour essayer de réfuter nos arguments...\nle Mer 2 Jan 2008 - 18:52\nEt après quand les gamins deviennent grands et qu'ils voient ça:\nIls penseront plus à considérer le chasseur comme un assissin, que quelqu'un qui est souvent indispensable à l'équilibre des écosystèmes, et ne songera pas à son voisin totalement enkysté par l'échinococcose... Les images frappent et on ne retient pas souvent le principal!\nle Mer 2 Jan 2008 - 20:37\nalexandre77 a ecrit : Ils penseront plus à considérer le chasseur comme un assissin, que quelqu'un qui est souvent indispensable à l'équilibre des écosystèmes, et ne songera pas à son voisin totalement enkysté par l'échinococcose... Les images frappent et on ne retient pas souvent le principal!\nle Jeu 3 Jan 2008 - 7:58\nEt il y a des restrictions d'age pour les films violents, car ils sont susceptibles de perturber le bon dicernement des enfants, pourtant ce genre de film entraîne le même type de troubles, mais dans quelques mois, on pourra certainement le voir sur une chaine télé à une heure de grande écoute! Forcément, on ne peut pas peser lourd, car jamais on ne verra sur la même plage horaire une émission montrant l'importance des dégats du renard sur certains agrosystèmes, ni de chirurgien enlevant les kystes musculaires de ce parasite sur la table d'opération (trop violent pour les momes pensez bien ça risquerait de les perdurber ça!)\nle Mer 9 Jan 2008 - 13:57\nje tiens à faire part de mon opinion (c'est un forum après tout!)\ncaneton a dit :"Alors que certains veulent faire de ce petit animal une victime des chasseurs, piégeurs, etc, on prend bien soin de ne pas informer le public que cet animal est porteur et vecteur d'une maladie mortelle pour l'homme : l'échinococcose alvéolaire, que plus de 200 victimes ont déjà été enregistrées dans notre pays.\nPourquoi ce silence??? Silence peut-être.....Mais de là à faire de la pub pour cet animal, de là à bourrer le crâne de nos enfants, et de pas mal de leurs parents en passant, il convient de réagir et d'informer sur le réel danger que représente cet animal."\ntu sais je crois que le réel et pire des dangers dans le monde c'est l'être humain!il détruit la planète tout ça pour son confort, l'argent, le pouvoir....l'être humain n'a toujours pensé qu'à sa gueule...résultat, une terre qui meurt(et ça ce dit supérieur!!!?)\nje suis d'accord avec Adeline ("Le pb c'est que après ce genre de film tout le monde veut approcher ou obtenir ces animaux "star"), il est clair que ce genre de pub n'est pas nécessaire et c'est clair que les gens sont trop influencé par les médias, le problème c'est qu'un animal sauvages n'a rien à faire en captivité, chacun sa place, et ce genres de personnes n'en ont rien à faire de l'animal , il le prenne comme un objet, ce qui est ridicule, ce sont des êtres vivants, et qui plus est de l'espèce animal, comme nous, ce ne sont pas des nounours en peluche!!\nd'autre part, thierry51 tu dis "on ne montre pas non plus qu'il va casser la croute sur des petits lapins et des jolies oiseaux", c'est ironique???non parce que je vois mal un renard aller chercher un steak chez le boucher du coin!!c'est normal qu'un carnivore mange des lapins et des oiseaux faut bien qu'il se nourrise!!!!\nje suis contre les braconnier, pas contre les chasseurs,certes ils permettent un certaines équilibre, mais je trouve ça injuste, car après tout c'est nous qui bouffons leur territoire, c'est nous qui détruisons tout!!!l'homme a vraiment mal géré sont évolution!!!\n@ludwig a écrit: bonjour,\nd'autre part, thierry51 tu dis "on ne montre pas non plus qu'il va casser la croute sur des petits lapins et des jolies oiseaux", c'est ironique???non parce que je vois mal un renard aller chercher un steak chez le boucher du coin!!c'est normal qu'un carnivore mange des lapins et des oiseaux faut bien qu'il se nourrisse!!!!\nLà je crois que tu vas un peu vite en disant que l'être humain est le premier des parasites, entre autres.\nDe tels propos, nous les entendons généralement sortant de la bouche des anti-chasse, anti-tout ou n'importe quoi, sans savoir de quoi ils parlent.\nOn l'entend aussi et surtout sortant de la bouche des fumeurs de canabis, de tous ceux qui se disent écologistes pour se donner bonne conscience. l'écologie, c'est gratuit à en parler. Mais je pose la question qui fait quoi en la matière???? J'attends des réponses concrètes, les blablas, merci laissons ça à ceux qui nous critiquent.\nMaintenant si tu veux crever d'une tumeur origine parasitaire, c'est ton problème, mais n'empêche pas ceux qui se sentent responsables d'informer correctement.\nTu es bien libre de penser ce que tu veux sur l'environnement, mais avant de le commenter sauce masturbing-vert, il te faudra quitter tes culottes courtes.\nDe plus critiquer au sens large du terme la gent humaine comme tu le fais m'amène à te demander si tu ne préférerais pas être réincarné en renard.\nPS je note sur ton profil localisation "partout", cela en dit long sur ton raisonnement, pour ma part ce que j'écris, je l'assume, je le fais en mon nom, pas en me cachant derrière des "idées" si tant est que c'en soit! et si tu veux mon téléphone, je veux bien te le communiquer. pour info sur ce forum, j'ai posté très longtemps sous mon vari nom, car j'ai rien à cacher et pas de conneries à raconter.\nle Mer 9 Jan 2008 - 14:43\nAvant de ramener sa science, encore faut-il en avoir une !\nle Mer 9 Jan 2008 - 14:47\nLudwig, en effet c'est un forum où chacun peut exprimer son opinion, mais par contre je pense que le minimum avant d'intervenir sur un tel sujet et d'ouvrir un débat serait au moins de se présenter !\nle Mer 9 Jan 2008 - 17:39\nTypique d'un écologosiste récationnaire.\nOn est tous écologiste içi, mais je ne pense pas qu'il y ait une autre personne à part toi totalement dégoûté de l'espèce humaine.\nle Mer 9 Jan 2008 - 18:34\nPr ma part , je pense que lorsque tu as commenté ma phrase ; tu la mal interprété ...\nSinon je suis d accord sur le fait que l homme est le principal prédateur. tu dis qu'il detruit tout.\n-Non ; il detruit bcp ; certes mais il sauvegarde également beaucoup de choses\nle Mer 9 Jan 2008 - 18:59\nLe sujet n'est pas là!!!\nIl est de savoir si certains hommes doivent cacher à d'autres que la mort les guette au virage avec leur chien ou chat errant ou dans les pissenlit, les fraises et autres!!!!\nOn peut bien sodomiser les mouches au vol pendent 107 ans à savoir si l'homme est prédateur et dans quelle proportion, mais à côté de ça pourquoi cacher la vérité, l'information c'est gratuit.\nUn certain Monsieur Garetta , lui aussi a caché les risques du sang contaminé, et quand ça a été connu, un certain Fabius a lui aussi donné l'autorisation de mise sur le marché, cachant aux transfusés qu'ils allaient crever un jour d'hépatite ou de sida. Fallait-il là aussi cacher le pipi sous la moquette????\nDemandez aux victimes et à leur famille ce qu'elles pensent, s'il fallait ou non informer.\nL'ampleur de la cocose n'est heureusement pas à ce niveau, mais un peu de cocose par ci, un peu d'hydatiose par là, un peu de leptospirose, un peu de tularémie, un peu de brucellose, on a tous les ingrédients chez les animaux pour nous contaminer. Que nous soyons prédateurs, c'est certain, mais nous faisons partie du sytème comme tel depuis toujours. C'est pas pour autant qu'il faille se contenter de dire ça, et de s'en servir de prétexte pour rester les deux pieds dans le même sabot. En deux mots, il faut être responsable et adulte.\nle Mer 9 Jan 2008 - 21:42\nbien parler les gars je suis entierement d accord.\nadrien a raison il faut te presenter ludwig histoire de savoir qui tu est et a qui l on a faire.\nil y a tellement d espions qui disent et font n importe quoi que maintenant j ai un doute sur toi .\npeut etre t exprime tu mal.\nalors presente toi mieux vaut tard que jamais et puis c est plus poli car ici ce n est pas un moulin.\nle Mer 9 Jan 2008 - 21:54\nslt je n'est pas vue le film donc je juge pas mais les gens ne se rande pas cnte qe si on ne chasser put le renard par exemple et que il y aurait des renard patout dans les vill a faire les poubelles et mettre du desorde partout jpense qui verait le renard autrement,e pense assi qu'on dit que leschasseur tue tout ou detruise tout a cause d certain films de chasse ou a la fin de la parti dechasse il y a 20 sangler de mor e 15 cerf et autant de chevreuil entre paranthese je pense que l'on devrait interdir c'est video car c'est plus de la chasse il n'y a plus de plaisir et de sport dans cela c'est de la turie et sa montr une trés mauvaise image de la chasse et nous chasseur honete e raisonable on en paye les consequense\nle Mer 9 Jan 2008 - 22:50\nleptitchasseur, avant, il faut voir aussi les réels populations de gibiers avant de juger sur des images !\nle Jeu 10 Jan 2008 - 9:15\nEffectivement c'est le problème du rapport de la population réelle et du prélèvement.\nUne vidéo ne montre qu'une partie de l'équation, bien évidemment celle que l'on veut faire avaler...\nComme le film ne montre que ce qu'il veut faire avaler...\nEt ça marche bien, preuve en est>> ce sujet malgré les relances passe régulièrement à côté du débat pour revenir à chaque fois sur le film ou sur une vidéo, qui l'un comme l'autre nous desservent. >Et inconsciemment tout le monde contribue à l'objectif des auteurs escrologistes.\nRemuez, remuez, il en restera quelquechose... Alors que les risques de maladies, hé bien, silence ils passent à la trappe.\nAussi je me demande bien pourquoi certains se cassent la tête à faire de l'information réelle face aux escroqueries morales médiatisées..\nle Jeu 10 Jan 2008 - 15:15\nles gens ont besoin de rêve, les éscrolos sont là pour leur en fournir... C'est tout simple.\nSeulement il faut savoir se réveiller!\nD'ailleurs quand j'arrive à faire retrouver la raison à un écolo, j'appelle ça "l'éveil".\nle Ven 11 Jan 2008 - 6:33\nj'aime bien le mot"escrologiste"\nle Ven 11 Jan 2008 - 8:45\nje sais pas qui l a invente mais c est bien trouve peut etre adrien ou un autre le sait.\nHo non , désolé, j'en revendique l'importation il fait partie de mon vocabulaire spécifique depuis bien des années, et je crois bien être celui qui l'ait amené sur ce forum depuis pas mal de temps.......


Louange du jour : Je vais me réjouir en l’Eternel ! – Foi, Espérance & Vie\nLouange du jour : Je vais me réjouir en l’Eternel !\nCher tendre Père céleste, je viens Te louer pour Ta fidélité et Ta bonté dans ma vie ce nouveau jour, ce beau dimanche que Tu as fait. Je crois de tout mon cœur, que chaque jour est un nouveau que Tu fais et qui doit être pour un sujet d’allégresse et de joie.\nJe Te loue parce que Tu m’as gardé, Tu as gardé ma famille restreinte, ma famille dans le Corps de Christ, ma famille élargie et tout ce qui nous appartient durant toute cette semaine.\nJe Te loue pour Ta Parole puissante qui soutient toute chose et qui soutient ma vie.\nPère céleste, c’est Toi le Dieu de mon salut, c’est Toi qui m’as formé de la poussière de la terre, c’est Toi qui me soutiens depuis ma naissance, c’est Toi la source de tout ce que je suis, de tout ce que j’espère.\nJe fais mon choix de pouvoir Te louer et me réjouir en Toi peu importe ce qui se passe dans ma vie. Laisse que ma louange soit l’expression de ma foi, de ma confiance, de ma soumission en toi.\nJe Te loue parce que si tu peux faire que la poussière devienne une âme vivante, Tu peux faire encore beaucoup mieux et plus pour une âme vivante que je suis.\nJe Te loue parce que même si les choses ne marchent pas comme je les avais prévues, je crois que Tu as un plan meilleur qui est déjà en exécution et qui prendra le dessus de mon plan.\nComme Habacuc, ce matin je dis :\nEt il me fait marcher sur mes lieux élevés. »\nJe Te loue parce qu’en dépit de tout ce qui m’arrive, Tu m’accordes toujours Ton salut. Je Te loue parce que Tu es ma force, tu rends mes pieds semblables à ceux des biches et Tu me fais marcher sur mes lieux élevés.\nSois béni à jamais et à perpétuité. Tu es un Dieu Fidèle et Juste. Tu es Incomparable et Insondable. Tu véritable et Bon.\nC’est dans le glorieux, le précieux nom de Jésus-Christ de Nazareth que j’ai ainsi loué.\nLouange du jour Dieu de mon salut, Dieu est ma force, Je veux me réjouir en l'Eternel, Louange 6 commentaires\n← Je vais me réjouir en l’Eternel!\nL’éclat de Sa gloire 26ème partie: « Le Psaume 150 – suite et fin » →\n6 commentaires sur « Louange du jour : Je vais me réjouir en l’Eternel ! »\nAmen, amen, amen. Gloire à Celui qui est digne de notre louange et notre adoration.\n28 juillet 2015 à 1 h 20 min\nhosanna hosanna a toi agneau de DIEU!