Kioob

A mon avis tu ne voudras pas débourser pour cela, mais il y a éventuellement les solutions de type Amazon S3 ; on paye à la consommation pour un service d'une très bonne qualité. Dans tous les cas je rejoins Dan : la plupart des hébergeurs gratuits cloturent ou suppriment les comptes dès qu'ils trouvent qu'il y a trop de consommation... et souvent sans le moindre pré-avis. D'autres ont tout simplement une "protection" anti hot link, si bien que tu ne peux même pas utiliser leur service pour ça.

Une IP blacklistée ne l'est jamais définitivement, donc dans ce cas généralement j'utilise une IP failover pendant quelques semaines/mois puis bascule sur la "vraie" plus tard.

Hello, à partir du moment où tu passes par un vrai hébergeur, tu n'as normalement plus besoin de "redirection transparente". Pour ce qui est du transfert du domaine, je ne connais pas "rapidomaine" mais généralement on a pas besoin de changer de registrar quand on change d'hébergeur.

Hello, pour moi la seule façon de tester un code est de l'exécuter... d'où les tests unitaires.

Hello, et en utilisant PDO, ça ne fonctionne pas non plus ?

Ce qui bouffe de la mémoire, c'est très certainement PHP (et donc Apache) ; mais comme dit plusieurs fois l'essentiel est de savoir pourquoi il y a cette consommation.

Bah tu voulais pas changer ? L'économie faite sur le serveur en passant par OVH paye généralement le coût d'un service d'infogérance externe.

Le soucis c'est que là le "free" tu ne l'as pas lancé durant une période de problème. Et un serveur qui manque de mémoire juste après avoir rebooté, ce n'est heureusement pas trop répandu. Enfin bref, je vais laisser ton infogérant faire puisque lui a accès aux infos en temps réel, et peut beaucoup mieux analyser le problème. A moins que tu n'optes pour les services de Dan directement, au moins il saura où regarder.

Hello, un SSH qui met des plombes à se connecter, c'est souvent par manque de mémoire. Un free -m une fois la connexion établie devrait fonctionner. Tuer les processus Apache peut effectivement fonctionner : cela tue également les processus PHP ainsi que la plupart des requêtes SQL, donc même si Apache n'est certainement pas le fautif, le problème semble au moins temporairement résolu. La machine me semble toujours assez puissante pour ma part pour un "si petit trafic", 5'000 visiteurs uniques par jour, y a vraiment pas de quoi fouetter un chat. Mais je peux me tromper, Wordpress est peut être encore plus gourmand que ce je pensais. Il faudrait déjà voir dans les logs à quoi correspond cette erreur.... et ton "infogérant freelance", il en dit quoi ? Après tout, il a hérité du bébé désormais Pour ce qui est du changement d'hébergeur bien que de prendre une machine plus puissante est rarement une solution pérenne, repartir sur une configuration saine ne serait sûrement pas du luxe. Du coup un petit Kimsufi XXL d'OVH avec une prestation d'infogérance externe pourrait être efficace, tout en laissant beaucoup de marge coté perfs.

Hello, dans ce cas il est peut être plus simple d'utiliser un autre script non ? D'autant plus qu'à priori il n'y rien de bien compliqué à parser un flux RSS.

Hello, pour le .it, Gandi le fait. Pour ce qui est de l'.es, il y a au moins MailClub qui le fait (ainsi qu'un très grand nombre d'autres extensions). Dommage que leur interface de gestion des domaines ne soit pas à la hauteur du reste de leurs services.

de rien

Oui, quand le site est sur plusieurs machines généralement je procède comme cela : deux IP en "round robin", pour cela il te suffit de mettre deux fois la même entrée dans la configuration du domaine, par exemple on a généralement : (pas besoin d'avoir tes propres DNS pour cela) @ A 1.2.3.4 www A 1.2.3.4 A la place tu mets : @ A 1.2.3.4 @ A 1.2.3.5 www A 1.2.3.4 www A 1.2.3.5 Et le trafic sera réparti de manière à peu près égale sur les deux adresses IP. Mais en cas de panne de la machine correspondant à l'IP, tu perds quand même 50% de ton trafic. Pour éviter ça l'idéal est que ces IP soient des IP "flottantes" ou "fail-over" comme dit OVH. Ainsi sauf grosse coupure de l'hébergeur, l'IP est toujours valide. Mais pour éviter ce dernier cas ("grosse coupure de l'hébergeur"), à ma connaissance la seule solution à notre échelle est la modification coté DNS.

La plupart se contentent d'une sauvegarde fréquente et du contrat SLA de l'hébergeur. Après si tu ne peux pas te permettre quelques heures de coupure par mois, il y a des solutions techniques plus élaborées et plus chères, telle que les clusters chez Sivit. Mais ça ne repose pas ou peu sur les DNS. Les DNS pour ma part je m'en sers surtout pour de la répartition de charge (ça c'est toujours pratique), et en dernier recours pour de la tolérance aux pannes, et uniquement sur déclenchement manuel.

Hello, déjà, quel est ton prestataire pour le serveur principal ? Sivit permet l'utilisation d'IP flottantes par exemple, et OVH propose des "IP failover" mais qu'il faut généralement basculer à la main (c'est automatisable via une API maison à priori). La mise à jour des DNS pour moi c'est la solution la moins fiable. Même avec un TTL de 5 minutes, je ne la considère pas effective à 100% avant 24 heures minimum. Mais si tu n'as que cette possibilité... soit. Pour la synchronisation des fichiers (scripts PHP, images, fichiers uploadés par l'utilisateur), si une seule machine est active à la fois (ce qui ne peut pas être assuré en jouant avec les DNS...) un simple rsync régulier suffit. Dans le cas contraire, je suppose qu'il va falloir y aller à coup de rsync avec des critères différents entre chaque dossier peut être. Il y aurait bien des solutions telles que DRBD, mais là encore en jouant sur les DNS ça ne passera pas, et en plus le débit risque de ne pas suivre. Pour ce qui est de MySQL... là aussi très rigolo. Tu peux tenter la réplication, ou une synchronisation régulièrement à base de snapshot LVM + rsync ; mais il faut s'assurer qu'il n'y aura jamais les deux bases de données utilisées en écriture simultanément, ce qui encore une fois est impossible en jouant sur les DNS. Coté bouquin... je ne suis pas certain que ça englobe tout, mais j'ai sur mes étagères "LInux Enterprise Cluster", qui ne répond pas exactement au même problème mais certaines techniques sont les mêmes. Une autre solution c'est de passer directement par un prestataire qui propose ce genre de solutions, comme Sivit par exemple. Enfin bon courage en tous cas...

Bah comme j'ai indiqué plus haut : Parmis les méthodes dispos il y a effectivement la modification des DNS... mais avec tous les caches qui entrent en jeu, même si tu mets un TTL faible le résultat sera peu fiable : une partie des visiteurs n'aura pas accès au site de toutes façons. Et si c'est pour faire une répartition en fonction de la charge, c'est vraiment pas le bon plan : à la limite tu peux faire du "round robin", c'est à dire envoyer à peu près le même trafic sur chaque machine, mais ça s'arrête là. (et non on est pas obligé de préciser une seule IP justement, c'est justement ce qui permet de mettre en place le round robin dns) Pour la redondance des serveurs DNS, c'est surtout pour éviter qu'en cas de panne d'un serveur DNS tous les domaines hébergés sur ce serveur deviennent inaccessibles... C'est pourquoi il est quasiment obligatoire d'avoir au moins 2 serveurs DNS pour héberger un domaine. Après la limitation de 13 est due à la taille des packets UDP utilisés par le protocole DNS vis a vis du "MTU" garanti sur Internet ; un truc technique à la con dont tu n'auras à priori jamais besoin de t'occuper. Sache juste que c'est à cause de cela qu'il n'y a que 13 IP qui gèrent le root, c'est à dire la racine des DNS, ce qui fait tourner Internet en gros.

Bonjour, S'ils multiplient par deux la puissance, je suppose qu'on va voir arriver des quad quore à la place des dual core actuels... Mais d'un autre coté sur l'entrée de gamme malgré l'annonce d'il y a plusieurs mois on est toujours sur les stocks de l'année dernière, c'est à dire du vieux Celeron D et du PIV mono coeur. Donc déjà s'ils bazardent ça et mettent vraiment à disposition les Celeron 220 et Intel Pentium E2180, ce sera bien. Par contre il me semble que les changements de gamme se font deux fois par an, en mars et en septembre. Les changements de septembre sont souvent "à demi mesure" (du genre machine identique mais disque 33% plus gros par exemple, ou RAID offert). Après je suis loin d'être un expert OVH, mais ce qui a été annoncé dernièrement (frais d'installation si location d'1 mois, blocage des machines si considérées comme spammeurs par un organisme qui dit lui même être "très agressif", etc) je ne m'attendrais pas à une révolution en mars prochain.

Ou encore celui de l'hebergeur. La plupart du temps on se contente d'utiliser ceux du registar ou de l'hébergeur. L'indépendance, et un peu de souplesse éventuellement ; à condition d'avoir le temps et les connaissances pour gérer tout ça soi même. C'est parfois un problème de limitation aussi : ceux d'OVH ne gèrent pas les wildcards par exemple, et ceux de Mailclub ne permettent pas la gestion des DomainKeys. Dans mon cas je gère quelques centaines de domaines sur mes serveurs DNS, donc il m'est pratique de pouvoir "scripté" un peu tout ça. Mais pour une utilisation classique, ceux du registrar ou de l'hébergeur suffisent très largement. Quand on utilise leurs serveurs DNS oui. Après coté choix du prestataire c'est souvent une affaire de goût. J'ai acheté mon premier domaine chez Gandi (c'était le moins cher à l'époque) et j'ai toujours été satisfait ; donc maintenant je passe toujours par eux. Mais sinon GoDaddy a une assez bonne réputation également, notamment pour ce qui est de son interface de gestion (je précise : c'est ce que j'ai entendu dire, je ne m'en suis jamais servie). Pour ce qui est de l'interface d'OVH ou de MailClub, pour avoir déjà passé des heures dessus, moins je les utilise et mieux je me porte

Hello, généralement tout ce que fait le registrar c'est associer des serveurs DNS à ton domaine. Et c'est à toi choisir les serveurs DNS que tu veux utiliser : certains registars en proposent en standard, sinon tu peux souvent utiliser ceux de ton hébergeur, ou encore tes propres DNS si tu en as. Ensuite ce sont ces serveurs DNS qui permettent du dire tel et tel sous domaine pointent sur telle adresse IP. Mais pour ce qui est de l'association finale "domaine" => "dossier", ça se passe sur ton serveur dédié uniquement, dans la configuration d'Apache. Si tu es sur du mutualisé, c'est là aussi l'hébergeur qui s'en charge. === Pour ce qui est de la réplication, c'est à toi de mettre en place des outils synchronisant "automatiquement" les données entre les deux machines. Il y a de nombreuses techniques, chacune ayant ses avantages et inconvénients (aucune n'est parfaite malheureusement). Déjà il faut voir si tu cherches avant tout à faire de la "répartition de charge" pour limiter les ralentissements donc, ou encore si tu souhaites surtout de la "tolérance aux pannes". Ca peut paraître idiot, mais selon l'objectif les outils sont parfois différents.

Hello, à ma connaissance il n'y a aucun moyen simple d'obtenir cette info, tout simplement parce qu'elle n'a aucune utilité pour ce qui est de MySQL. Si cette valeur a une importance du point de vue de ton modèle de données, alors ce n'est certainement pas le type ENUM que tu dois utiliser.

Bonjour, c'est marrant dans ton erreur "déjà corrigée" tu as pourtant exactement ce que Dan a indiqué, y compris la faute de frappe. J'en remets une couche : $publish = (int) ( isset( $_POST['publish'] ) and ( $_POST['publish'] === '1' ) ); Il y a probablement des parenthèses en trop ou manquantes, mais je n'ai pas le courage de recompter ni tester, dsl. Si ça ne fonctionne toujours pas, commence par apprendre à débugger un minimum. Par exemple fait un var_dump() de la requête juste avant de l'exécuter, et active l'affichage des erreurs : error_reporting( E_ALL | E_STRICT );.

Et t'es certain de ton "whois" sur l'IP ? C'est quelle IP ?

Hello, je débarque mais visiblement ton serveur SMTP utilise l'identification "pop before smtp" ; bien que pratique (quand ça fonctionne) ce n'est pas vraiment fiable : si tu checks une boite mail en "POP" il accepte ensuite toute utilisation du serveur SMTP depuis ton IP durant par exemple 30 minutes. T'as pas intérêt à utiliser un accès Wifi en déplacement quoi... Dans tous les cas il vaut mieux à mon avis configurer l'identification via SMTP, même si tu utilises les mêmes identifiants. Maintenant comment faire ça sous QMail (je suppose), je n'en ai absolument aucune idée.

Hello, je suis peut être à coté de la plaque mais j'ai du mal à comprendre tes notations : - quand je vois "PC2-4200-444" je comprends qu'il s'agit de DDR2 4200 avec des timings 4-4-4 - quand je vois "PC2-5600-800" je comprends qu'il s'agit de DDR2 4600, et que les timings ne sont pas fournis. Non ? Et donc là tu te retrouvais avec une mémoire PC2-3200-288, c'est à dire si j'ai bien compris environ plus lente que la 4200 mais avec un meilleur temps d'accès (et encore, je suppose que les timings sont en cycle d'horloge, et donc à multiplier par la fréquence utilisée). Maintenant à la question "quel est le mieux", bah... ça dépend de ton utilisation, évidement. 1) Si ton système manque de mémoire et swap beaucoup ou bien accède beaucoup au disque car le cache fichier est trop petit, ajouter 1Go de mémoire va beaucoup aider oui. Sinon, pas forcément. 2) Si le système n'a pas l'utilité de ce Go de mémoire supplémentaire, la vitesse de la mémoire actuelle est plus importante que la quantité.

L'IP en question ce n'est pas tout simplement le proxy de Google pour les appareils mobiles ? Généralement ces proxies se présentent comme tel : le reverse DNS ou encore le user_agent indique qu'il s'agit de proxy et/ou passerelle. De manière générale, blacklister un proxy est une mauvaise idée, oui... si c'est ça la question Par exemple bloquer tous les abonnés d'AOL ou tous les fonctionnaires d'un coup, ça peut évidement avoir un impact sur ton trafic et/ou l'image du site.