Kioob

si, c'est le "bind" de variables et c'est ce que permettent les extensions mysqli et pdo... comme conseillé au dessus.

Le forum du Hub remplace les arobases par "_AT_" (même lorsque c'est entre balises [ code ]...), je pensais que tu l'aurais remarqué désolé. Il faut donc modifier le code ci dessus et remplacer à nouveau les _AT_ par des arobases.

<hs>Perso je n'utilise jamais mon adresse directe, vu que cela me sert également à classer les mails. Et c'est bien là le soucis à mon avis, "disposable" n'implique pas "temporaire" pour moi (ainsi que mes clients d'ailleurs).</hs>

Hello, tu as trois listes en bas de cette page : http://en.wikipedia.org/wiki/Disposable_e-mail_address Toutefois ça ne couvre pas exactement les boites "jetables" (mais certains domaines de la liste que tu as fournie sont des DEA). Pour ma part je n'utilise pas de boite jetable, mais utilise très souvent des "disposable email"... tout comme certains de mes clients d'ailleurs. Je trouve donc assez dangereux de vouloir condamner ce genre de pratique. EDIT : encore grillé :'(

re, je pense que la machine est largement assez puissante oui, peut être à condition de configurer ça un peu. Par exemple diminuer le KeepAlive d'Apache à 2-3 secondes est bien souvent obligatoire pour éviter une saturation trop rapide. Et coté MySQL, je ne sais pas ce que consomme Wordpress, mais il se peut que les buffers par défaut ne soit pas suffisamment dimensionnés. Après il peut y avoir des centaines de petits détails à configurer... ce n'est pas pour rien que CTN1 propose une formule "infogérée"

Non, il faut plutôt regarder la ligne ajustée en fonction du cache (-/+ buffers/cache), qui indique 867Mo de libre. Pour les logs, vaut mieux les consulter directement via SSH : less, grep, awk, wc, tail, head sont des outils assez pratiques pour cela. Mais il y en a sûrement d'autres.

mysql_query( "set _AT_compteur:=0" ); $sql_societe = "SELECT soc_raison,soc_respon,soc_id , _AT_compteur:=@compteur+1 AS test FROM societe ORDER BY soc_raison ASC LIMIT 0,15"; if ($result_societe = mysql_query($sql_societe, $link) or die ('Erreur : '.mysql_error() )) {

hello, c'est surtout parce qu'il s'agit de deux requêtes. Sépare les, ça devrait fonctionner.

Si, avec free -m par exemple. Ou top pour surveiller en continue.

Hello, pour ma part j'aurais tendance à chercher à déléguer le plus possible à MySQL : est ce génant si tous les cas de type 0/3/1/4, 3/1/4/0, 1/4/0/3, 4/0/3/1 sont stockés en base sous forme de 0/3/1/4, ou bien tu as une perte d'info ? Si ce n'est pas génant, un simple algo coté PHP d'uniformisation au moment du stockage te permettrait de directement utiliser les opérateurs de comparaison de MySQL. Si ça l'est, prévoir éventuellement un double stockage : ajouter une colonne qui contiendrait la version "uniformisée" de ce champ. Ensuite s'il y a d'autres opérations plus "complexes" de comparaison, je me baserais sur des procédures stockées, coté MySQL donc (si ton hébergement te le permet).

Hello, de quel tuto parles tu ? implode("",@file($fichier)) Beurk... difficile de faire pire ici : lire un fichier, le scinder ligne par ligne et tout stocker dans un tableau PHP, tout ça pour ensuite re-concaténer le tout. file_get_contents() serait déjà beaucoup plus propre. Sinon le débugage me semble relativement simple : 1) comme ton var_dump() l'indique, la fonction lit_rss() retourne NULL 2) la fonction lit_rss() ne fait son return que si la lecture du fichier s'est bien passée et que celui ci n'est pas vide. Mais comme tu masques les erreurs grâce à l'arobase, on ne sait même pas si la lecture s'effectue correctement. => commence par enlever ça 3) traiter un flux XML à coup de preg_split(), c'est quand même pas ce qu'on fait de plus fiable. => Utilises plutôt SimpleXML (nécessite PHP 5). 4) ton tableau $tmp3 est initialisé nul part, si bien qu'en cas de soucis avec ton traitement preg_split(), tu fais un return d'une variable non déclarée. => Initialise le.

Idem : RoundCube est simple à installer, à configurer et à utiliser. Tout en étant assez rapide. Il est plutôt basique, mais pour le moment c'est celui que tous mes clients préfèrent.

Je confirme APC est maintenant activé sur votre serveur : en standard à chaque fois qu'on accède à une page "dynamique" de votre site (typiquement une page en .php) PHP "recompile"* tout le script avant de l'exécuter. C'est lent et parfaitement inutile. Le "cache d'opcode" se charge donc de conserver en mémoire le résultat de cette compilation afin de pouvoir exécuter aussitôt les scripts, sans traitement superflu. Selon la structure des sites, la différence de performance peut être énorme. Pour ce qui est de l'utilisation du sous domaine phpadsnew, oui il est parfaitement possible que suite à une faille de phpadsnew un script y ait été installé afin de diffuser ce fameux Live via votre serveur... Il faudrait remonter plus loin dans les logs et/ou regarder les statistiques de consommation de bande passante (ça l'hébergeur doit certainement le fournir sur votre compte client) afin d'en avoir le coeur net. En tous cas s'ils tombaient sur une erreur 403, ça m'étonnerait que ce soit la source des problèmes... ce type d'erreur ne passant généralement même pas par PHP. Idem pour les erreurs 404 qu'il y a maintenant, ça ne consomme quasiment rien, donc aucune sécurité à mettre en place de ce coté. Par contre si un "pirate" a eu à un moment accès à la machine, ça peut être très génant oui. *compiler : consiste à transformer un code source lisible par un humain en un fichier binaire exécutable par une machine. (cf : Wikipedia).

re, quel correctif de sécurité ? (APC - qui n'a rien à voir avec une sécurité - n'est pas actif en tous cas ; à moins qu'Apache n'ait pas été relancé ?) phpAdsNew n'a pas la réputation d'être léger, donc c'est possible que le serveur charge à cause de ça oui. Mais sans "chiffres" indiquant l'ampleur de l'utilisation de ces scripts depuis l'extérieur, difficile à dire. A priori une règle .htaccess d'anti "hotlink" ferait l'affaire (faire une recherche sur le forum ou google à ce sujet) Il n'y avait pas un "live" de l'émission diffusé via phpadsnew ? Les sites en question auraient simplement cherché à copier le contenu.

re, si j'en crois mon survol de ce site, un simple "yum install php-pecl-apc" devrait suffire à l'installation d'APC (qui est un des principaux cache d'opcode). Quitte à relancer Apache ensuite (service httpd restart). Mais n'hésite pas à demander confirmation à ton hébergeur avant.

La "bonne nouvelle" c'est qu'il n'y a visiblement aucun cache d'opcode en place sur la machine. Ce qui explique en partie la consommation CPU de PHP. La mauvaise c'est que je ne suis pas certain de moi pour la procédure "correcte" à utiliser sur une Fedora Core (j'utilise uniquement Debian). Pour ce qui est de l'intervention, le mieux serait que tu t'adresses à quelqu'un connaissant un peu mieux cette distribution.

Pour le phpinfo tu crées un script par exemple "hub-info.php", et dedans tu mets uniquement "<?php phpinfo();". Tu mets ça sur le site via FTP puis tu nous donne l'adresse. Pour le monitoring, je suppose que s'il y en avait un tu serais au courant, donc tampis. Non merci, si j'interviens moi même je facture (et en l'occurrence l'accès SSH serait plus utile que l'accès FTP)

re, le "lsb_release" permet déjà de savoir quelle distribution tu utilises ; là on peut voir une Fedora Core 6. Ce qui ne m'arrange pas vraiment d'ailleurs... mais on va faire avec. Sinon pour le top, en vrac : "load average: 1.13, 0.70, 0.49" => charge 1.13, avec un seul processeur en gros ça nous fait du 113% c'est pas génial "Cpu0 : 43.3%us, 3.7%sy, 0.0%ni, 52.7%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st" => environ 47% du CPU occupé, pas génial non plus mais au moins il n'y a pas d'occupation disque (le 0.0%wa). "595500k cached" => pas loin de 600Mo de mémoire utilisés pour les différents caches (dont le cache disque), c'est plutôt bon signe la machine est loin de manquer de mémoire (ou bien elle ne sait pas s'en servir, ce qui arrive aussi). Et des lignes suivantes on peut voir que c'est httpd (Apache+PHP) qui bouffent ces ressources. Et du peu de lignes "httpd" présentes, ça m'étonnerait que ce soit une saturation du nombre de slots Apache. Ca n'explique certainement pas un crash serveur, mais ça laisse peu de manuvre coté CPU à mon avis : quand le processeur est complètement surchargé la consommation mémoire augmente en flèche et on arrive rapidement un crash de la machine s'il n'y a pas les limitations adéquates. En tous cas Apache en lui même consommant généralement peu de CPU, j'aurais tendance à miser sur PHP comme coupable. Un cache d'opcode est il installé sur le serveur ? (si tu ne sais pas, mets un script sur le site contenant uniquement "<?php phpinfo();" afin qu'on y jette un oeil) PS : je n'ai pas pensé, mais tu n'aurais pas un mrtg, un munin ou un cacti installé sur cette machine, qu'on voit les courbes d'utilisation des ressources ?

Hello, avant de réinstaller la machine personnellement je regarderais la configuration des outils en question (probablement Apache, PHP et MySQL). La plupart des hébergeurs livrent effectivement les machines avec les logiciels installés, mais pas configurés pour autant. Enfin déjà : de quelle distribution s'agit il ? Si vous ne savez pas, via SSH, tapez : lsb_release -a Est ce que vous utilisez un "panel de configuration", de type Plesk, CPanel, ou autre ? Savez vous si la machine manque d'une ressource particulière ? les premières lignes de résultat d'un top pourrait aider à se faire une idée. En cas de manque de mémoire (ce qui est fort probable à mon avis avec une configuration classique), il y a souvent un minimum de traces dans les logs. Entre autre l'intervention de "oom-killer". Changer de machine peut également être une solution, mais s'il y a vraiment un problème de configuration ou dans les sites, il y a des chances pour que cela ne fasse que repousser le problème.

Je t'ai indiqué où est le problème à mon avis. La solution est simplement de corriger cela. :S

if ($aff_news != "1") { include ("config.php"); include ("functions.inc.php"); include ("options.inc.php"); } $aff_news = 1; La configuration de la connexion à MySQL n'est chargée qu'une seule fois, donc les deux includes c'est la même base de données qui est utilisée.

Bonjour, il y a des chances également pour que le script ne conserve pas le "mysql handle" pour l'appel aux fonctions mysql_xxx() ; donc PHP mélange tout oui. A moins que ce soit un pseudo cache du script mal fichu. M'enfin, comme le dit Prélude sans connaitre le contenu du script on ira pas bien loin.

Bah dès lors qu'il s'agit d'une configuration en VirtualDocumentRoot (avec sous domaines "automatiques" typiquement), ça ne fonctionnera pas non : dans ce type de config le Document_Root est le même pour tous les sous domaines. Et cela concerne quand même beaucoup d'hébergements mutualisés je pense ; ainsi que pas mal d'hébergements dédiés je suppose.

Hello, ça ne répond pas vraiment à ton problème mais pour ma part je ne me base que rarement sur le document_root, celui ci étant toujours faux quand on utilise une configuration basée sur le "VirtualDocumentRoot" d'Apache. J'ai donc généralement un script faisant office de fichier de configuration qui génère le bon dossier à partir d'un dirname(__FILE__) ; et les autres scripts se basent ensuite uniquement sur ce chemin "généré".

Tu prends un petit serveur VDS et ainsi tu seras responsable de ton IP... et en fera ce que tu voudras oui. Maintenant entre un VDS à 10 par mois qu'il faudra configurer et gérer, ou une offre "pro" qui fera tout et dont la quasi totalité des mails arriveront à destination, à toi de voir.