Kioob

Il n'existe aucun soft gratuit qui gère tout de A à Z. Techniquement ça se passe à divers niveaux : - configuration DNS du domaine utilisé pour l'envoi (SPF, DomainKeys, SenderID, DKIM, etc) - configuration du reverse DNS de l'IP utilisée pour l'envoi - configuration du serveur de mail utilisé sur la machine, avec ajustement des règles de "retry" pour chaque "FAI" - utilisation d'un soft de mailing qui gère les messages d'erreur de retour (car trop d'erreurs => blacklisté) Et sans oublier la mise à jour régulière de tout ça. Ca c'est le minimum, et il ne faut pas négliger non plus le contenu et le formatage du mail en question... c'est également un gros point. Certains de mes clients ont choisi de tout gérer "eux même" : c'est à dire que je me suis chargé de la configuration d'origine de la machine, qu'ils ont fait développer le soft de mailing avec gestion des bounces, et qu'ils se chargent eux même quotidiennement de la surveillance du tout, de se faire whitelister auprès de chaque fournisseur, et de faire une vieille technologique sur toutes les techniques du genre etc etc. Ca prend énormément de temps, et a un certain coup malgré tout. D'autres ont opté directement pour des solutions pro, et ne se prennent plus la tête avec l'envoi de mails. Après tout dépend de ton volume effectivement.... et de ton budget.

Effectivement j'étais à coté de la plaque : je pensais que tu voulais vérifier en début de script qu'il s'agissait bien d'un appel via include() et non d'une exécution directe. Mais ce que tu cherches à faire semble totalement différent, et je n'en comprends pas le but... dsl, et bon courage

Pour l'emailing tout ce qui est gratuit prend énormément de temps et demande beaucoup de connaissances dans divers domaines... Après c'est un choix.

Pour une moi une jointure "externe" (aussi appelée "semi jointure") c'est une jointure partielle à coup de LEFT|RIGHT join... ce que SQLITE supporte d'ailleurs. C'est un peu expliqué ici : http://fr.wikipedia.org/wiki/Structured_Query_Language D'ailleurs, la liste des limitations de SQLITE est sur le site officiel. Donc le LEFT JOIN est bien supporté mais pas le RIGHT JOIN... y a pas mort d'homme quoi. De manière générale il supporte bien plus de choses qu'un MySQL 4.0 voir un MySQL 4.1 ; qui sont pourtant encore très répandues.

Pour être plus précis : faire de grosses concaténations comme dans ton premier exemple n'est certainement pas l'idéal. Faire la même chose sans concaténation ( echo 'chaine 1' , 'chaine2'; ) est mieux, mais à la condition également que l'output_buffering de PHP soit activé (ce qui est le cas si la compression interne à PHP est activée par exemple). En mode "CLI" au contraire il vaut mieux faire les concaténations avant, à cause du "flush" automatique. Frédéric Bouchery avait rédigé un petit article à ce sujet il y a quelques temps ; mais il a visiblement fermé son blog... dommage. Enfin, j'ai beau être assez pointilleux sur pas mal de choses, là je trouve que c'est quand même chipoter Ce que je n'aime pas ce sont les traitements inutiles. Quand tu utilises des doubles quotes à la place de simples quotes, cela implique un traitement d'analyse de la chaine pour y retrouver des variables ; là pour moi c'est effectivement un vrai gaspillage (même si l'impact est ridicule). Mais y aller à coup de concaténation pour éviter d'utiliser les doubles quotes n'est pas plus malin pour autant, le résultat n'étant pas forcément mieux. Il en est de même pour l'opérateur de comparaison : pour moi, par défaut il faut utiliser le triple égal. Ainsi on évite à PHP de faire des "transtypages" souvent inutiles, et c'est plus "rapide". Par contre lorsque tu n'es pas certain du type de tes variables, et que dans le contexte en question une chaine vide est la même chose que NULL ou false, bah le double égal est certainement plus adapté oui. S'intéresser à la consommation des ressources c'est plutôt bien oui, mais dans certaines limites peut être ? Là tu chipotes sur ce genre de choses alors que comme chez beaucoup de monde il y a des chances pour que la compression des pages interne à PHP (zlib.output_compression) ne soit pas activée, bien que l'impact coté visiteur (comme serveur d'ailleurs, le slot Apache étant libéré plus tôt) est certainement plus important.

Les gens cherchant à faire ça utilisent généralement une constante (define() / is_defined()).

Hello, Pour tester le fait qu'une fonction soit déclarée il y a function_exists() ; mais tu cherches à faire quoi au juste ? :S EDIT : grillé en beauté

Hello, premier cas : je dirais que ça importe peu. Quitte à choisir pour les perfs j'opterais pour l'absence de concaténation (en remplaçant les points par des virgules), et pour la lisibilité la seconde version. Dans les 2 cas je ne suis pas certain que ça change quoi que soit, généralement les optimisations ne se font pas vraiment là dessus. deuxième cas : délicat. S'il y a peu de données, qu'il n'y a que très peu d'écriture, pas besoin d'utiliser de verrous, et que c'est relativement bien codé, alors le fichier sera certainement beaucoup plus performant oui. Mais ça fait beaucoup de "si".

Par contre coté perfs de lecture, je ne suis pas certain que ce soit moins bon que MySQL. Cela dépend sûrement des cas, mais c'est plutôt très performant comme petit truc. Pour les écritures il ne faut surtout pas oublier les transactions, sinon les perfs sont catastrophiques. Mais actuellement je ne m'en sers que pour de petites bases...

Donc en gros l'interface coté LWS ne permet que de configurer leurs propres DNS (ns1.lwsdns.com et ns2.lwsdns.com)... Finalement tu cherches à faire quoi avec ton domaine ? Utiliser les DNS et l'hébergement d'OVH, c'est bien ça ? Je n'ai jamais eu de mutualisé chez OVH, mais je suppose qu'il doit falloir déclarer ton domaine quelque part... l'as tu fait ?

Bah soit l'interface de LWS ne se synchronise pas correctement avec l'interface OVH, soit ce sont les DNS d'OVH qui merdoient fortement. Sinon pas la peine de tester depuis 36 FAI : il suffit d'interroger directement les serveurs DNS indiqués dans le whois pour voir que la config est fausse.

Hello, dans le whois du nom de domaine le proprio est indiqué comme : Ca correspond à toi ? En tous cas en date de modification c'est bien le 24/07/2008 qui est indiqué, et les DNS sont bien les tiens. Par contre coté OVH effectivement ce n'est pas à jour : je ne sais pas s'ils suivent les conseils de la RFC pour les numéros de version, mais la version actuelle est 2008042601... et je confirme l'IP 213.186.33.4. Le fichier de zone que tu vois c'est sur l'interface d'OVH ? Parce qu'il ne correspond pas à ce qu'annoncent leurs serveurs.

Déjà mettre la rotation des logs Apache toutes les nuits ne serait pas du luxe : vu que tu as une debian, c'est dans /etc/logrotate.d/apache2 que ça se règle, il faut remplacer le weekly par daily et éventuellement diminuer la quantité de logs conservés (le rotate 52). Pour ton blocage, c'est typique d'un blocage coté MySQL : une requête mal foutue verrouille une table importante, toutes les pages du site accédant à cette page se retrouvent bloquées, le nombre de connexions MySQL simultanées ainsi que de connexions Apache augmente fortement jusqu'à ce que la limite coté MySQL soit atteinte (too many connection), ou Apache ne réponde plus (nombre de slot arrivé à saturation), ou encore que la machine soit à genou (manque de mémoire => swap, etc). Bien sûr, ce n'est pas forcément ça non plus... mais il faudrait commencer par regarder ce qu'il se passe vraiment plutôt que de tout de suite couper Apache et MySQL. Faire un "show processlist" dans MySQL dans ces cas là te permet de voir ce qui a foutu un tel boxon.

Sans savoir ce que tu comptes faire, ça va être difficile de répondre... Dans tous les cas ce sera toujours très relatif : pour un néophyte, n'importe quel site sera compliqué à mettre en place. Donc cela va surtout dépendre du "niveau" de la personne qui va t'aider. Pour le coût bah... 2 ou 3 brouzoufs je pense, selon l'age du capitaine surtout.

Ce ne serait pas en cas d'une détection de langue du navigateur différente du FR ? (et que par défaut il afficherait le FR si rien n'est indiqué)

De manière générale pour "débogger" ce genre de truc, ne pas oublier de faire un "afficher source" dans ton navigateur ; après tout l'HTML est interprété...

Hello, à ce niveau ça sent surtout l'erreur d'étourderie. Donc donne nous le code exact que tu utilises pour vérifier ça.

Si tu fais une autre jointure alors que tes principales sont liées à coup de "group by", ça peut vite devenir imbuvable comme requête (coté perfs, j'ai du mal à me faire une idée par contre). Du coup j'aurais tendance à séparer de cette manière : select XXXX from table3, ( select ZZZZ, YYYY from table1 left join table2 on [...] where [...] group by ZZZZ ) t4 where t3.bidule = t4.chose Ce n'est pas forcément mieux... il faudrait un exemple concret, mais dans l'idée c'est ça. Enfin coté lisibilité, la vue est encore mieux et fait à priori exactement la même chose.

A moins de faire un "max(id_command)" et croiser les doigts pour que les numéros de commande soient dans l'ordre chronologique, non tu ne peux pas directement obtenir l'id correspondant à la commande la plus récente. Tu es obligé de passer par une requête imbriquée (ou table temporaire, ou encore une vue).

Non la syntaxe ne devrait rien changer à cela. Toutefois j'ai remarqué auprès de collègues qu'en utilisant la syntaxe "JOIN" les conditions de jointure étaient beaucoup moins souvent oubliées... Pour la configuration de ton serveur MySQL, essaye de jeter un oeil sur WMC. Il y a même un outil qui aide à la configuration.

Hello, le premier cas me semble un peu beaucoup une usine à gaz... et la gestion du protocole HTTP semble bien hasardeuse. Mais l'avantage est que tu peux configurer les entêtes envoyés et gérer un éventuel timeout (ce qui n'est pas fait ici). Autre avantage, ce code n'est pas dépendant du paramètre "allow_url_fopen". Mais un simple file_exists() ne serait il pas plus efficace que ton fopen ? (ce serait probablement une requête HEAD envoyée au serveur plutôt qu'une GET).

De rien dexmon Crocxx : je ne suis pas certain de comprendre la question :$ Si tu parles du fait de changer la langue des messages d'erreurs, ça m'étonnerait que ça change quoi que soit. Surtout qu'en théorie des erreurs il n'y en a pas souvent Si tu parles de la configuration multi fichiers de MySQL ; ça doit bien faire perdre quelques millisecondes au démarrage de MySQL oui... mais... dans 99% des cas ça n'a pas d'importance, si ?

Hello, pour du ponctuel MySQL, le plus "simple" est de se connecter au serveur MySQL et de lancer un "show processlist". Mais pour un suivi en temps réel, "mytop" est plus pratique. Il en existe pas mal d'autres du genre. Sinon sur WMC (désolé) il y a un petit topic dédié à l'administration de MySQL. Mais un monitoring permanent de la machine ainsi que de ses services sera toujours utile (Munin, Nagios, Cacti, etc). Dans les grandes lignes : %us "user" : pourcentage d'occupation en zone "utilisateurs" (la plupart des applications) %sy "system" : pourcentage d'occupation en zone "système" (grosso modo le kernel) %ni "nice" : comme le "user" mais uniquement pour les programmes dont la priorité a été modifiée via "nice". %id "idle" : pourcentage de glandouille %wa "wait IO" : pourcentage d'occupation en attente d'entrées/sorties (typiquement les accès disque) %hi / %si / %st : aucune idée dsl. Mais en faisant un man top tu obtiendras certainement les définitions exactes. Bah... tu as combien de processeur ? Eventuellement, fais un cat /proc/cpuinfo pour voir le nombre de processeur considérés par le noyau (avec l'hyperthreading des Pentium 4 le nombre peut-être doublé). Là comme ça en tous cas ton MySQL semble bouffer tout le CPU, tu n'as à priori aucun soucis d'accès disque et plein de mémoire libre ou pas vraiment utilisée. Je peux me tromper mais oui ton serveur MySQL a l'air assez mal configuré. Mais après tout, ce n'est peut être qu'une vilaine requête MySQL accédant à tes tables mal indexées...

Blop : théoriquement tu peux oui... mais l'espace occupé par les différents fichiers de log peut s'avérer assez conséquent ; sans oublier l'espace utilisé par le système de fichier, puis par l'OS. Il vaut donc mieux prévoir une bonne marge.

re, yep, c'est le chemin complet du fichier qu'il faut donner, probablement à coup de /home/http/NOMDUSITE/httpdocs/script/[...] ; et il faudrait s'assurer que chaque dossier soit accessible par MySQL ainsi que le fichier aussi... Enfin si c'est du Plesk ce n'est certainement pas sécurisé, donc aucun problème de droits d'accès : il te suffit de donner le bon chemin d'accès au fichier.