Reprise du message précédent :

 
My 2 cents :
 
root@kangaroo:~# pv /dev/md6 | gzip  > /dev/null
 160MB 0:00:20 [ 8.5MB/s] [>                                 ]  0% ETA 14:31:23
root@kangaroo:~# pv /dev/md6 | gzip -1 > /dev/null
 110MB 0:00:09 [10.5MB/s] [>                                  ]  0% ETA 9:28:20
root@kangaroo:~# pv /dev/md6 | gzip -9 > /dev/null
 120MB 0:00:19 [8.19MB/s] [>                                 ]  0% ETA 18:22:56
 
donc en gros, oui, le gzip, ca bouffe, mais sur un P4 a 3 Ghz, ca compresse quand meme environ 10 Mo/s, meme en -9.
 
Donc avant que cela soit significatif va falloir faire un packet de traffic (rappel : 10 Mo/s en continue sur 1 Mois, ca fait 25 Tera de traffic/Mois)
 
 
Pour les optimisations de mémoire & co, pareil, faut pas se toucher, a priory ca ne sert vraiment pas a grand chose d'enlever des services qui de toutes facons ne sont pas utilisés, vu que ceux ci sont de toute facon swapper. Si votre serveur est trop juste en ram, ce n'est pas en enlevant l'identd que vous allez changer quoi que ce soit, mais plutot en optimisant le service qui bouffe : apache (et/ou mysql).  
 
En plus, je dirais qu'il ne faut pas se laisser avoir par la consomation mémoire d'un truc qui tourne a vide : deja, beaucoup de service n'alloue pas la ram tant qu'ils n'en ont pas besoin, et meme sans cela, le noyau (linux en l'occurence) n'alloue pas la mémoire alloué tant que celle ci n'est pas reelement utilisée (c'est a dire que si votre apache demande 100 Mo de ram au démarrage mais que seul 10 mo ont reelement été utilisé (parce que seul vous etes passé sur le site), et bien linux, intelligement, n'allouera que 10 Mo a apache). Le probleme étant bien sur que le jour ou tout les processus qui "pensent" avoir 100 Mo de ram l'utilise reelement, votre machine explose.
 
 
Enfin, je me permet de rajouter un hébergeur a la liste des "truc-cher-mais-qui-marche-bien" (surtout niveau vds) : http://www.enix.org/

 
J'ai 8 tokens, soit 300mhz, pas un P4 3ghz et le swap n'est pas autorisé en VDS, donc désolé, 1Mo de gagné par ident, c'est toujours 1Mo.

 
Ha.
 
Mes condoléances
 
Note que meme 300 Mhz, ca fait 1 Mo/s
 
Pour le swap, ba ... faut se prendre un vrai vds, pas un truc daubesque basé sur vserver.

 
Pour l'instant je m'en fou, mon petit vds tient sans probleme la charge, on verra plus tard mais bon pour info c'est :
Cpu -> 300Mhz Burstable  (8 tokens sur Bi P4 Xeon 3.2Ghz)
Ram -> 160Mo Burstable
DD -> 1Go
BP -> 2Mb en upload.

On peut faire 10 Mo/s avec du gzip, seulement sur un serveur web qui crache 10 Mo/s il serait dommage de négliger la charge utilisée déjà par les services qui tournent. C'est comme dire qu'un disque et un CPU vont aussi vite quand on les bench à vide que quand on les bench pendant une compression d'archive

 
Non, ce que je veux mettre en avant, c'est que sur une page qui met, on va dire, 1 seconde à se generer, le gzip prend 0.005 sec.
 
Donc passer la compression de "default" (8Mo/s) a "minime" (10 Mo/s) ca ne sert vraiment pas a grand chose.
 
Accessoirement, aucun serveur web ne crache 10Mo/s. Aucun serveur web ne crache ne serait-ce que 1 Mo/s si tout ce qu'il fait est servir des pages php
 
Il vaut mieux, a mon avis, chercher un systeme qui ira *fondamentalement* plus vite, par exemple avec un optimiser de php, ou alors avec un boa ou autre (qui permettra de limiter le nombre d'instance apache au traitement du php seulement), etc etc.

De toute façon j'ai viré le gzip, comme ça, pas de probleme

 
Je suis assez d'accord avec toi effectivement, sauf sur le fait qu'aucun site ne crache 1 Mo/s de PHP et 10 Mo/s vu que j'ai mis en place des serveurs qui ont pousser ça.

 
Ca d'apres les tests que j'ai réalisé, c'est une mauvaise idée.
 
Deja, cela influe bcp sur la bande passante serveur (une page d'html type se compresse au moin a 70%) ... et en fait, en pratique, ce qu'il se passe, c'est que ton serveur est occupé plus souvent a "envoyer des données". Donc il faut plus de processus apache pour gerer la meme quantité de client ... donc plus de ram etc etc etc nécéssaire
 
Enfin si ca marche mieux pour toi ...

 
 
Ouais enfin le gain de RAM est accompagné d'une montée de la charge et de l'occupation CPU non négligeable, donc bon c'est un choix, perso je préfère ajouter de la RAM que changer les CPU...

 
+ de processus == plus de ram, mais aussi moin de cache dispo pour chaque processus lors du context switching, moin de place pour le cache disque, etc etc.
 
En pratique, sur une machine avec ressource limité, généralement la puissance "raw" du cpu n'est pas un probleme, la ram, si (en tout cas, sur le VDS d'ou est parti ce debat, ca avait l'air d'etre le probleme).
 
Sans oublié le fait qu'a mon humble avis, la "montée en charge" est justement completement négligeable (vu que le gzip ca va quand meme tres vite sur des documents de 15-20 ko).

 
Pas vraiment non, c'est d'ailleurs un soucis pour pas mal de sites à forte fréquentation ( ratio nb de machines / bande passante totale )

Sur le dernier site a fort traffic que j'ai eu sous la main (un forum p2p qui *était* assez connu), j'ai d'abord cru qu'en effet cela était conséquent, jusqu'a ce que je me rende compte que le serveur ramait moin quand celui ci était activé
 
Mais manifestement on a pas les memes retour d'experiences
 
edit: quelques benchs vite fait pour étayer mes dires :
 
root@kangaroo# ab -c 1 -n 1000 -H "Accept-Encoding: deflate, gzip, x-gzip" http://kangaroo/test/test.php
[plein de truc]
Time per request:       5.908 [ms] (mean)
[plein d'autre truc]
 
root@kangaroo# ab -c 1 -n 1000 http://kangaroo/test/test.php
[plein de truc]
Time per request:       4.285 [ms] (mean)
[plein d'autre truc]
 
le contenu de test.php est : "<? phpinfo(); ?>"
il y a dans le meme repertoire un fichier .htaccess qui contient : php_flag zlib.output_compression On
(ce qui a donc pour effet de compresser les pages si le client le permet)
 
Le -H "Accept-Encoding blalbalbal" passé en parametre a ab sert justement a faire croire au serveur web que ab est un client capable d'interpreter le gzip, alors que par default il ne le peut pas. Il en resulte des pages envoyé compressées dans le premier cas, alors qu'elle sont non-compressé dans le 2eme.
 
On voit clairement que la difference moyenne de génération de page est de 2 ms. Une page phpinfo fait environ 7 ou 8k, elle n'est donc pas de taille négligeable.
 
Sur une page normale, telle que celle de ce forum (qui est particulierement bien optimisé), le temps moyen de génération est de l'ordre, au minimum, de 20 ou 30 ms. Donc y rajouter 2ms ...
 
Mais bien entendu, on ne parle de l'incidence que sur des pages dynamiques ici, la difference lorsqu'il sagit d'une compression de page statique est bien plus importante.
 
BREF !

C'est pas un problème de temps de génération mais un problème de charge derrière, ici elle est conséquente dès qu'on passe en compression toutes les pages ( ce qui nous empêche pas de le faire cependant pour limiter la BP ).

Je ne comprends pas bien comment gzip peut diminuer l'occupation-mémoire. Sans connaître précisément son fonctionnement, j'imagine que la page non compressée est d'abord entièrement bufferisée, puis compressée avant d'être envoyée au client.
Perso, tout ce que je vois, c'est deux opérations supplémentaires : la bufferisation entière de la page (d'accord c'est souvent le cas, même sans gzip) et surtout la compression.
 
Même si je comprends qu'envoyer un petit fichier est plus rapide qu'en envoyer un gros, j'ai vraiment du mal à comprendre comment on peut, au final, économiser de la mémoire avec une opération supplémentaire. Si quelqu'un peut m'éclairer...

 
Pour information, gzip est capable de bufferiser un flux par pallier de 4 ko je crois. Potentielement, donc l'overhead mémoire est inéxistant (vu que la compression peut se faire avec une bufferisation de 4k), meme si je suis loin d'etre sur qu'apache/php procede de cette maniere. Dans tout les cas, une page de 30 ko ... ba, a coté de l'interpreteur php, c'est négligeable, il faut avoir 300 clients *simultané* (ie, pas 300 visiteurs sur le site, mais 300 requetes en meme temps) pour que cela prenne 10 Mo ... A noter qu'on parle de requete sur un .php la, donc un forum bardé de petit smiley (qui prenne a chaque fois 1 requete pour etre chargé) qui fait au total 300 requetes/secondes n'a rien a voir.
 
Et ce que je met en avant, c'est juste que si on passe moin de temps a envoyer la page, alors le process apache correspondant est libéré plus vite pour faire autre chose, donc potentielement il peut etre réutiliser la ou il aurait pu etre nécéssaire d'en recreer un (et donc de gaspiller de la ram). Une page de 30 ko qui est compressée en une page de 5 ko, quand elle est envoyé a 512k (donc 60 ko/s), met 0.1 secondes a etre envoyé plutot que 0.5 secondes. Rien de sorcier (petit rappel : pour la compresser sur un P4 a 3Ghz, on a mis 0.002 sec). Un process apache creer, si je me souviens bien, c'est "quelques mo" utilisé, genre entre 2 et 4.
 
J'arrete de répondre a ce topic vu que je pense que tout les éléments sont entre les mains des gens qui veulent se faire un avis, et que mes posts commencent a reelement ressembler a du spam

Qu'elle différence de compression GZip entre le level1 et 9 ? le 1 enleve que les espaces c'est ça ?

Krystal_ : la taille du process Apache dépend de ses modules et de la page à générée, donc tu peux pas estimer comme ça sa taille, c'est très variable entre le Apache utilisé et la page à afficher. D'ailleurs tu peux très bien avoir 2000 processus Apache sur 1 Go de RAM pour un serveur de download de media et exploser les mêmes 1 Go avec 250 processus Apache sur des pages PHP.
 
Soit dit en passant Apache ( du moins pour la version 1 ) fonctionne par slot et peut avoir un keep alive, donc ton calcul qui estime qu'un processus apache est libéré suite à la requête est un peu inexact comme il est présenté, puisqu'Apache se garde le slot au chaud pour éviter la charge de devoir reforker un process lors d'une nouvelle requête ( plus pénalisant quand on a de la RAM que de laisser le process en RAM en attente )
 
Bref tu fais beaucoup de calculs "sur le papier" mais tu ne prends pas tout en compte là D'autant qu'à gros volume si ton CPU arrive à 100% d'occupation ton site s'écroule car les processus commencent à s'entasser en RAM et rien ne va plus, tout comme tu peux dire et là je serai d'accord, que si ta RAM est saturée par les processus ça s'écroule aussi.

Je repose ma question qui est passée inapercue (vive les topics uniques )
 
Bonjour,
Je recherche un hébergement avec nom de domaine pour le site de mon association http://toursmoreau.dynalias.org/
Qu'es-ce que je peux prendre pour garder une marge en espace et pourquoi pas la gestion de bases de données, au mailleur prix pour un .fr  ?

Qu'elle charge (hits, Bande passante) ? combien d'espace ?

salut,
jusqu'au 31/12 tu as l'offre de 1and1.fr
ça te laisse le temps de tester, et de migrer vers une autre offre payante si tu le souhaites.
tu paieras juste ton .fr
 
sinon dans 2-3h, vu sur la ML, ovh va annoncer un cadeau de noël, mais pas de détails pour l'instant.
 

 
edit : voilà le cadeau en question
 
http://www.ovh.com/fr/produits/noel.xml

Un cadeau est toujours bon à prendre, mais c'etait quand même pas la peine d'essayer de faire monter la pression pour annoncer ça (c-à-d 2 Go par compte mail).

ah ben c'est OVH ! ils font monter la sauce pour t'annoncer un truc bidon.
 
Ils feraient mieux d'avoir des serveurs mail qui tiennent la route plutot que d'augmenter la taille des boites.

C'est sympa 2go, mais bon mon bon vieux compte gmail fait deja 2.6go...

J'ai donc 33 fois plus de place sur le compte mail qu'en hébergement  

Car statistiquement, personne ne doit utiliser 2go d'espace pour des mails

hello !
 
j'aimerai avoir votre avis sur cet offre :
 
http://hebergement.netissime.com/h [...] ndows.html
 
sur le 50mo a 18€ht/mois
 
merci  

C'est ultra cher, mais bon, les windows ça ne court pas les rue en offre d'hebergement...

 
hebergement windows sert que pour l'asp ?  
 
c'est quelqu'un que je connais, on lui propose ca comme hebergement... il y connais absolument rien.
 
Je dois moi meme faire son site internet (html/css/php)
 
je vois pas l'interet d'un hebergement aussi cher et pourquoi ils lui ont conseillé de prendre un hebergement windows...

Si c'est en php, mieux vaut un hebergement linux, les hebergements windows ne sert que pour les langage specifique a windows, mais meme l'asp peut tourner sous linux.
Si le trafic est petit tu peux te tourner vers www.les-basics-nfrance.com ou la version pro www.nfrance.com (gros traffic, site commerciaux, ...)  

 
c'est juste un site présentation/contact pour une sté, donc pas de gros traffic, ni de langage spécifique.
 
Merci pour les liens  

de rien

 
Sinon un petit 60gp chez OVH, ça coute quasi rien (12€HT par an) et ça marche tres bien.

Bon un petit post pour avoir vos conseils.
 
Ça fait maintenant 2ans que j'ai un hébergement payant chez Llord en mutualisé.
 
Je compte peut être bientôt changé si les problèmes que je rencontre avec eux ne sont pas résolues très rapidement  
 
 
Dc vers qui me tourner ?
 
Mes "exigences" :
 
Faire tourner sans ralentissement un forum phpBB qui compte actuellement 60 000 messages que je ne compte pas délester... donc pas de limitations de taille de bdd (ou bien au mini 100mo pour être tranquille-> actuellement 61mo de taille sql d'après le cpanel de llord).
 
Pour le moment il n'y a pas de site a proprement parler (enfin si mais il n'est plus maj et est sur free) vu que j'avais 500m d'espace sur llord je comptais créer un beau site en utilisant env. 200mo. (site en php assez simple).  
Au niveau bande passante c'est dur à qualfier car actuellement je n'ai que le forum qui tourne. Actuellement c'est env 3go/mois.
 
Les tarifs chez llord sont assez bas par rapport aux autres hébergeurs d'après les recherches que je viens de faire :

 
Je n'irais pas chez ovh car d'après ce que j'ai pu lire il n'aime pas les "grosses" bases (même si je ne qualifié pas ma base de grosse...)
 
Donc qu'est ce que vous avez à me proposer svp ?
On m'a conseillé sivit.fr mais les tarifs sont bien plus élevés et je ne trouve pas bcp d'info sur le forum    
Qu’en pensez vous ? Avez vous mieux?
 
 
Merci bcp  

D'un coté un phpbb ça te plombe un serveur
 
Sinon tu veux y mettre quel prix ? perso je suis en VDS pour 10€ / mois et ça tourne niquel.

que me conseillez vous pour hoster un e-commerce ?
 
par notoriété et qualité de service javais entendu claranet/oleane.
 
avez vous dautres a me conseiller svp ?

 
Evite Claranet qui n'est pas terrible niveau datacenter et qualité de réseau, évite Oleane pour le rapport qualité / prix je pense.
 
Tu veux un dédié infogéré ou juste un dédié en baie ?

Sly > Me semblait à un moment que tu étais chez Clara ou Oleane et que tu en étais content ?
 
Ou alors c'est HFR (Le site) qui y était ? Me souviens plus ... Ou alors France Express ?

Pourquoi vous faire chier a acheter un server ?
Vous avez juste a envoyer un trojan qui installera un key logger et un backdoor chez qq'un qui gere des boxs
 
XaT

env 5€ /mois comme pour mon compte actuel ..
 
VDS c'est la technologie ça non ?
tu as un lien de ton hebergeur ?
 
http://www.celeonet.fr/_comparatif vous connaissez ?

Je connais, j'ai même hésité a prendre chez eux, ca m'a l'air d'être bien
 
XaT