Kioob

Bonjour, es tu certain que l'user unix sous lequel tourne MySQL a accès à ton fichier "/var/script/backup/data/sql/load/90_17-07-2008_03-57-55.txt" ?

Je n'avais pas regardé en détail, mais pour moi les DNS de ton hébergeur (frihost.net) déconnent sérieusement. Le zonecheck de l'afnic n'arrive même pas à trouver les adresses IP correspondant à ces serveurs DNS... (pas de soucis avec les .com étant donné que ces IP sont très certainement fournies en "glue records") Et même lorsque la résolution DNS se fait bien la page met des plombes à s'afficher... à mon avis tu devrais migrer ton site chez un autre hébergeur, de préférence en Europe, non ?

Sur Wikipedia il y a une petite liste d'outils de ce genre, as tu regardé ? http://en.wikipedia.org/wiki/Comparison_of...encing_software

Hello, "GROUP BY" correspond justement à ça : un group by sur l'idcontact, et un max(commande.date) et c'est réglé.

Hello, d'après DNS stuff il y a au moins cette erreur qui pourrait être génante : Ce sont tes propres serveurs DNS ?

Hello Blop. ça c'est très relatif... pour les sites sur lesquels j'interviens je vise en dessous 500ms pour la page d'accueil, cache vide. Mais avec tout ce qui est élément externe (régies pubs, tags de stats type xiti, etc) c'est parfois très difficile. Si j'ai bonne mémoire dans la video de Bigb06 il explique que Google a gagné 20% de trafic en diminuant le temps de chargement de 500ms... ou inversement peut être. Après en tant que simple "internaute", j'ai tendance à sentir la lourdeur d'une page à partir d'une seconde.

Hello, je n'ai pas vérifié, mais ce ne serait pas plutôt du coté de la configuration MySQL ? Sous Debian je crée un fichier /etc/mysql/conf.d/language_xxxxx.cnf contenant uniquement : [mysqld] language = /usr/share/mysql/french/

A l'époque où j'en gérais un (ça date un poil), il y avait un compte UNIX par serveur CS tournant sur la machine. Il n'y avait donc qu'un seul script à lancer qui se chargeait de tuer l'instance actuelle si besoin, et de lancer la nouvelle avec les paramètres adéquat. De plus le script bouclait sur lui même, si bien qu'en cas de fermeture "normale" du soft (via rcon par exemple), le serveur était relancé automatiquement. Dans ce type de config, il y a deux solutions pour le reboot distant : 1) via RCON comme on t'a indiqué si dessus. Ce n'est pas parce que tu utilises un port différent que ça n'est pas possible, ce n'est qu'un paramètre. 2) via un exec( 'ssh CompteDuServeurCS_AT_IP /chemin/du/script/de/reboot' ); Par contre tu devras probablement prévoir une identification via clé SSH pour éviter la demande de mot de passe.

Hello, Je vois trois cas : 1) ta méthode est statique, dans ce cas tu passes : array( 'NomClasse', 'NomMethode' ) 2) ta méthode n'est pas statique, et tu fais l'appel depuis l'instance de l'objet : array( $this, 'NomMethode' ) 3) ta méthode n'est pas statique, et tu fais l'appel depuis l'extérieur : array( $objectInstance, 'NomMethode' ); Or de ce que je vois dans ton exemple, tu utilises ta classe A de manière statique uniquement. C'est à dire le premier cas. Pour faire du multiple en PHP5, dans le constructeur de ma classe C j'instancierais A et stockerais l'instance dans une propriété interne... la méthode __call utiliserait donc call_user_func_array() via un array( $this->instanceA, 'nomMethode' ); Si ça coince vraiment, donne un exemple de ton vrai code, et indique à quelle ligne correspond ton erreur sur le $this (je peux me tromper, mais j'ai l'impression que l'erreur est relative à une utilisation dans la méthode de A ; ce qui n'est pas forcément choquant dans ce contexte).

Hello, regarde du coté de la fonction call_user_func_array().

Hello, 1 million d'enregistrements pour une base de données ça n'a rien de "gros". Un simple indexe (à priori un index multi column sur l'idutilisateur + la date) devrait effectivement suffir. Pour ce qui est de séparer en plusieurs tables, les seules fois où j'ai vu ça c'était pour un forum qui utilisait des tables myisam (et qui aurait donc rencontré des problèmes de verrous sans ce "bricolage").

Hello, le plus simple pour être certain que les fichiers soient presque toujours dans le cache en question est de régulièrement les lire, depuis un cron par exemple. Mais s'il s'agit de script PHP chargés à coup d'include/require le mieux est probablement de mettre en place un cache d'opcode (APC ou eAccelerator par exemple), qui conservera en mémoire une version "compilée" de ces scripts. Après tu peux effectivement les stocker directement en mémoire (en faisant un lien symbolique vers /dev/shm par exemple) mais à moins que le volume soit relativement faible l'impact peut être assez négatif si ta machine vient à manquer de mémoire.

La dernière fois que Sivit a voulu faire un truc du genre (à base d'rsync) pour une de mes machines ça s'est soldé par un échec à cause de udev. Je n'ai pas cherché plus loin, mais pour le coup ce n'est pas forcément aussi simple. Si la machine de destination n'est pas strictement identique, ce n'est pas toujours facile. Par contre si vous connaissez une solution vraiment "portable", ça pourrait m'intéresser.

Une autre alternative est FastCGI (couplé à suexec de préférence). Via FastCGI l'interpréteur n'est relancé que toutes les 500 exécutions, les performances sont donc très proche de celle de la version module.

Question de point de vue alors. Pour ma part une table corrompue ce n'est absolument pas normal, et je préfère chercher à corriger l'origine du problème que de faire des "repair" automatiquement. Pour ce qui est de s'en rendre compte, Logcheck ou tout autre système du genre ne manque pas d'en informer l'admin "d'astreinte". Je comprends ton point de vue mais perso ce genre de correction automatiques, je ne suis vraiment pas fan.

Hello, perso j'ai un "OPTIMIZE TABLE" qui passe toutes les nuits (ou presque) sur toutes les tables de toutes les bases de mes clients. Mais il n'y a aucune base "très grosse", pas plus de quelques Go. Le "OPTIMIZE TABLE" en lui même n'est pas si important je trouve mais c'est surtout le "ANALYZE TABLE" (inclus dans l'optimize) qui m'intéresse. Par contre je ne fais pas de REPAIR non. Pourquoi les tables seraient elles corrompues ? Ca n'arrive qu'en cas d'incident rare (partition saturée, coupure électrique, plantage complet de l'OS), et dans ce cas la correction est faite ponctuellement.

Hello, il y a plusieurs façons de faire ça, via un cron par exemple... Ou bien tu peux directement faire un lien symbolique, voir un "mount --bind". Tout dépend de ce que tu cherches à faire en fait... Pourquoi places tu "par erreur" des fichiers dans ce dossier ?

Sinon il y a Sivit qui a une option "d'infogérance complète" ; mais ce n'est plus vraiment le même budget.

La taille idéale c'est assez difficile à dire.... généralement j'essaye de ne pas dépasser 10'000 entrées par dossier. Mais pour un accès FTP la limite est souvent bien inférieure ; par exemple PureFTPd par défaut limite à 2'000 entrées par dossier dans ses listings.

Hello, une solution fréquente est de diviser en plusieurs niveaux d'arborescence en fonction des premières (ou dernières) lettres du nom de fichier. Prenons par exemple les fichier "toto.jpg" et "bidule.png", tous deux actuellement dans le dossier "/home/ton/dossier/images/". Le nouveau chemin de stockage serait /home/ton/dossier/images/t/o/toto.jpg et /home/ton/dossier/images/b/i/bidule.png ; ou selon les préférences : /home/ton/dossier/images/t/o/to.jpg et /home/ton/dossier/images/b/i/dule.png. Cela évite de se retrouver avec 100'000 fichiers dans le même dossier.

Hello, ce n'est pas du tout la même chose non. MySQL va généralement utiliser un seul index par clause/jointure. Si tu fais une requete avec deux clauses de ce genre : where page_id = 18 and zone_id = 20 Si tu as l'index groupé, MySQL pourra s'en servir pour rechercher directement page_id + zone_id. Sinon, il utilisera au choix l'index sur page_id ou zone_id, mais pas les deux en même temps. Par contre si tu as une requete avec uniquement cette clause : where module = 'toto' MySQL sera incapable d'utiliser l'index groupé, car l'ordre de l'index groupé est important : il aurait fallu que la clause ait des critères sur page_id et zone_id également. Pour savoir quand utiliser quoi, cela dépend essentiellement de tes requêtes.

Pour ne prendre que les balises "link", il faut le préciser.... y a aucun flag qui va le dire à ta place. Après faut voir si tu veux qu'on te donne une solution directement ou bien si tu veux te faire la main sur les regex par toi même

Hello, ta REGEX commence par "^" indiquant que tu ne cherches qu'au tout début de la chaine ; ce qui n'est évidement pas ton cas.

dans la boucle il faut utiliser strpos, comme conseillé par KnockedMaster

Ou bien utiliser une simple boucle sur le tableau.