Voilà encore une chose de faite… Le serveur de 2803 dispose maintenant d’un giga de mémoire au lieu des 512 mb initiaux qui commençaient être vraiment juste malgré toutes mes optimisations du serveur. Les équipes d’Iweb, l’hébergeur du serveur dédié de 2803 ont effectués ce remplacement hier (même pas le temps de leur dire GO que la barrette de mémoire était déjà installée).
Théoriquement je dois maintenant être un peu plus serein sur ce point!
Et vous vous avez quoi comme taille de mémoire sur votre serveur (si vous êtes en dédié bien sûr)?
42 Comments
512 Mo aussi… la honte ! Mais changement de serveur et 2 Go à la clé au printemps
Le serveur dédié te sert à héberger tous les blogs du réseau 2803 ?
yes c’est aussi pour cela que cela consomme
Je viens de passer en dédié chez OVH (parti de chez Dedibox) pour un serveur PIV 3Ghz avec 1Go de RAM et 750 Go de disque durs, et avec tout ça, je devrais faire rentrer facilement 40 domaines assez gourmands en ressources MySQL avec un traffic de 2Go / jour.
T’as combien de sites complets hébergés sur ton dédié ?
8 blogs wordpress plus ou moins actifs et avec plus ou moins d’audience
Pourquoi tu prends pas une dédibox ? Tu payes combien ton serveur actuel ?
C’est imbattable
Et puis je n’ai pas entendu que du bien sur les dédibox…
bob -> ouch c’est dur lourd ton truc
Moi j’ai 512 sur une brique gandi (leur nouveau système). C’est pas tout à fait un dédié d’ailleurs car ce sont des machines virtuelles mais ça fonctionne bien
Par contre mon blog est en mutualisé OVH
@Gonzague je consomme aussi 2G de bande passante par jour mais je ne sais pas comment… Avec 512 tu es large ou bien tu sens que cela est un peu juste?
Gonzague > Chez gandi, j’avais les mêmes benchmarks que mon serveur actuel chez OVH avec 6 parts. Donc en gros ça me coute le même prix, sauf que chez Gandi, c’est en BETA et que les prix finaux ne sont pas encore fixés…
La dedibox n’est pas faite pour héberger des gros sites, c’est un bon serveur FTP mais le processeur n’est pas capable de traiter un volume d’information important.
Par exemple, des benhmarks Apache/PHP (sans MySQL) ont donnés des résultats de plus de 100 secondes alors que chez OVH, je suis descendu sous les 40 secondes pour le même volume de commandes PHP à traiter.
Si on rajoute MySQL la différence n’est plus de 50% de moins chez OVH mais de 90% !!
Bref, c’était vite vu
Henri : tu as plus de sites aussi
En trafic avec mon blog perso uniquement j’en suis à 1 Go par jour et encore j’ai allégé tout ce qui est scripts etc.
Pour le dédié, je m’en sers pour faire quelques tests de la plateforme donc je ne lui ai pas fait subir de grosse montée en charge
Il y a quasi rien dessus. ça viendra plus tard
Bob : j’ai deux parts pour un Apache + Postfix + MySQL afin de lancer quelques projets. Pas mal de soucis avec mon mutualisé OVH que je finirais par bouger sur le Gandi (selon l’évolution des prix après la beta)
Henri > Tu aurais des statistiques d’utilisation de MySQL pour tes 8 sites (blog WP ?) ? Moi j’suis à environ 25 requêtes / sec avec des dotclear et des sites faits maisons mais surtout de plus en plus de WP et j’ai peur que ça n’empire avec le temps… Si tu ne sais pas ou voir ça, c’est dans PHPMyAdmin > “Etat du serveur” ou “Statistiques”.
Tu veux ça comme données ?
Statistiques sur les requêtes: Depuis son démarrage, 2 193 669 requêtes ont été envoyées au serveur.
Total 2 M ø par heure 207,18 k ø par minute 3,45 k ø par seconde 57,55
57,55 / sec… C’est quand même gourmand en requête WP
Ca a l’air de ramer encore un chouia en tout cas quand on poste un message, ça ne poste que 10 à 15 secondes après chez moi. (on verra pour celui là).
512mb, chez ovh.
4 blogs qui tourne dessus (wordpress).
Les seules fois où j’ai “presque” saturé, c’est quand j’ai fais des pointes à 40000 visiteurs (140000 PV). Et encore, c’est le CPU qui en souffre le plus. Mais ça va bcp mieux depuis l’installation de wp-super-cache !
Je vois que tu tourne sous apache, une astuce pour consommer moins de mémoire consiste à strip le binaire httpd avec la commande :
strip httpd
Du coup chaque processus httpd (= chaque connexion d’un navigateur sur tes sites) consommera un peu moins de mémoire.
57,55 / sec… C’est quand même gourmand en requête WP
Ca a l’air de ramer encore un chouia en tout cas quand on poste un message, ça ne poste que 10 à 15 secondes après chez moi. (on verra pour celui là).
(Ah ben en fait, quand j’ai essayé de poster il a essayer de me télécharger un fichier .php vide après 1 minute à ramer…). Vous avez les mêmes problèmes les autres ?
J’ai donc encore quelques soucis.. Mais je ne pense pas avoir les compétences d’audit du problème… Any help?
Je suis malheureusement en mutualisé…
julien > comme j’ai aussi 512 Mo chez OVH, ton cas m’intéresser => ta pointe de 40000 visiteurs, c’est sur quelle période ?
Pti-seb > elle sert à quoi cette commande strip ? concrètement, si apache consomme moins de ressources, c’est que quelque chose se fait en moins… et c’est quoi ce quelque chose ?
Henri,
iweb est hébergé au Canada si je ne m’abuses. Tu préfères pas avoir une IP en France pour ton site ?
@Quentin : strip efface les symboles qui sont insérés dans les fichiers compilés, donc tu te retrouve avec un binaire plus légé de quelques Ko.
Le truc c’est que pour chaque processus, donc chaque connexion clients, le binaire est chargé en mémoire. Donc genre si tu gagne 100ko, il faudra multiplier ce gain par le nombre de processus.
Maintenant, j’ai remarqué que sous certaines distribution, le binaire est déjà strippé …
@Nico plus de problème depuis que Google te permet de définir la zone géographique de ton domaine
As tu constaté une augmentation de trafic depuis la modif de la zone geo ?
Je me demande toujours la part de recherche de l’option “France” de google
Quid des autres moteurs ?
@Quentin
Les 40000v c’est avec le blog d’un ami, sur une période de 3 jours, pendant le buzz sur laure manaudou (vers mi-décembre)
4 Go de RAM, donc ça trace
Par contre, que du fait maison, bien mieux.
Et oui, WordPress est beau, mais gourmand pour ce qu’il fait de base. Et je parle pas des dizaines de modifs successives qui empirent bien les choses. Enfin, c’est pas pire qu’un phpBB ou d’un OsCommerce ou d’un OpenAd … le Open Source a encore de gros progres à faire en terme de perf
Pour le temps au niveau de l’envoi des commentaires, ça ne serait pas un anti spam qui se connecterai à un truc à distance pour vérifier justement qu’il ne s’agit pas d’un Spam ?
@Jeremy G. c’est vrai que cette histoire des 10 secondes pour les commentaires est quelque chose de bizarre, je penchais pour ma part au plugin de mise en cache qui doit mettre un peu le souk..
Mais au final non car sur les autres blogs avec une base mysql plus petite cela ne nécessite pas autant de temps
Un systeme de cache qui prend autant de temps, et qui … à première vue en tout cas, ne semble pas rendre le site plus rapide. Sincèrement j’espère que ce n’est pas ça
J’ai un forum de plus de 4 millions de messages en base, le systeme de cache permet un affichage instantané, et l’envoi des messages est tout aussi rapide.
Je me sers pas trop trop de WordPress, donc j’ai pas eu le temps de faire un Bench (test de rapidité) mais je sais que pour OsCommerce … c’était vraiment n’importe quoi, et le avant/après était vraiment impressionnant en terme de performance.
Je pose quand même la question mais bon .. ils ont pas prévu un mode de debug pour voir ce qui pourrait prendre du temps ? Généralement suffit de modifier quelques dizaines de ligne pour améliorer très efficacement la performance.
En fait le système de cache fonctionne très bien mais dès qu’il y a une écriture dans la base mysql le système patine à fond et ça c’est un peu chiant.
Ouaip, je confirme que la validation d’un commentaire est toujours anormalement longue, ce problème n’est pas dû au plugin de modification d’un commentaire ?
Jul : je ne pense pas car ce plugin fait appel à du JS et là c’est le temps de “connexion” au serveur qui est énorme entre le moment où tu postes et le moment où la nouvelle page commence à s’afficher. Si c’était le plugin , ça ralentirait juste l’affichage des pages pour charger les kilo-octets de script
@JUL je viens de le virer pour faire un test.
@Gonzague pas mal ton explication, heureusement que la vitesse d’affichage est plutôt pas trop mauvaise…
Le plugin est toujours là on dirait, et ça n’a pas l’air de s’être amélioré !
J’en ai viré un autre
La lenteur de post existait déjà avant la modification après post, donc ça doit pas être ça dans tous les cas.
Jeremy G. je ne comprends pas trop ton commentaire. Tu veux dire que cela met tjs autant de temps?
Le plus simple pour savoir, c’est d’essayer
(EDIT : 10 secondes tout de même pour être posté mais c’est moins que la dernière fois)
Je dois certainement encore avoir un plugin merdique qui traine…
Si tu as l’occasion de le faire, henri, et que tu ne l’as pas encore essayé, regarde du côté de WP Super Cache qui est plutôt impressionnant, en matière de gains de performances, pour l’essentiel des utilisateurs, puisqu’il permet tout simplement de stocker les pages du site directement dans l’arborescence de fichiers, sous forme compressée et non compressée, et gère très correctement les caches des navigateurs. En somme, le PHP n’est même pas sollicité pour fournir la page web à l’essentiel des utilisateurs. Toutes les configurations de serveurs ne le supportent pas, cependant.
Martin j’utilise wp-cache tu conseilles le passage à super cache?
Hum, hard quand même un cache en dure pour aller plus vite …
Une optimisation dans ton cas devrait largement suffire. Mais évidemment, faut savoir où et comment chercher.
Tu n’essayerai pas de voir ligne par ligne ce que fait Wordpress quand tu postes un commentaire ? et tu commentes par bout de code pour tester ce qui pourrait provoquer les lenteurs (évidemment, tu ne bloques pas l’insertion du commentaire, sinon ça n’a plus trop d’intérêt). Après je dis ça, en supposant que tu es des bases en programmation.
PS: 13 secondes pour envoyer ce message
Si tu veux bien m’expliquer comment faire pour installer ce contrôle ligne par ligne je veux bien le faire
Car ce problème commence à me souler un peu! Merci par avance.