IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Performance Web Discussion :

Informations sur la BP moyenne d'un site Web


Sujet :

Performance Web

  1. #1
    Invité
    Invité(e)
    Par défaut Informations sur la BP moyenne d'un site Web
    Bonjour,

    Je cherche actuellement des informations sur la bande passante moyenne et exceptionnelle (pics) que requièrent des applications web de type forum ou portail communautaire. Avec si possible le nombre de visites mensuelles et la taille moyenne des pages. Si vous connaissez un endroit où je puisse récupérer des courbes de suivi de la bande passante et de fréquentation, je suis preneur. Que ce soit pour de vrais sites web (hors géants type Google, Amazon, Facebook, eBay, Yahoo...) ou des moyennes plus ou moins théoriques issus d'un travail de recherche récent.

    Ce que je ne cherche pas :
    - un outil pour mesurer la bande passante de mon application web
    - le débit moyen fourni par des FAH ou des hébergeurs comme OVH

    Merci.

  2. #2
    Membre éclairé

    Profil pro
    Inscrit en
    Février 2010
    Messages
    119
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2010
    Messages : 119
    Points : 777
    Points
    777
    Par défaut
    Salut
    la bande passante est à peu près le croisement du poids des pages avec le nombre de visites.

    Concernant le poids, tu peux avoir des infos génériques ici : http://httparchive.org/websites.php
    Ce sont des stats globales mais si tu connais le nom des sites concurrents tu peux les retrouver dans la partie sites et faire la moyenne toi même
    Sauf si tu gères plusieurs dizaines de forums (en étant hébergeur par exemple), je ne vais pas t'apprendre qu'une moyenne ne sert à peu près à rien car ton cas aura des particularités.

    Concernant la fréquentation de ces sites, je ne suis pas sur que ce genre de stat existe de manière très publique

  3. #3
    Invité
    Invité(e)
    Par défaut
    Bonjour,

    Merci pour ce site, que je ne connaissais pas.

    J'ai en effet pu lire dans maints tutoriels et fils de discussions qu'il suffit de rapporter le volume total de données transférées au temps sur lequel ces données ont été transférées.

    Mais ce calcul est beaucoup trop simpliste :
    • Il ne dit rien sur la manière de calculer le volume de données transférées du serveur vers les clients (visiteurs) : les systèmes de cache ou de compression des données IP mettent en échec le calcul qui consiste à multiplier entre eux le nombre de visites, le nombre de pages vues en moyenne par visite et la taille moyenne des pages.

    • Il considère que la fréquentation du site est constante au cours du temps, ce qui n'est jamais le cas : tout l'enjeu est justement de connaitre les valeurs de pics atteignables au regard de la nature d'un site (très graphique ou pas du tout, Flash, applet Java, contrôles Active X, forum, événementiel, etc...) et de sa fréquentation.


    Je demande peut-être quelque chose qui n'existe pas de manière publique sur le web, mais étant donné que des milliers voire des millions de webmasters, d'hébergeurs, de DSI... de part le monde se penchent sur ce genre de stats chaque jour, on est en droit de penser que des chiffres sont disponibles sur la toile.
    Le tout est de savoir où. J'ai fouillé sans succès. D'où ma question.

    Merci encore.

  4. #4
    Membre éclairé

    Profil pro
    Inscrit en
    Février 2010
    Messages
    119
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2010
    Messages : 119
    Points : 777
    Points
    777
    Par défaut
    prévoir un pic, c'est très dur, le site moyen ne peut pas vraiment le faire "à priori", et tu es obligé de surdimensioner au pifomètre ta plateforme. Ceux qui y arrivent très bien par exemple ce sont les sites de news : quand il y a un événement du genre mort de Mickael Jackson ou affaire DSK, leur trafic est multiplié par 10, et pourtant ils ne payent pas tout au long de l'année une plateforme 10 fois trop grosse, car les rédactions Web n'ont finalement que très peu de budget.
    Il y a quelques années de ça, ils ne tenaient pas du tout la charge pendant les événements exceptionnels, comment ils s'en sont sorti ?
    Bêtement de manière empirique en voyant leurs sites s'écrouler de temps en temps et en perdant de l'argent, ils ont accumulé de l'expérience et ont vu ce qui craquait en premier, et ils ont fini par payer des CDN qui eux savent absorber les grosses charges
    Pas glorieux, mais quand tu as un manque de budget, il faut faire avec

    concernant le calcul, il est impossible de prendre en compte tous les équipements réseau entre tes utilisateurs et tes serveurs et je ne suis pas sur que ça soit important. A part multiplier le poids de ta page moyenne (que tu peux obtenir avec ySlow, webpagetest.org et plein d'autres) par le nombre de pages vues (informations business difficile à trouver) et tu auras une fourchette haute.

  5. #5
    Membre émérite
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 448
    Points : 2 284
    Points
    2 284
    Par défaut
    Citation Envoyé par jpvincent Voir le message
    prévoir un pic, c'est très dur, le site moyen ne peut pas vraiment le faire "à priori", et tu es obligé de surdimensioner au pifomètre ta plateforme. Ceux qui y arrivent très bien par exemple ce sont les sites de news : quand il y a un événement du genre mort de Mickael Jackson ou affaire DSK, leur trafic est multiplié par 10, et pourtant ils ne payent pas tout au long de l'année une plateforme 10 fois trop grosse, car les rédactions Web n'ont finalement que très peu de budget.
    Il y a quelques années de ça, ils ne tenaient pas du tout la charge pendant les événements exceptionnels, comment ils s'en sont sorti ?
    Bêtement de manière empirique en voyant leurs sites s'écrouler de temps en temps et en perdant de l'argent, ils ont accumulé de l'expérience et ont vu ce qui craquait en premier, et ils ont fini par payer des CDN qui eux savent absorber les grosses charges
    Pas glorieux, mais quand tu as un manque de budget, il faut faire avec
    <hs>
    C'est un peu rude ce que tu dis.
    Je ne vois pas ce qu'il y à de plus glorieux à mettre 50 frontaux qui ne sont pleinement utilisé qu'une fois dans l'année.
    De la même manière qu'apprendre de son expérience est un processus que l'on à tous fait, et c'est plutôt un signe d'intelligence.
    Autrement, le cloud sa existe c'est un peu là pour répondre à ce problème de charge inopiné, et oui c'est mieux que de sur dimensionner sa plate forme.
    </hs>

    Voilà, désolé, d'empiéter sur votre discussion =)
    Par ailleurs, je ne comprend pas l'utilité d'être aussi précis dans ton calcul kéraunos, puisque de toute façon pour les raisons évoqués par jpvincent, on à tendance à prévoir une fourchette haute.

    <hs2>
    Après la BP, personnellement, en tant que dev, sa me fait un peu rire.
    C'est plus un critère de facturation qu'un gage d'assurance que ton site va tenir la charge.
    Si tu prend un site de dl, il aura une utilisation de la BP bien plus importante que n'importe blog avec le même nombre d'utilisateurs.
    </hs2>
    Fin voila, juste pour dire que je ne saisit pas bien l'objet de ta recherche, mais que je reste curieux !

    a+

  6. #6
    Invité
    Invité(e)
    Par défaut
    Merci pour vos contributions à la discussion.

    Kaymak : on me demande de réaliser une étude sur l'hébergement d'une future plateforme SaaS (dont pas une ligne de code n'existe aujourd'hui), avec comme données en entrées des hypothèses sur le nombre de visites et sur la taille des contenus. Et cette étude contient un volet qui, justement, traite de la facturation de la BP. N'étant ni spécialiste des architectures web ou des réseaux, ni commercial chez un hébergeur, j'ai bien du mal.

    Au demeurant, se préoccuper des pics n'est pas seulement important du point de vue facturation. En fait, tout dépend du niveau de qualité de service à fournir et de la criticité des données. Dans certains cas, la disponibilité est cruciale pour éviter de perdre des marchés. Surtout pour une PME dont les concurrents se bousculent.

    Jpvincent : tu vois, ce que tu me dis dans ton dernier message, c'est typiquement le genre d'infos que je recherche. Sauf qu'en l'occurrence c'était une version qualitative, or il me faudrait des chiffres sur lesquels baser mes propres hypothèses.

    Merci.

  7. #7
    Membre émérite
    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    1 448
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Janvier 2007
    Messages : 1 448
    Points : 2 284
    Points
    2 284
    Par défaut
    on me demande de réaliser une étude sur l'hébergement d'une future plateforme SaaS (dont pas une ligne de code n'existe aujourd'hui), avec comme données en entrées des hypothèses sur le nombre de visites et sur la taille des contenus. Et cette étude contient un volet qui, justement, traite de la facturation de la BP. N'étant ni spécialiste des architectures web ou des réseaux, ni commercial chez un hébergeur, j'ai bien du mal.
    Ah oui c'est coton. Fais simple, et prévoit des tests de montée en charge avant la mise en ligne. Vous verrez bien à ce moment là ce que sa donne.
    Sa se trouve sa va complètement se votrer et il faudra renvoyer l'appli chez les devs (ah oui c'était cool pour eux d'utiliser un ORM, mais qu'est ce que sa consomme =).

    Moi il me semble que la BP facturée, c'est qui part de ton/tes serveurs jusqu'au premier routeur de ton hébergeur qui enregistre ton traffic.
    Mais c'est à confirmer...... :/

    Au demeurant, se préoccuper des pics n'est pas seulement important du point de vue facturation. En fait, tout dépend du niveau de qualité de service à fournir et de la criticité des données. Dans certains cas, la disponibilité est cruciale pour éviter de perdre des marchés. Surtout pour une PME dont les concurrents se bousculent.
    Ce que je voulais dire plus haut, c'est que si tu veux faire du prévisionnel de résistance à la charge il ne faut pas se baser sur les trafics de la BP.

    Le trafic de la BP ne tient pas compte du dimensionnement des serveurs ni de l'appli qui est hébergé, de sa nature, de son comportement face à la charge.

    La BP va te permettre de dire :
    Soit j'ai énormément de client qui télécharge des petits contenus
    Soit j'ai peu de clients qui télécharge d'énormes contenu.
    Je vois pas bien ce que sa apporte.

    a+tard

  8. #8
    Invité
    Invité(e)
    Par défaut
    Oui, d'accord, une mesure prise indépendamment de tout le reste, pour des systèmes aussi complexes que des applications hébergées en mode SaaS, ça n'a pas énormément de sens. D'où l'intérêt de données empiriques.

    Mais bon, supposer que la BP toute seule ne veut rien dire, ça ne m'aide pas beaucoup. Je ne cherche pas de la précision à ±5%, mais des ordres de grandeur.

    Je renvois mes éventuelles lecteurs à mes messages précédents pour éviter de répéter ma demande.

    Merci.

Discussions similaires

  1. ne s'arrête pas sur les points d'arrêt du site web
    Par cortex024 dans le forum Développement Web avec .NET
    Réponses: 5
    Dernier message: 09/09/2011, 16h40
  2. Réponses: 7
    Dernier message: 31/07/2009, 22h18
  3. Réponses: 1
    Dernier message: 30/01/2008, 16h42
  4. Réponses: 13
    Dernier message: 04/10/2007, 19h17
  5. Récupérer des informations sur un site web
    Par JnewB dans le forum Langage
    Réponses: 11
    Dernier message: 08/04/2007, 19h44

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo