Journal Un module apache pour accélérer le net par google (inc)

Posté par  (site web personnel) .
Étiquettes : aucune
10
5
nov.
2010
Je m’attendais à voir passer cette nouvelle ici, mais non (ou je l’ai loupée…), alors je m’y colle.
J’ai vu passer cette information ici : [http://www.zorgloob.com/2010/11/03/google-apache-mod_pagespe(...)] (il y a même un jolie vidéo, alors…).
Comme je n’y connais pas grand chose, je ne vais pas beaucoup développer (du tout, en fait) mais il semble que le but soit d’optimiser un certain nombres de points qui ralentissent l’affichage des pages. Le gain annoncé est de 50% (pile poil !).

Si d’aucun a déjà fait des tests, je suis curieux de leurs avis.

  • # Les tests sont dans ton lien

    Posté par  . Évalué à 8.

    Et ils indiquent un premier hébergeur qui l'a enlevé aussitôt mis : la charge serveur avait trop augmenté, les sites devenaient inaccessibles.

    Il faudra rajouter dans ce module un test de puissance CPU pour le rendre inactif si le serveur n'en peut plus ;-)

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

  • # Un module Apache HTTPD pour accélérer le *web*

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

    Ça se saurait, si optimiser Apache accélérait Internet…

  • # il fait des petites optimisations

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

    Il n'y a rien de nouveau dans ce que fait ce module. La seule nouveauté c'est qu'il le fait à votre place et au vol - et ça bouffe du cpu, c'est normal. Il est en fait présenté comme un outil de développement, afin de voir tout ce qui peut-être optimisé sur le site.
    Ceux qui ont connu le web des années 19,6 - 28.8 - 33.6 - 56 et même 2 x 56 ne seront pas surpris parce qu'à l'époque on optimisait tout:
    on réduisait la palette des images indexées pour avoir une meilleure compression, on recompressait les JPEG par zones, on retaillait les images au plus juste, on enlevait tout le code inutile, les espaces, les retours chariots, on réécrivait les variables Javascript pour avoir des pages plus légères (passer de "ma_variable_nommée_truc_qui_fait_ça" à "zk" ça économise 33 octets avec un codage de caractères sur 8 bits), etc.
    On grattait.
    C'est exactement ce que fait ce module:
    - il combine plusieurs en-têtes (head) entre eux;
    - il déplace les CSS et Javascripts dans des fichiers externes (le navigateur les met en cache);
    - il combine les multiples CSS entre elles;
    - il révise le code CSS, JS et HTML: retire espaces, commentaires et attributs inutiles, ajoute des trucs manquants;
    - il optimise les images, les retaille, les recompresse et fait un truc que je ne suis pas sûr d'avoir compris avec les plus petites ("inlining images"). Si une bonne âme peut m'expliquer...
    - et quelques autres petites choses pas inutiles.

    "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

    • [^] # Re: il fait des petites optimisations

      Posté par  . Évalué à 4.

      ben je comprends pas... on nous explique depuis 5 ans que toutes ces opérations sont inutiles, que la place disque est presque gratuite et que les gens sont en adsl 800 GB, qu'il n'est pas nécessaire de perdre son temps à optimiser un fois à la création et là on pond un module apache qui fait cette opération à chaque fois ?

      • [^] # Re: il fait des petites optimisations

        Posté par  . Évalué à 10.

        C'est parce que ceux qui disent ça sont effectivement en ADSL 800Gb, pas forcément ceux qui consultent les sites.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: il fait des petites optimisations

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

        Oui, mais c'est plus vraiment pour accélérer le côté client, mais le côté serveur. Quand tu es le site le plus visité au monde, tu souhaites envoyer ta page au plus vite afin de pouvoir servir un autre client.

        Regardes le code source de la page d'accueil de google, illisible mais il y'a le strict nécessaire pour que ton client fasse le minimum de requêtes et que le serveur google passe le minimum de temps à te répondre.

        "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

      • [^] # Re: il fait des petites optimisations

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

        C'était effectivement le cas il y a quelques années, mais depuis les sites web ont évolués. Globalement, ils font appel à de plus en plus de ressources séparées (feuilles de styles, beaucoup de javascript, images, polices, etc.), or multiplier les requêtes HTTP ralentit le temps de chargement des pages.

        Pire, l'augmentation de la bande passante a un effet quasi négligeable sur le temps de chargement (pour les gens qui ont au moins une connexion ADSL). En gros, passer de 10 Mbits à 20 Mbits ne va pas aider à afficher plus rapidement les pages web car le problème est principalement une question de latence (résolution DNS, ouverture de sessions TCP, éventuellement SSL, attendre d'avoir parsé le HTML pour savoir quelles ressources télécharger, etc.). Au final, malgré les progrès techniques, les pages web s'affichent moins rapidement aujourd'hui qu'il y a 2 ou 3 ans en moyenne.

        Et cela ne devrait pas aller en s'améliorant. Les sites web utilisent de plus en plus de ressources externes (trucs de facebook, google analytics, embed youtube, boutons "share this", commentaires gérés par des services externes comme disqus, etc.), ce qui multiplie les risques qu'une page se charge lentement.

        D'un autre coté, le temps de chargement des pages est de plus en plus mis en avant : Amazon a publié des études qui montrent qu'un temps de chargement un peu plus long (genre 100ms de plus) provoquent des chutes vertigineuses dans les ventes (10 à 30%), Google tient compte du temps de chargement des pages pour son indexation.

        On voit donc se généraliser des techniques pour optimiser le temps de chargement des pages : minification des CSS et JS, regrouper plusieurs fichiers dans un seul, le retour des sprites CSS, le préchargement de ressources, etc. La promesse du mod apache de Google est de faire ça automagiquement , à grande échelle, sur des sites existants pour lesquels ces opérations ne seraient pas faites autrement.

    • [^] # Re: il fait des petites optimisations

      Posté par  . Évalué à 5.

      fait un truc que je ne suis pas sûr d'avoir compris avec les plus petites ("inlining images"). Si une bonne âme peut m'expliquer...
      Il encode l'image en base64 et l'inclut directement dans la page Web au lieu de la servir dans un fichier séparé.


      Où le gros bruit à la fin c'est le fichier image codé en base64.

      Ça permet d'avoir une seule requête (pour la page) plutôt qu'une requête page + une requête image.

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: il fait des petites optimisations

        Posté par  . Évalué à 2.

        Et forcément, l'exemple ne passe pas >_<

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: il fait des petites optimisations

        Posté par  . Évalué à 4.

        Le base64, ça ne nécessite pas 33% d'octets en plus ?

        • [^] # Re: il fait des petites optimisations

          Posté par  . Évalué à 6.

          Avec les petites images, ça peut te permettre d'économiser une requête http et l'overhead + le temps d'attente qui va avec. Une autre solution ce sont les sprites css.

          • [^] # Re: il fait des petites optimisations

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

            Oui les sprites css sont très intéressant quand la page contient plein de petites icônes, ou lorsque le visiteur va sur plusieurs pages. En combinant toutes ces petites images en une seule on ne fait plus qu'une seule requête, et en plus c'est efficacement mis en cache.
            Les images map (ismap) pour les menus pourraient être plus employées aussi.

            "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # Mouais...

    Posté par  . Évalué à 2.

    C'est vraiment pas la solution que je prendrais. Là, ils rajoutent un cache au niveau du serveur (donc conso mémoire), et doivent calculer le hash des resources à cacher à intervalle régulier (donc conso cpu).

    La solution la plus simple, et déjà relativement répandue auprès des personnes ayant ce type de problèmatique, consiste simplement à mettre un timestamp sur le nom des resources ; quand on redéploie, on change donc de nom, et le client sait qu'il ne doit plus utiliser sa version locale.

    Bon, après nul doute que ça peut être utile pour des hébergeurs pour Madames Michu.

  • # Précision

    Posté par  . Évalué à 3.

    Attention, ça ne marche qu'avec un processeur Intel Pentium.

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # La roue

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

    Il n'y avait déjà templeet qui faisait ça ?

    L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

  • # Gogos

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

    C'est typiquement pour les "gogos".

    J'ai essayé sur un prestashop, typiquement un bon candidat. Niet. Pas de gain.

    En plus, ça fait pas le plus important, concaténer les fichiers JS (ça se multiplie vite ces bêtes là, regarder prestashop).

    Refaire le même boulot à chaque requête, c'est quand même balot. C'est le genre de truc qui m'oppresse. Ok il y a un cache pour la minification des css et des js, l'optimisation des images. Mais, le HTML est attaqué à chaque requête.

    Alors il y a deux choix, faire les optimisations une bonne fois pour toute, ou bien les faire à chaque requête et bouffer du CPU.

  • # test sur une Ubuntu hébergée sur une dedibox

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

    j'avais une dedibox sous Ubuntu 8.04 LTS avec quelques sites personnels et j'ai fait le test d'installer le module Apache. Bingo, le premier site testé en spip ne fonctionne plus, je cherche un peu et je me dis que je vais retirer le module et regarder un peu mes configs. Sur cette Ubuntu 8.04, pas de module apache deflate installé alors je me dis que même avec le 100 Mbits/sec de bande passante de la dedibox, je vais l'activer et là, il y a une réelle amélioration de performance sur l'affichage de tous les sites (HTML pur et aussi SPIP avec ou sans compression des entêtes). C'est tout à fait étrange que cette Ubuntu 8.04 n'active pas la compression par défault (c'est activé sur Centos 5.5) et c'est tout aussi étrange que cela accélère autant les sites.
    Bon, il reste à retester le module Google et comprendre ce qui cloche.

Suivre le flux des commentaires

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