Kioob

Bonjour, diverses solutions : - installer "ntpd", qui va synchroniser l'heure en permanence - installer "openntpd", même chose mais plus léger il parait - installer ntpdate, et mettre en place un cron pour régler à nouveau l'heure de temps en temps J'ai une préférence pour les 2 premières solutions. Si tu es sous Debian (voir Ubuntu) : aptitude install openntpd

Bonjour. Ne pas passer par wget, et encore moins par Apache pour exécuter un cron. Un "vrai" script, lancé en ligne de commande, sans timeout, ça évite beaucoup de problèmes de ce genre. Mais... encore faut il que l'hébergement le permette...

Sauf que le script PHP ne débute qu'une fois que le fichier est entièrement uploadé... Ce qui est indiqué dans les commentaires, c'est uniquement dans le cas du test d'une image distante, via HTTP par exemple.

Hello, en fait ce que tu veux c'est connaître le format du contenu, pas l'extension du fichier, non ? Normalement getimagesize() se base uniquement sur le contenu du fichier, pas du tout sur l'extension. Tu peux appeler ton fichier toto.png, toto.php ou toto.jpeg, s'il s'agit d'une image JPG getimagesize te retournera le même résultat.

J'ai juste indiqué "par où et comment"

Et bien là on voit qu'on il n'utilise qu'une seule table (forum), l'index "type", et qu'il parcourt 39'866 lignes pour répondre à ta requête.

Pour savoir pourquoi une requête est lente, la meilleure solution est bien souvent de faire un EXPLAIN de la requête. Ainsi tu sauras "par où et comment" MySQL passe pour répondre à la requête. Pour ce qui est de la réponse immédiate, oui c'est seulement s'il n'y a aucune clause et que la table est stockée au format MYISAM.

Si la table ou la base est verrouillée (à cause d'une modification en cours dans la table ou d'un LOCK), la requête devra attendre : normalement dans le log "slow query", le "locked time" est indiqué. Il est à 0 ici ? Après ça dépend de plusieurs facteurs... un count(*) sans clause where sur une table MyISAM est effectivement immédiat. Mais s'il y a des clauses WHERE ou s'il s'agit d'INNODB, MySQL sera bien obligé de vraiment compter les lignes en question. Pour ce qui est de la meilleure manière de faire, oui c'est bien souvent le cas. Mais ça ne veut pas dire que c'est forcément "hyper rapide".

Si ton script PHP lance cette requête, il ne pourra rien faire d'autre tant qu'elle n'est pas terminée... Donc s'il le fait avant d'afficher la page, celle ci mettra 56 secondes à s'afficher oui... bien que l'internaute sera probablement parti ailleurs depuis longtemps. Pour ce qui est du fait qu'aucune page ne mette autant de temps d'après toi, justement tes logs disent le contraire... et comme l'a expliqué Mr Nounours le résultat est probablement en cache, donc tu ne t'en aperçois pas. Il se peut aussi que ce soit un ralentissement ponctuel à cause de la procédure de sauvegarde, d'une autre requête qui verrouille la table, voir même un ralentissement global du serveur.

Note que je n'ai pas dit qu'il s'agissait d'un site Internet... Quand il y a énormément de données (des dizaines, voir des centaines de Go), et que la requête est complexe (beaucoup de jointures, des group by, etc) ça peut vite monter. Encore plus si la requête est "mal faite" et/ou que les indexes nécessaires ne sont pas présents. Pour ce qui est du "comment ça se passe sur le site web", bah c'est simple : l'utilisateur va voir ailleurs avant que la page ne s'affiche... ou encore Apache abandonne et affiche une erreur. Il n'empêche que coté MySQL la requête continue de tourner, et apparaîtra probablement dans le log "slow query" à la fin.

Oui, depuis MySQL 4.0 il y a un cache de requête "automatique". Pour ce qui est du temps d'exécution, 56 secondes c'est très court dans le monde des bases de données. Certaines requêtes peuvent durer plusieurs heures.

Hello, déjà, qu'est ce qui t'oblige à passer par une "boucle PHP" ? Ne peux tu pas faire directement ces X requêtes en indiquant tes tables "articles" en sous requête ?

C'est déjà largement suffisant pour commencer je pense. Reste à détecter les éventuels problèmes... Un truc qui mouline pendant des plombes, et qui fonctionne juste après, je verrais bien un soucis coté MySQL qui est "masqué" grâce au cache de requête. Mais ce n'est qu'une supposition... Voir ce qu'il en est dans le log "slow queries".

Bah à toi de nous le dire... as tu essayé le code que tu indiquais dans ton post ?

Bonsoir, si c'est bien ça le problème, je t'invite à activer la compression des pages de PHP : soit modifier directement zlib.output_compression dans le php.ini ou bien ajoutant ini_set('zlib.output_compression', true); en début de script.

Par exemple si il met "From: toto_AT_daevel.fr" dans son email, l'email passera forcément en spam partout (ou presque) parce que son serveur n'a pas le droit d'envoyer d'email en les "signant" avec une adresse daevel.fr.

Faire passer l'email comme venant de ce qui est dans le champ $_POST, ça pose divers problèmes (SPF, DomainKey, etc) ; pour de nombreux serveurs c'est considéré comme un vol d'identité.

En même temps je t'ai indiqué deux solutions : les calculs directs à coup de divisions par 86400, et la conversion à la volée au format date MySQL via la fonction from_unixtime(). Aucune des deux ne te convenant, je ne vois pas quel type de solution tu espérais, surtout en partant d'un format pas vraiment adapté.

Bah je pensais remplacer le champ actuel en fait, qui est rarement utile au format timestamp

Et bien je te laisserai simplement réfléchir 30 secondes

Oh bah c'est sûr que si le domaine pointe sur l'IP d'un autre serveur, y a peu de chance d'avoir une erreur 404...

Perso je pensais que ce module était utilisé en standard chez la plupart des hébergeurs, étant donné que cela réduit la consommation, mais visiblement non... Jusqu'à maintenant les seuls chez qui j'avais vu que c'était désactivé sont ceux qui facturent au "hit", ce qui leur permet de gonfler un poil la facture... Au final c'est comme la compression des pages, c'est à l'hébergeur de décider.

MySQL peut faire certains calculs, mais avec du group by derrière ça risque d'être terriblement lent. Si tu fais un "from_unixtime()" tu as ensuite accès à toutes les fonctions de date de MySQL (je te laisse consulter la Doc MySQL pour avoir la liste)... mais autant stocker directement au format date/datetime tu ne crois pas ?

Tu utilisais quoi comme valeur de $from avec "mon" code ? Il faut mettre une adresse email...

Hello, de manière générale quand on veut faire du "requetage" sur les dates, il faut utiliser un champ DATE/DATETIME, sinon forcément ça complique les choses... Après si tu veux utiliser ton champ "timestamp", tu peux tenter un truc du genre floor( DateJour / 7*86400 ) as semaine... en espérant que le 01 janvier 1970 était un lundi (ou dimanche selon ta façon de compter les semaines).