Journal Get the Facts : serveurs Web ; Apache/Linux loin devant IIS/Windows pour la disponibilité

Posté par  (site web personnel) .
Étiquettes : aucune
0
22
juin
2007
ZDNet.fr a publié un commentaire d'une étude de la société néerlandaise WatchMouse dans un article intitulé « Serveurs Web : Apache/Linux loin devant IIS/Windows pour la disponibilité ». D'après l'article WatchMouse s'est basé sur un panel de 1 500 site Web, répartis sur 28 thématiques et 5 pays européens, qui ont été testés pendant un mois. L'indice de performance se base sur le temps de chargement de la page d'accueil et de la disponibilité du site pendant le mois écoulé. Plus cet indice est est élevé, plus l'expérience de l'utilisateur est dégradée. Les sites sous des serveurs Linux/Apache obtiennent un score de 799 points alors que ceux sur Windows/IIS totalisent 1079 points, soit une différence de performance de l'ordre de 25%
Nos recherches ont démontré que les internautes sont de plus en plus impatients et n'attendront pas plus de quatre secondes pour charger une page Web », indique Mark Pors, directeur technique de WatchMouse. « Les entreprises ayant des sites Web doivent donc mieux mesurer l'importance de réaliser le meilleur choix quant à leur plate-forme de serveurs Web.

http://www.zdnet.fr/actualites/internet/0,39020774,39370586,(...)
  • # Avocat du diable

    Posté par  . Évalué à 5.

    Le problème, c'est qu'on a aucun détails sur les plates-formes (alims redondantes et mémoire ECC pour la fiabilité, par exemple, matériel réseau pour les performances), ou même sur les installs. Par exemple, il y a une certaine différence entre Apache 1 basé sur les process, et Apache 2, basés sur les threads.

    Et toujours le bon morceau de troll commun à tous mes postes, j'aimerais bien voir le score de disponibilité d'une plate-forme OpenBSD/Apache 1 :°
    • [^] # Re: Avocat du diable

      Posté par  . Évalué à 2.

      > Et toujours le bon morceau de troll commun à tous mes postes, j'aimerais bien voir le score de disponibilité d'une plate-forme OpenBSD/Apache 1 :°

      Dans l'industrie, il y a des PC sous MS-DOS avec des uptimes délirants (ça se compte en années...).
      • [^] # Re: Avocat du diable

        Posté par  . Évalué à 6.

        Oui, même que chez nous, on a même peur de rebooter la machine (1998 sans reboot). évidemment, pas de sauvegarde, et la prod ne peux pas s'arrêter)

        J'en fais des cauchemars toutes les nuits.
        • [^] # Re: Avocat du diable

          Posté par  . Évalué à 2.

          comment vous faites pour changer les batteries de l'onduleur (tous les 3 ~ 4 ans) sans couper le jus ?
          • [^] # Re: Avocat du diable

            Posté par  . Évalué à 2.

            un onduleur ? c'est quoi ca ? ca existait en 1998 ?
          • [^] # Re: Avocat du diable

            Posté par  (site web personnel) . Évalué à 5.

            L'onduleur software a dû être porté sous MS-DOS...
          • [^] # Re: Avocat du diable

            Posté par  . Évalué à 2.

            ce sont les batteries d'origine /o\

            il faut comprendre, que dans le contexte industriel où je travaille, l'informatique n'est vraiment pas une préoccupation.

            Je sais, c'est mal. Mais les lignes sont en cours de rénovation. et on vire les PC
    • [^] # Re: Avocat du diable

      Posté par  . Évalué à 1.

      Et toujours le bon morceau de troll commun à tous mes postes, j'aimerais bien voir le score de disponibilité d'une plate-forme OpenBSD/Apache 1 :°


      Et bien, 100%, modulo un reboot tout les 6 mois pour mettre à jour vers la nouvelle version.. en supposant qu'il n'y ait pas eu d'autres fixs de sécurité nécessitant un autre reboot :)
    • [^] # Re: Avocat du diable

      Posté par  . Évalué à 2.

      Le problème, c'est qu'on a aucun détails sur les plates-formes


      C'est pour cela qu'ils ont calculé leur indice sur un panel de sites ; en en prenant un suffisamment large, ça doit gommer statistiquement les effets des différences de configuration (en moyenne, les serveurs IIS ont sans doute une configuration similaire à celle des serveurs apache), pour ne garder que celles dues aux logiciels.
      C'est la différence entre les statistiques et les benchmarks.
  • # C'est les mêmes site...?

    Posté par  . Évalué à 6.

    C'est les mêmes sites qui tournait sous "deux server" distinct...?

    ça ne veux vraiment rien dire cette étude, du moins les infos
    que l'on a !

    Parceque par exemple, on pourrait croire que les gens qui font
    du windows/IIS pour leur servers web font des grosse plate-forme
    ASP/.NET/tralala et que beaucoup de server apache c'est juste
    du fichier ou au pire Perl/php/MySQL/tralala.

    Ou même que les applis web sous Unix/apache sont mieux
    prévu du fait que c'est generalement les kikoolol qui utilisent
    les logiciels clickaclick de chez Redmond, etc etc...

    Bref, du flan de chez Zdnet...
    • [^] # Re: C'est les mêmes site...?

      Posté par  . Évalué à 1.

      C'est vrai que leur étude manque un peu de précision sur le type de site (simple forum ou applis web complex).

      Quand c'est du IIS, on est certains que .NET tourne, mais quelle version du framework ?
      J'imagine qu'entre .NET 1.1 et .NET 2.0, les performances du même site change.

      Pour Apache, il faut aussi voir qu'il peut rediriger vers un serveur d'appli comme Tomcat pour un site Java/JSP/J2EE.
      Les temps de réponse, les performances et le matériel sont différents d'un simple site PHP pour un blog.


      Je trouve que ce n'est pas très pro ce genre d'étude.
      • [^] # Re: C'est les mêmes site...?

        Posté par  . Évalué à 5.

        J'imagine qu'entre .NET 1.1 et .NET 2.0, les performances du même site change.

        Oui, d'expérience, ça se dégrade.
      • [^] # Re: C'est les mêmes site...?

        Posté par  . Évalué à 3.

        > Je trouve que ce n'est pas très pro ce genre d'étude.

        Au contraire, je la trouve très pro cette étude.
        Elle est comme la plus part des autres.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.