Comment dimensionner l'hébergement d'un nouveau site

[OJAL]

Bonjour,

Nous allons bientôt lancer un nouveau site dans lequel nous avons intégré d'assez gros catalogues. Le site est composé de 30.000 pages.
Le référencement sur GOOGLE est crucial et tout est normalement mis en place pour que le référencement se passe correctement.
Néanmoins, nous nous posons la question de l'hébergement de ce site...
En effet, si on moyenne la taille des pages à 70Ko, on s'aperçoit que lorsque GOOGLE aura indexé les 30.000 pages, il aura dowloadé 30.000*70= 2.100 Mo, soit 2,1 Go...
C'est clair que coté GOOGLE ça ne va pas leur poser trop de problème, mais de notre coté, ça risque de coincer coté hébergement...

Quel type d'ébergement pouvons nous retenir?
Pour info, nous pensons héberger la base de données sur notre propre serveur, le serveur web fera des accès distants sur notre serveur... De ce fait, nous n'avons pas besoin d'espace de stockage, uniquement de bande passante...
Existe-t-il des mutualisés qui pourraient accepter de tels trafics???

Nota: je ne raisonne que sur la consommation que va nous engendrer GOOGLE, sachant que les volumes supposés consommés par les visiteurs 'humains' seront de l'ordre de 150 Mo par jour.

Merci pour vos conseils

 

[e-kiwi]

>> mais de notre coté, ça risque de coincer coté hébergement...

pas du tout, coté heberement, le site fera le poid du code php, c est a dire de l ordre de quelques megas, sauf si vous utilisez un systeme de cache

>> si on moyenne la taille des pages à 70Ko
il va falloir optimiser qd meme. 70ko la page pour un catalogue, ca n'a pas l'air super bien codé

>> Existe-t-il des mutualisés qui pourraient accepter de tels trafics???
il n y a pas de limite définie en traffic ou ressource coté hebergeur. le gros probleme est la consomation de ressources. un site peut faire 1000 visites jour et occuper 20% des ressources du serveur, alors qu'un site peut avoir 10 000 visites / jour et occuper 1% des ressources. tout depend du codage du catalogue. donc pour alleger votre site, il faut utiliser un systeme de cache. et là revient le probleme de l espace hebergeur. il faudra effectivement plus de place. (quel dilem

déjà optimisez votre site, on trouve des catalogues dont le spages ne font pas plus de 15ko

>> Pour info, nous pensons héberger la base de données sur notre propre serveur, le serveur web fera des accès distants sur notre serveur...

pourquoi ne pas heberger la totalité sur votre serveur dans ce cas là ?? quel interet d heberger la BDD et pas le site ?

 

[Madrileño]

>> si on moyenne la taille des pages à 70Ko
il va falloir optimiser qd meme. 70ko la page pour un catalogue, ca n'a pas l'air super bien codé

Sauf s' il compte les Images peut être :lol:

 

[OJAL]

Oui, en effet je compte les images... la page entière en effet, avec bandeau etc...
Je ne vois pas comment on pourra diminuer la taille... les fiches sont assez complexes et riches en contenu...

 

[e-kiwi]

reste les autres questions : utilisez vous un systeme de cache pour que les pages soient générées en statique ? pourquoi utilisez vous un serveur (qui n'a apparemment aps de limite vu que c est le votre) pour la BDD et un autre pour le spages du site ?

 

[e-kiwi]

>> si on moyenne la taille des pages à 70Ko
il va falloir optimiser qd meme. 70ko la page pour un catalogue, ca n'a pas l'air super bien codé

Sauf s' il compte les Images peut être :lol:

donc si il y a 150 000 pages, tu compte 150 000 fois le meme bandeau haut qui prend la place qu'une fois et 150000 fois les memes images ddu menu présente une seule fois ?

kiwi +1

quant à une image d un catalogue, ca fait 10ko, reste donc 60 ko pour le code, ca fait beaucoup

 

[OJAL]

Notre soucis ne concerne absolument pas l'espace disque chez l'hébergeur, ni les ressources puisque la BDD sera hébergée sur un autre serveur, mais concerne les volumes de données qui vont transiter....
Ce qui me fait penser qu'un hébergeur mutualisé classique risque de nous jeter...

Nous ne voulons pas utiliser notre serveur dédié pour des raisons d'optimisation du référencement... Ce point a déjà été abordé par ailleurs me semble-t-il... On ne souhaite surtout pas mettre tous nos sites sur le même serveur ou la même tranche d'IP...

 

[OJAL]

donc si il y a 150 000 pages, tu compte 150 000 fois le meme bandeau haut qui prend la place qu'une fois et 150000 fois les memes images ddu menu présente une seule fois ?

kiwi +1

quant à une image d un catalogue, ca fait 10ko, reste donc 60 ko pour le code, ca fait beaucoup

Oui, en effet, sui GOOGLE nous indexe 100.000 pages, il va bien charger 100.000 fois le même bandeau non??... je ne vois pas d'autre solution...

Quand au catalogue, on a souvent plusieurs image sur la même fiche....

J'ai peut être exagéré sur une moyenne à 70 Ko, mais en tous cas pas moins de 50 Ko...

 

[yanhl]

google se fiche des images, et tu peux mettre un disallow sur le dossier d'images dans ton robots.txt
Je ne sais pas trop comment tu te représentes le fonctionnement de ton site, mais dis-toi que Google c'est qu'un visiteur très actif, rien de plus. Il ne va pas tout indexer le même jour, peut-être même jamais *tout* indexer.
Ensuite si tu fais un référencement, c'est pour augmenter ton traffic. Donc tes 150 mégas actuels ne sont probablement qu'une petite partie de ton traffic à venir.

En tout cas, l'idée de mettre la BD sur un serveur à vous ne me parait pas terrible. Pourquoi, dans ce cas, ne pas vous charger de tout l'hébergement ? Parce que si le contenu est très important comparé au HTML (en terme de poids), vous aurez quasiment autant de BP de consommée pour envoyer les résultats des requêtes. De plus, ça consomme bien plus de bande passante qu'une page HTML compressée en gzip.

Et puis s'il y a 5 requètes SQL par pages, ça fait 5 interrogations de la base via le net : c'est plus lent que de les traiter en local.

En somme, je me demande bien pourquoi vous comptez mettre en place une telle structure, vu que vous allez avoir un site ralentit et une consommation de bande passante plus importante...

 

[OJAL]

Salut yanhl,

Nous avons défini une architecture avec une base de donnée centralisée pour des raisons bien précises. Plusieurs sites viendrons puiser leurs informations sur cette base de données et tous ces sites ne seront surement pas sur notre serveur dédié...

Cette notion de serveur centralisé ne peut pas être remise en question...

 

[OJAL]

Je vais reposer ma question différemment...
Sur un hébergement mutualisé, quel volume de données pouvons nous espérer fournir par jour :?:
Je crois qu'il y a aussi des limitations en nb de hits ou requêtes, mais qu'est exactement que ces hits ou requêtes :?:

 

[yanhl]

Un exemple d'hébergeur : http://www.ovh.com/fr/mutualise/
OVH ne compte pas le volume de données mais le nombre de hits. Egalement le nombre de connexions simultanées à une bdd mais que si elle est chez eux, donc ça ne te concerne pas.
Un hit c'est un appel à un fichier : une page, une image, un fichier css...
Si tu fais une page avec deux images, un appel à cette page "consomme" trois hits.

Ce que tu me dis concernant ton infrastructure ne change rien à la donne : pourquoi ne pas avoir plusieurs serveurs chez vous dans ce cas ? Ils pourraient tout aussi bien faire appel à une même bdd ?
Ce qui implique une seconde question : pourquoi voulez-vous éviter d'avoir plusieurs serveurs sur une même tranche d'IP ?

 

[OJAL]

Un exemple d'hébergeur : http://www.ovh.com/fr/mutualise/
OVH ne compte pas le volume de données mais le nombre de hits. Egalement le nombre de connexions simultanées à une bdd mais que si elle est chez eux, donc ça ne te concerne pas.

Pour la pette histoire, nous avions réalisé la maquette de ce site sur un tout petit hébergement mutu OVH.. tout allait bien jisqu'au jour ou OVH a décidé arbitrairement de nous interdire les accés à notre BDD MySQL externe à leur réseau...
Après longues discussion auour de soit disant problèmes de sécurité qui se sont rébélés faux, ils font la sourde oreille et ne donnent plus signe de vie...
Ils ne sont pas OK pour nous rembourser et ont même changé des pages de leur site pour nous montrer que les accs de ce type MySQL étaient interdits... Malheureusement pour eux, le cache de GOOGLE avit encore en mémoire leus ancien contenu... Enfin en 2 mots lamentable...
Ils basculent les grosses BDD sur un serveur qui rame pour décourager les grosses BDD.... enfin voila le tableau de OVH....

 

[OJAL]

Ce que tu me dis concernant ton infrastructure ne change rien à la donne : pourquoi ne pas avoir plusieurs serveurs chez vous dans ce cas ? Ils pourraient tout aussi bien faire appel à une même bdd ?
Ce qui implique une seconde question : pourquoi voulez-vous éviter d'avoir plusieurs serveurs sur une même tranche d'IP ?

Il vaut mieux donner l'impression à GOOGLE que nos sites n'ont aucun liens entre eux (hormis quelques backlinks ) et donc être sur des IP différentes...

Hormis cela, d'autres webmasters pourront venir construire leur propre sites en puisant dans notre BDD de contenu et on ne va pas héberger tous nos partenaires...

 

[yanhl]

Et euh... t'as rien de confidentiel dans ta bdd ? Tu donnes l'accès à ta base comme ça ?

En ce qui concerne OVH, je connais le problème de limitation de taille de bdd et les serveurs pourris quand on a une base trop grosse, c'est d'ailleurs ce qui m'a poussé à prendre un dédié. Concernant l'accès aux bases externes, je ne connaissais pas cette limitation de leur part.

"Malheureusement pour eux, le cache de GOOGLE avit encore en mémoire leus ancien contenu"
J'ai rien compris à cette phrase. Ok c'était dans le cache, et alors ?

En ce qui concerne le "donner l'impression à GOOGLE que nos sites n'ont aucun liens entre eux", je crois que tu rêves un peu. Ou bien il va voir le duplicate content ou bien il ne le verra pas, mais à part ça...
Et puis qu'est-ce qu'il se passera si l'un de tes partenaires prend un mutu chez le même hébergeur que toi, avec une même tranche d'IP ?

 

[OJAL]

"Malheureusement pour eux, le cache de GOOGLE avit encore en mémoire leur ancien contenu"
J'ai rien compris à cette phrase. Ok c'était dans le cache, et alors ?

OVH a modifié une page de son site uniquement pour nous montrer que ce que nous souhaitions faire était interdit (accès à notre BDD externe à leur réseau). Et le cache GOOGLE montrait clairement que l'ajout venait juste d'être fraichement fait par OVH...

 

[yanhl]

ah ouais, pas cool. :-/

 

[OJAL]

En ce qui concerne le "donner l'impression à GOOGLE que nos sites n'ont aucun liens entre eux", je crois que tu rêves un peu.

Hors sujet de cette discussion, mais nous sommes convaincus de l'intérêt d'être sur plusieurs hébergements... Par exemple pour être bien référencé en allemagne, si tu n'es pas sur un serveur allemand, tu auras du mal.... Ce n'est qu'un exemple....

 

[mahefarivony]

quel hebergeur pour 150Mo par jour? euh, n'importe quel hebergeur fera l'affaire je pense

 

[yanhl]

oui ok, dans le cas d'un site au contenu localisé, l'intérêt est évident.
reste le problème de l'ouverture de la base. Pourquoi ne pas faire des webservices par exemple ? Dans ce cas, OVH n'y trouverait rien à redire. Et peu importe l'emplacement du serveur qui s'en occupera (euh.. dans vos locaux par exemple ;-) )
Au niveau de la sécurité, ça me parait mieux. A moins que tu connaisses de très bon mécanismes de protection des données fournis par la base que tu utilises, un accès aux bases complet voudrait dire que si un partenaire fait un delete from une_table_a_laquelle_il_a_acces, t'es mal. Idem s'il se fait hacker, ou s'il a des failles permettant des injections SQL. Enfin bon, j'imagine que t'as réfléchi à la question, mais sait-on jamais...

Sinon comme hébergeurs tu as Amen (que personnellement je n'aime pas, pour différentes raisons et sans même l'avoir testé personnellement), Sivit...

 

[e-kiwi]

>>Oui, en effet, sui GOOGLE nous indexe 100.000 pages, il va bien charger
>> 100.000 fois le même bandeau non??... je ne vois pas d'autre solution...

google ne va pas stocker votre bandeau. je vois pas en quoi le fait d avoir 300 000 pages va multiplier le poid d un bandeau par 300 000. il y a du avoir une mauvaise formulation ^^

 

[OJAL]

>>Oui, en effet, sui GOOGLE nous indexe 100.000 pages, il va bien charger
>> 100.000 fois le même bandeau non??... je ne vois pas d'autre solution...

google ne va pas stocker votre bandeau. je vois pas en quoi le fait d avoir 300 000 pages va multiplier le poid d un bandeau par 300 000. il y a du avoir une mauvaise formulation ^^

SI notre bandeau fait 10Ko, si GOOGLE indexe 100.000 pages, il aura bien généré en volume de données transférées rien que pour le bandeau 100.000*10= 1Go de données...

 

[yanhl]

je t'ai répondu dans ma première réponse à ce sujet :

google se fiche des images, et tu peux mettre un disallow sur le dossier d'images dans ton robots.txt

Quand google indexe les pages, il le fait en ne se basant que sur le HTML de la page, sans se préoccuper des fichiers "média"

 

[mahefarivony]

SI notre bandeau fait 10Ko, si GOOGLE indexe 100.000 pages, il aura bien généré en volume de données transférées rien que pour le bandeau 100.000*10= 1Go de données...

100.000*10 = 0 Ko effectivement...