Kioob

Hello, première remarque : là ton formulaire est soumis aux injections, ton formulaire va (oui c'est une quasi certitude tellement c'est répandu) être utilisé pour spammer. Il faut empêcher la saisie de retours chariots dans le champ $sujet. Et pour ton problème, il faut ajouter un "From" dans les entêtes supplémentaires (quatrième paramètre de la fonction mail()). Par exemple : mail("mon_email","$sujet","$email \n\n $message", "From: $from\r\n"); Attention, il est lui aussi sensible aux injections, donc s'assurer qu'aucun caractère en trop ne s'y est glissé.

Un load à 6 sur un core2quad, y a encore du boulot pour réduire tout ça

Si ce n'est pas du fastCGI c'est clair que ça doit mouliner sévère... sans oublier qu'aucun cache d'opcode n'est utilisable dans ces conditions.

Bonsoir, en tous cas pour moi ce n'est pas l'option 2, ce type de serveur est capable d'encaisser un trafic bien supérieur à cela... à condition d'adapter la configuration d'Apache, PHP et MySQL. As tu regardé avec un "mytop" pour voir ce qui se passe coté MySQL ? Et pour y voir un peu plus clair sur les graphs, essayes "renice 1 -u nobody", sur le graph CPU la consommation liée à Apache/PHP devrait passer en vert. Dans un premier temps tu peux aussi désactiver le KeepAlive d'Apache. Mais bon, trifouiller "au pif" des paramètres n'est pas forcément la bonne approche. L'idéal est d'identifier la cause des problèmes.

Je ne connais pas l'hébergement de GoDaddy, mais à moins que ce soit un serveur virtuel ou un serveur dédié tu ne peux pas.

djp1988 : il y a plusieurs extension de Firefox qui permettent de voir ça, par exemple avec "Web Developer" tu fais "Informations" / "View Response Headers". Ou tout simplement avec Live HTTP Headers qui t'indiquera tous les entêtes. Mais à priori oui, le module Expires ne semble pas disponible sur ton Apache. Si c'est ton serveur, et que tu es en Debian ou Ubuntu : a2enmod expires; /etc/init.d/apache2 reload

Je n'ai testé que 4 fournisseurs de serveurs, mais parmis ceux ci seul OVH n'utilise pas Grub. Et c'est un des premiers trucs que je change. D'ailleurs, est ce que le paquet Grub est toujours absent de leur miroir Debian ?

Hello, pour ce genre de liste j'ai tendance à passer par Wikipédia, as tu regardé ?

Configurer MySQL est quelque chose d'obligatoire à mon sens, et c'est ce que vient de faire votre hébergeur à priori. Mais c'est déjà un gros morceau. Si ca n'avait jamais été fait jusqu'à maintenant, cela peut complètement expliquer les précédents problèmes. Y compris coté Apache, avec un "keepalive" réglé par défaut à 15 secondes et un PHP installé en tant que module Apache, la mémoire peut vite exploser... à cause d'un seul malheureux paramètre dans ce cas. Bref, en partant d'un serveur non configuré il y a effectivement de nombreuses pistes. Mais il faut déjà savoir identifier ce qui coince, et connaître les éventuelles solutions. Je vois que Nuxit propose une offre d'infogérance à 20€ HT par mois, je ne sais pas ce qu'elle englobe mais c'est à mon avis un bon point de départ : ainsi ils se chargeront d'ajuster la configuration au fil du temps. Maintenant si vous y tenez vraiment, un des points les plus importants est d'avoir un monitoring : comment "optimiser" quoi que ce soit si on ne connaît pas les ressources consommées et/ou les goulots d'étranglement ? Là aussi il y a du choix : cacti, munin ou zabbix par exemple correspondent en partie à cela. Et dans un deuxième temps vous pourrez peut-être vous pencher sur l'optimisation de "l'expérience utilisateur", via les liens indiqués par Bigb06. Ce point est déjà beaucoup plus de votre ressort je pense.

Aucune des deux n'est à jour. La dernière version officielle de la branche 5.0 est la 5.0.77... et la dernière version officielle de production est la 5.1.31. A coté de ça la distribution Debian stable (sortie vendredi dernier) ne propose qu'une version 5.0.51a...

Bonsoir, il faudrait déjà préciser de quoi il s'agit. Le serveur est surchargé, ou bien le site est lourd coté client ? Car bien que certains problèmes soient répercutés d'un coté et de l'autre, ça n'est pas toujours le cas. Si le serveur MySQL est au bord du crash, ce n'est pas en réduisant les hits du front que ça se réglera... et inversement, si le site est mal construit et génère une centaine de hits, c'est pas en trifouillant PHP que ça se corrigera.

Bonjour, pour moi si on opte pour la distribution "clés en main" d'OVH, c'est justement parce qu'on ne veut rien y modifier non ? En tous cas ce n'est clairement pas la plus pratique pour faire ce genre de choses. Maintenant pour ce qui est d'un upgrade MySQL depuis une Gentoo (en supposant qu'OVH ait suivi la "procédure" Gentoo...), Google semble déborder d'infos.

Hello, sans plus d'info, j'aurais tendance à miser sur un problème DNS, même si tu penses que ce n'est pas le cas. As tu testé des outils de diagnostique DNS tels que DNS report sur certains des domaines impactés ? Tes refresh jusqu'à obtenir la bonne page, c'est avec Firefox que tu fais cela ? Car Firefox a justement un cache DNS assez faible (1 minute)... Une fois la piste DNS éventuellement écartée, faudra voir coté hébergement, mais chaque chose en son temps. Non ?

A l'époque j'avais cru lire au contraire qu'OVH faisaient pointer les bots sur des "nodes" spécifiques de leurs clusters : en gros des nodes dédiés aux robots, où ce n'est pas bien "grave" que les pages soient un poil longues à s'afficher. <pure speculation>Si je prends ma boule de cristal, OVH utilisant fastcgi le fait d'avoir des robots qui scannent en permanence tous les sites force les clusters à avoir quasiment en permanence une copie du PHP correspondant au site en question, et pose donc de gros soucis de perfs. Ainsi un node dédié aux crawlers avec du CGI normal (et non du fastcgi) aurait peut-être pu être la solution.</speculation> Tout du moins c'est ce que j'avais cru comprendre à l'époque. Maintenant comme seuls les robots utilisent le(s) node(s) en question, s'ils sont surchargés le site est inaccessible pour eux, et personne ne s'en rend compte.

Il n'utiliserait pas plutôt tes images / photos ou autres fichiers du genre ?

Je peux aussi me tromper, mais sans plus d'info c'est ce que je comprends d'un "(proxy|passerelle).(ministere|societe|organisation).tld".

Hello, pour moi il s'agit simplement d'employés du ministère de la culture qui consultent ton site.

Dans les exemples ci dessus je ne vois aucune variable à échapper.

dans le cadre du débugage, il y a aussi : var_dump( $_GET, $_POST );

Histoire de chipoter : sous Oracle ça n'est pas obligatoire (cf les + au milieu du WHERE) ; la syntaxe n'a pas été reprise ailleurs ?

A priori on est d'accord, c'est surtout ce bout de phrase qui me faisait un peu peur : (oui c'est sorti du contexte, mais je pense que ça peut vraiment être mal interprété, c'est tout )

Je suppose qu'en utilisant explicitement des "JOIN" le travail de l'optimiseur est simplifié, mais qu'il y a de grandes chances pour que le "query plan" soit identique. D'un point de vue pratique je préconise l'utilisation du JOIN uniquement parce que j'ai remarqué que les développeurs oublient moins souvent les clauses de jointure avec cette syntaxe (oui j'en avais marre des produits cartésiens corrigés à coup de distinct...).

Pour mysql_query ce n'est pas un script mais un patch, à appliquer à l'extension mysql de PHP avant compilation donc. A l'époque c'était pour la version 5.2.0 de PHP fournie en etch : http://daevel.fr/200-mysql.min_stored_data.patch Pour limits, je ne suis pas certain que ça fonctionne en module Apache... la limite serait alors probablement globale et non par script.

Je me suis peut être mal exprimé... Je disais que si le DISTINCT était si lourd c'était justement parce qu'il utilisait des mécanismes similaires au GROUP BY, qui est lui aussi très lourd. Les deux sont simplement à utiliser à bon escient.

Un distinct est considéré comme très lourd justement parce que ça revient "quasiment" à faire un group by.