jcaron

Ce ne serait pas ton FAI qui empêche d'utiliser un serveur smtp autre que le leur (pour lutter contre le spam)? Wanadoo s'est mis à faire ça il y a quelques mois, Free aussi il me semble (mais chez eux tu me le désactiver), il y a en peut-être d'autres qui suivent le mouvement... Essaie en local sur ton serveur pour voir (telnet adresseip 25)... Jacques.

Quoi qu'il arrive, si tu veux que ça marche aussi avec IE6, n'oublie pas que celui-ci ne supporte :hover que sur les <A>... Jacques.

Effectivement elle swappe un peu (mais 17 Mo vs 1 Go de RAM c'est pas beaucoup, il faudrait voir la quantité de swap in/out), mais clairement le plus gros problème c'est qu'elle sature le CPU, nettement plus que le fait qu'elle swappe. Et ce qui bouffe c'est essentiellement apache (et un peu mysql quand même), donc ça veut dire qu'il y a des scripts qui sont un peu trop gourmands. Il y a de l'optimisation à faire, et réduire le nombre de serveurs apache ne va pas changer grand chose (à part réduire un chouïa les context-switches et augmenter beaucoup la latence avant qu'apache ne commence à traiter la requête). Il faudrait savoir ce qui tourne comme appli (un truc standard genre CMS ou forum, ou des applis maison), avoir une idée des pages/scripts les plus souvent invoqués, avoir quelques sorties de server-status. Après si c'est du php comme c'est certainement le cas je donne ma langue au chat, je ne sais même pas s'il y a des outils de profiling qui vont avec cette chose :-( Jacques.

Les projets ou les existants? Pour les existants, tu peux chercher du côté de: - Redbus Interhouse - Telecity - Telehouse - Global switch - Interxion - Ldcom - Interoute - Verizon - Level3 - Telstra Et il doit y en avoir des dizaines d'autres... Jacques.

Ben si ça prend tu temps, c'est que ça sature quelque chose quelque part: soit le CPU, soit la RAM, soit les accès disque. La première chose à faire c'est de mesurer tout ça: de façon instantanée avec top par exemple, et sur la durée avec des graphes à la mrtg (il me semble que c'est fourni en standard par ovh, même si leurs graphes ne sont pas forcément tous exacts ou utiles). Si c'est le CPU, il faut déterminer quel processus en consomme le plus (a priori ça ne peut être que ton serveur http ou ton serveur mysql, mais tu pourrais découvrir d'autres trucs dans les parages). Si c'est la RAM, ça swappe (donc accès disque) ou ça augmente les accès disque (parce qu'il n'y a pas assez de RAM pour garder ce qu'il faut en cache). Pour le premier il faut réduire le nombre de processus ou ajouter de la RAM. Pour le deuxième, voir ci-dessous. Si c'est les accès disque (le plus vraisemblable à mon avis), probablement du fait de mysql, plusieurs options: - s'assurer que toutes tes requêtes sont correctement optimisées et en particulier qu'elles utilisent bien des index - dans certains cas une restructuration de la base et/ou des index peut aider - si la "partie utile" de la base (celle qui est régulièrement accédée, on se moque un peu du post d'il y a 6 mois que personne ne va jamais lire) est trop grosse pour tenir en RAM, il va soit falloir réduire cette partie utile (cf plus haut), soit dégager de la mémoire pour faire du cache (éventuellement en réduisant le nombre de processus apache, par exemple), soit modifier la config de mysql pour adapter la taille de ses buffers à la taille de ta base, soit ajouter de la RAM (pour qu'il y ait plus de choses en cache, donc moins d'accès disque) - tu peux aussi faire du caching au niveau de ton appli - et à la fin, la seule option c'est d'augmenter le nombre de disques pour avoir plus de bande passante d'I/O. Voilà déjà quelques pistes à explorer... Jacques. (edit: cas de la saturation de la RAM)

Déjà, le titre de ton message n'est pas forcément en adéquation avec ta question, comme on te l'a déjà fait remarquer. Même si ce n'est pas forcément très bien défini, un data center (ou hosting center) c'est un lieu, et dans les plus gros il y a souvent beaucoup de prestataires différents. En général on distingue d'un côté le fournisseur de l'infrastructure physique (le hosting center lui-même) qui fournit l'espace, le courant (avec onduleurs, générateurs, etc.), la clim, la sécurité, éventuellement les baies, le câblage, etc, parfois la connectivité, et d'un autre côté les hébergeurs, qui fournissent des serveurs dédiés ou mutualisés ou des systèmes plus complexes, la connectivité, du management et du support. Dans certains cas c'est la même société, dans d'autres le premier "héberge" le deuxième. Et dans certains cas il y a même encore plus de niveaux d'imbrication, et évidemment il y en a qui ont des offres un peu à cheval, et j'en passe... Tu as du mal chercher... Comme indiqué plus haut, tu risques d'en éliminer tout plein comme ça. Et au vu de ta liste, tu as oublié tout un tas de critères, il y a tout plein d'hébergeurs au delà du marché du "serveur dédié commandable en ligne" (qui est en fait quelque chose de relativement récent). Au moins deux d'entre eux ne respectent pas ton premier critère. OVH est sur Telehouse et Global Switch, de mémoire, CTN1 doit être chez Redbus je crois, amen je ne me souviens plus. Commence par mieux définir ce que tu cherches exactement. Si tu veux une liste exhaustive de tous les hébergeurs, elle va être (très) longue. Si tu cherches juste les gars qui fournissent des dédiés commandables en ligne, la liste sera plus courte, mais il y en a quand même pas mal. Si tu cherches la liste des data centers physiques, la liste sera encore très différente... Jacques.

La grosse différence c'est surtout qu'il y en a qui qui est dispo pour la France et pas l'autre (à moins que ça ait changé récemment). Depuis qu'ils ont refait leur page d'accueil, paypal.com, même en français, te donne des infos sur les produits US, pas les produits français. Il faut regarder sur paypal.fr pour avoir les produits pour la France. Sinon sur le principe Payflow requiert que tu aies déjà un compte commerçant CB, de mémoire... Jacques.

Absolument pas, non, c'est une légende urbaine que tout ça. Je vous propose un petit extrait du code monétaire et financier, qui nous dit dans son article L.132-2: L'ordre ou l'engagement de payer donné au moyen d'une carte de paiement est irrévocable. Il ne peut être fait opposition au paiement qu'en cas de perte, de vol ou d'utilisation frauduleuse de la carte ou des données liées à son utilisation, de redressement ou de liquidation judiciaires du bénéficiaire. Il ne dit pas "le fait de signer" ou "le fait de taper son code". Il indique qu'un ordre ou un engagement de payer a été donné. Par écrit, par téléphone, par fax, par Internet, peu importe. Il est absolument et totalement interdit de dire "ah non je ne veux pas finalement" ni même "je n'ai pas eu le produit demandé" ou quoi que ce soit du genre (ce sont des litiges commerciaux à régler avec le commerçant, la banque n'a aucune raison d'être impliquée là-dedans). Le seul cas où c'est autorisé, c'est donc en cas de perte, de vol, de fraude (et éventuellement le redressement ou la liquidation judiciaire, mais ce cas est assez spécifique pour qu'on le mette de côté). Et dans ce cas, il est assez légitime qu'un dépôt de plainte soit demandé, non? Sinon ça ouvre la porte aux gens qui disent "ah non ce n'est pas moi, je n'ai pas passé cette commande" (fausse déclaration), mais les gens se risquent moins à ça quand il faut aller le dire aux braves gens en bleu qu'à leur banque... Ceci dit, ça ne protège pas contre les vrais cas de fraude, et il faut toujours avoir le maximum d'éléments permettant de tracer qui a effectivement passé la commande (adresse IP + heure, e-mail, adresse de livraison, vérification téléphonique...) pour soit prouver que la contestation est de mauvaise foi, soit pouvoir se retourner contre le fraudeur. Jacques.

C'est beaucoup plus compliqué que ça. Le fait de mettre un doctype ne suffit, pas, ça dépend de quel doctype (version, strict ou pas, URL ou pas...) Quelques références: - La doc MS (c'est quand même eux qui ont inventé cette horreur) http://msdn2.microsoft.com/en-us/library/b...ncements_topic2 - La doc Firefox: http://developer.mozilla.org/en/docs/Mozil...OCTYPE_sniffing - La doc Opera: http://www.opera.com/docs/specs/doctype/ - Un petit récapitulatif: http://hsivonen.iki.fi/doctype/ Bon courage! Jacques.

Plutôt dans le log d'accès. Si tu vois que pour une IP donnée tu as une série plutôt longue d'accès à différentes pages (probablement en boucle, ou avec genre un paramètre qui se rajoute à chaque appel, ou un truc du genre), c'est que tu as un problème. C'est en général assez évident à voir... Jacques.

Si le problème vient de références circulaires, ça devrait se voir assez rapidement dans tes logs, regarde-les, ils sont là pour ça! Jacques.

Comme tout le monde, si tu t'enregistres pour la TVA (obligatoire au dessus d'un certain montant de CA annuel). C'est un numéro de TVA intracommunautaire... Pas vraiment, non. Au choix: - tu n'as pas de numéro de TVA: tu achètes TTC (tu paies la TVA et tu ne te la fais pas rembourser), tu revends sans TVA (donc tu ne la collectes pas et ne la reverses pas). - tu as un numéro de TVA: tu achètes HT (tu paies la TVA et tu te la fais rembourser pour les achats en France, tu ne paies pas le TVA pour les achats UE), tu vends TTC (tu factures, collectes et reverses la TVA). Jacques.

Une erreur 500 c'est (en général, probablement tout le temps d'ailleurs) un script qui ne se comporte pas comme il devrait, et qui se termine avant d'avoir fourni une page. Il peut y avoir tout un tas de raison à ça (bug, problème d'accès à une base de données, à un fichier...), mais la seule solution pour savoir, c'est de regarder les logs d'erreur, ils sont là pour ça! Jacques.