Kioob

Hello, si on en croit Wikipedia, le Xeon L3426 utilise la même architecture que le i7 qu'on retrouve chez OVH. Seulement ce Xeon tourne à 1.86Ghz là où l'i7 du Kimsufi est à 2.66Ghz. Si c'est la puissance CPU qui t'intéresse, il n'y a pas photo, l'i7 doit être nettement plus péchu. Pour le reste, c'est une question de choix. La Dedibox Pro, est un vrai serveur, avec tout ce qui va avec (ne serait-ce que l'IPMI), là où le Kimsufi est une machine de supermarché : une grosse étiquette aguicheuse pour attirer le client, mais certainement pas la même fiabilité.

Chez nous c'est un peu comme Dadou : - un unique serveur SVN, local - un serveur de dev local, où chaque développeur a sa propre arborescence. C'est aussi sa "Working Copy SVN", à laquelle il accède via CIFS/NFS. - quand le développeur veut livrer ses modifs, il fait son "svn commit" - un unique serveur de test local également (pour le moment en tous cas), sur lequel on lance un script de mise à jour (grosso modo : svn cleanup; svn reverse; svn update; minify css/jss. le svn export était trop lent à notre goût) - on y fait tous les tests qu'on veut - si le résultat nous convient on lance un script de propagation vers les serveurs de prod (via N rsync en parallèle)

Je débarque un peu tard, mais de mon coté je n'ai aucun soucis à stocker ce genre de chose avec du MySQL, dès lors qu'on utilise InnoDB/XtraDB et non le MyISAM. Après comme l'explique jcaron il peut y avoir beaucoup d'autres facteurs derrière, qui feront que ça tournera plus ou moins bien, mais dans l'ensemble je n'ai vraiment rien à reprocher à MySQL sur du "gros volumes" (base de 40Go sur une machine ne disposant que de 12Go de mémoire).

mais de rien

Non pas besoin d'une délégation DNS pour ça. Juste un enregistrement A avec l'IP qui va bien suffira.

Bonsoir, c'est une configuration plutôt classique, sur quoi bloques tu ? Dans les grandes lignes : *) coté DNS, tu configures tondomaine.com et www.tondomaine.com avec l'IP de la machine A *) coté DNS toujours, tu configures forum.tondomaine.com avec l'IP de la machine B *) coté Apache, tu configures le virtualhost pour tondomaine.com et www.tondomaine.com sur la machine A *) coté Apache encore, tu configures le virtualhost pour forum.tondomaine.com sur la machine B Après pour "tonautredomaine.com", bah pareil, tu fais pointer ce que tu veux où tu veux.

Hello "Biloute", je ne suis pas sûr que repartir sur ce thread soit une bonne idée, mais soit. Le premier truc qui me fait peur dans ton message, c'est que tu indiques "performances faibles pour un prix trop important" : hors OVH c'est déjà du low cost, on peut leur reprocher pas mal de choses mais difficilement le prix. Pour ce qui est de la différence entre mutualisé, virtuel et dédié, plutôt que de répéter les (nombreux) sujets de ce genre je vais tenter une analogie : - le mutualisé, c'est prendre les transports en commun, le bus. Il faut faire avec le trajet imposé, et c'est plutôt inconfortable quand le bus est plein. - le dédié, c'est prendre ton propre véhicule. Tu dois savoir conduire et connaître ton itinéraire. Si ton budget ne te permet que de prendre une mobilette, t'iras pas forcément plus vite qu'en bus, tu seras plus exposé en cas d'accident et t'y gagne pas forcément en confort. Par contre si tu peux te payer une belle berline avec chauffeur (= gros serveur avec infogérance), c'est tout confort. - le virtuel, c'est entre les deux : tu dois savoir conduire et connaître l'itinéraire (bien que le chauffeur reste possible), mais la voiture c'est plutôt une voiture de location. Tu peux changer de véhicule tous les jours en fonction des besoins, de la twingo à la porsche, et t'as pas à te soucier de l'entretien du matériel. Voilà... maintenant je ne sais pas si ça t'aidera beaucoup. Pour revenir à ton cas, tes 50'000 visiteurs, c'est par jour ou par mois ? Et ton site e-commerce, il est basé sur un outil opensource ? (oscommerce, magento, prestashop, etc)

Pour le cache coté navigateur c'est forcément un peu plus limité oui. Dans le cas de ssi, si tu veux garder un comportement un minimum dynamique pour tes news tu ne pourras pas avoir de longue durée de mise en cache (ça n'empêche pas de mettre en cache quelques minutes par exemple). Sinon il faut effectivement séparer ces news dans une iframe... ou bien les rafraichir via du JS, je ne sais pas ce qui est le mieux / "moins mal".

Bonjour, justement la commande "date" donne l'heure du serveur. Qu'est ce qui te faisait penser que ton serveur n'est pas à l'heure ?

Hello, c'est pas si simple, la première chose à faire est d'identifier la cause du ralentissement. Et pour ça, faut surveiller les divers "ressources" du serveur : CPU, accès disque, mémoire, bande passante, et autres joyeusetées telles que les sockets ouverts, les slots Apache & MySQL, et tant d'autres choses rigolotes. Bref, commencer par installer un (bon) outil de monitoring. Pour ma part j'utilise Zabbix, mais j'aurais tendance à conseiller quelque chose de plus simple pour débuter, tel que Munin par exemple.

Bonjour, en terme de performances, avec un outil comme varnish derrière pour gérer le cache de la zone "news" ainsi que le ssi, la solution "SSI" est pour moi loin devant les autres. Le plus rapide oui, mais pas forcément le plus puissant, souple, ou simple. Déjà je ne sais pas ce que tu comptes utiliser comme hébergement, mais le SSI ça n'est pas forcément très fréquent chez les hébergeurs mutualisés... et du SSI sans cache, avec "news.html" qui pointe sur du PHP/JSP/Python/Ruby/autre, ça n'a guère d'intérêt coté perfs. - référencement : tout ce qui se passe coté serveur, c'est à dire toutes les solutions autres que l'iframe sont transparentes pour le client, que ce soit un navigateur ou un robot d'indexation. Donc du moment que tu n'utilises pas d'iframe, c'est tout bon. - cache : tu parles du caches coté client ou serveur ? Dans tous les cas c'est jouable, moyennant des outils/techniques plus ou moins complexes... mais sans plus d'info difficile de répondre. - sécurité : pour moi ça n'a aucun impact ici. Bref, si tu as accès au système, et envie de jouer avec des outils tels que Varnish, je dirais banco pour le SSI. Sinon, rester sur du classique dynamique, compatible avec 99% des hébergements mutualisés.

Si tu n'as pas non plus de phpmyadmin, openx, ou autres applis pouvant faire office de porte dérobée, non pas besoin de changer les users PHP (enfin, faut pas non plus qu'Apache soit propriétaire des fichiers quoi). Quant à phpsecinfo, la seule fois que je l'ai testé c'était dans un environnement FastCGI+SuExec, et il racontait un peu beaucoup n'importe quoi.

euh tu disais "a 100 au lieu de 48" ; là dedans ni l'un ni l'autre de correspond à "root". Donc à quoi correspondent tes ID 100 et 48 ? (désolé j'ai pas de fedora) Pour PHP, pas en standard non justement. Mais généralement on essaye d'utiliser un compte différent par site/application, par mesure de sécurité. Enfin c'est un poil plus complexe à mettre en place, vaut mieux laisser faire l'admin sys pour ça.

Hello, généralement on change les droits de PHP, pas ceux d'Apache. Es-tu certain de bien vouloir faire ça ?

Bonjour, déjà, personne n'a jamais dit que "ndd.tld" et "www.ndd.tld" devaient pointer au même endroit. Ca n'est qu'une habitude plus ou moins répandue. La première chose à faire serait donc de vérifier la configuration DNS, puis vérifier en interrogeant directement les serveurs DNS pour éviter tout problème de cache. Si tu n'as pas de "nslookup" ou autre "dig" sous le coude, tu peux utiliser un outil en ligne : http://www.kloth.net/services/dig.php Mais sans le domaine en question, je ne pourrais guère t'aider plus je pense.

Tu y mets beaucoup de mauvaise foi là : j'ai personnellement un facteur de 10 entre les deux mesures, et sur la deuxième page il y a une partie des conseils fournis par PageSpeed concernant le temps d'affichage. Que te faut-il d'autre comme preuve ? Qu'ils remplacent "chargement" par "affichage" ? C'est juste la traduction qui te chagrine ? Et en quoi la société Google se doit elle d'être neutre à ce sujet ? Cela te choque vraiment qu'elle mette en avant les sites les plus efficaces avec ses propres produits ? C'est comme s'il était prouvé qu'ils mettaient en avant les sites utilisant adsense/adwords, on peut le regretter, mais après tout Google reste une société non ? Et pourtant certains en font leur métier et font de l'audit en ce sens avec de très bons résultats à la clé. La "performance web", ça n'est pas nouveau, ça arrive juste un peu tard en France. Il y a pas mal de bouquins, blogs et autres medias qui y sont consacrés ; donc ça doit pas être si ingérable que ça non ?

ici : Pour ce qui est du "choix" du navigateur, pourquoi n'auraient-il pas le droit d'utiliser leur navigateur maison ? Pour ce qui est des détails techniques, as-tu au moins essayé PageSpeed dans Firefox ou l'équivalent intégré à Chrome ? C'est plutôt bien foutu, bien que pas parfait. Par exemple, le "domready" et la fin de chargement "complète" sont clairement identifiés, comme dans la plupart des outils du genre.

Dans les outils Webmaster de Google on voit clairement que Google mesure le temps de réponse et le temps d'affichage de manière très distinctes. En effet j'ai un site avec des graphiques "temps de réponse" ayant une moyenne de 300ms et des graphiques "temps d'affichage" de l'ordre de 4 secondes. Et à mon avis, ils vont opter pour ce deuxième critère, bien plus exhaustif. Ca fait déjà un moment que des rumeurs de ce genre circulent, et chez nous des décisions ont déjà été prises en ce sens (comme virer certaines intégrations publicitaires trop lourdingues). La bonne nouvelle pour moi c'est que ça va peut-être forcer les développeurs à prêter attention à ce genre de choses. Edit : dans les "Outils pour les webmasters", dans "Diagnostic => Statistiques sur l'exploration", on a le temps de téléchargement des pages. Tandis que dans "Labos => Performances du site" on a le temps d'affichage réel.

Du tout, ça peut justement être les deux, mais ce n'est certainement pas avec les infos que tu donnes qu'on va deviner lesquels Il faudrait au minimum les graphiques de monitoring des différentes ressources, ainsi que vérifier quelques points comme le résolveur DNS utilisé.

Bonjour, dans l'emailing il y a de nombreuses pistes à explorer / vérifier pour optimiser les temps d'envoi. Il faudrait commencer par rechercher et identifier ce qui coince coté ressources, non ? (par exemple : entropie, I/O disques, bande passante, résolveur DNS, etc) Après pour ce qui est de l'optimisation du logiciel qmail, c'est essentiellement une affaire de goût mais je l'aurais personnellement bazardé depuis longtemps pour quelque chose de moderne (Exim ou Postfix, par exemple).

Hello, les SSD sont intéressants pour les écritures, ainsi que les lectures dès lors que les données ne tiennent plus en cache. J'ai par exemple une base de données de plus de 40Go qui en tire bien parti. C'est particulièrement intéressant pour les bases de données de grosse taille ou avec bcp d'écriture, certains systèmes de cache disque, ou encore les serveurs de mails. Au niveau de mes choix c'est un priorité des SSD, et si la place manque j'opte pour cette gamme hybrid. Je ne garderai la gamme "classique" que pour les clients étant un peu courts coté budget. Pour moi le disque dur prend peu à peu la rôle des cassettes DAT d'il y a quelques années : c'est super lent et réservé uniquement au gros stockage. Enfin je dis ça mais j'attends toujours la gamme HG Hybrid...

Ils proposent même OSCommerce et PrestaShop "en 1 clic", donc sur le principe je pense pas qu'ils soient contre Magento. D'ailleurs ce choix de Magento est un choix définitif ?

Bonjour, un mutualisé de qualité peut-être bien plus sécurisé qu'un dédié mal configuré. Le soucis serait plutôt le manque de souplesse, les quotas, le fait de partager les ressources avec d'autres (et donc de subir des ralentissements par leur faute), et autres limitations. Par exemple j'ai un client qui utilise Magento et ses scripts PHP dépassent souvent les 100Mo de mémoire consommées ; chose que personnellement je ne tolérerai pas de si tôt en mutualisé. Pour ce qui est du "semi dédié" (serveur virtuel je suppose ?), c'est un mixte entre les deux : on a la souplesse et la complexité du serveur dédié, tout en partageant les ressources avec d'autres, généralement ça revient moins cher qu'un dédié. Je ne sais pas quelles sont les limitations chez OVH, mais j'aurais tendance à d'abord essayer leurs offres mutualisées. Quitte à changer si ça coince.

mmm tu supprimes bien toutes les références pour cela ? Y compris ta variable globale ?

Bonjour, quand tu fais ton $this->cnx = $cnx;, tu crées une référence vers l'objet en question, et $this->cnx = null; ne fait que détruire cette référence. Or, tant qu'il restera au moins une référence vers l'objet, il ne sera pas détruit. Donc dans ton cas, tant que la variable globale existe ou bien qu'il reste des instances d'objets ayant eux-même créé une référence, la connexion n'est pas fermée. Ajouter un destructeur pour effacer le $this->cnx ne changera donc rien du tout, d'autant plus que PHP se charge déjà d'effacer toutes les propriétés de ton objet. Je ne suis pas sûr d'avoir compris ce que tu cherches à faire : si tu veux t'assurer que la connexion soit bien fermée en fin de script, c'est déjà le cas, toutes les références étant forcément détruites le destructeur PDO est bien appelé. Maintenant si tu veux gérer ça de manière plus efficace en n'utilisant la connexion PDO que si nécessaire et en la détruisant dès que possible, ça va être plus compliqué oui et dépend essentiellement du cheminement de tes scripts. Par exemple pour ma part je m'assure de couper la connexion PDO avant de débuter le moindre affichage.