A quel moment publier sur son blog pour préserver les performances de son serveur

A quelle heure publier quoi ?

Je vais tenter ici de résumer la politique que je tente de suivre, et pourquoi. Tout d’abord, le but de tout cela est d’offrir aux visiteurs du site une accessibilité maximum, et donc un meilleur temps de réponse pour leurs requêtes, qui passe par une meilleure gestion des ressources au niveau serveur. Pour être plus clair : si vous voulez que votre temps d’affichage complet des pages diminue, il va falloir passer par une meilleure organisation des tâches au cours de la journée.

Pour commencer, voici un graphe d’accès au blog, qui constitue la tâche majoritaire du serveur (j’ai pris une assez longue durée pour avoir des résultats très représentatifs, et j’ai viré les chiffres) :

Comme on peut le voir, la charge maximum se situe entre 11h et 23h. Donc pour être simple, c’est là qu’il faut laisser le serveur traiter les requêtes, et seulement ça. A ce moment, le serveur ne doit avoir rien d’autre à faire.

Or, il se trouve que j’ai à peu près 75% de visiteurs qui viennent de Google, donc on peut considérer (à mon avis) que ces visiteurs ne sont pas sensibles aux nouveau billets. Ces visiteurs viennent d’ailleurs majoritairement sur des billets déjà publiés depuis plusieurs jours, donc ils constituent une base plus ou moins « non influençable » du trafic : c’est Google qui les envoi, et je n’ai pas la possibilité d’en faire venir plus ou moins à telle ou telle heure.

Par contre, à chaque publication de nouveau billet, leur publication sur les réseaux sociaux (majoritairement Twitter) et sur les RSS provoque une montée d’accès de visiteurs récurrents, qui viennent sur le blog pour lire les nouveaux billets.

C’est la raison pour laquelle je ne conseille pas de publier les billets en même temps que la charge maximum du blog : on surchargerait un peu inutilement le serveur, alors que celui-ci n’en a pas forcément les capacités. L’idée est donc de répartir les accès, et comme on peut paramétrer l’heure a laquelle on publie des nouveaux billets, autant le faire pour que ça n’influence pas (dans le mauvais sens) les performances du blog.

Pour venir compliquer le tout, il faut savoir qu’il y a une certaine inertie : quand je publie un nouveau billet, tous les visiteurs récurrents ne viennent pas tout de suite (j’estime à environ 3 heures la durée sur laquelle ceux-ci arrivent), et donc il faut également prévoir cela dans sa réflexion sur l’heure de publication.

Enfin, les lecteurs ne sont pas devant leur Twitter ou leur lecteur RSS 24h/24, donc la publication d’un billet à telle heure aura plus d’impact qu’à telle autre heure (pour être plus clair : il vaut mieux publier à 9h qu’à 2h du matin).

Au vu de tout cela, je préconise (si tant est que j’ai une once de légitimité à le faire) de publier entre 8h et 10h, ce pour éviter de surcharger le serveur, tout en maximisant es chances d’être « retweeté » sur Twitter (ou repris sur d’autres réseaux sociaux).

Pour le reste, et pour tout ce qui concerne le travail non visible du serveur (tâche Cron par exemple), j’ai l’habitude de les faire exécuter entre 1h du matin et 5h du matin, heures ou franchement, il n’y a pas grand monde, et où l’impact sur les performances du serveur est négligeable.

7 réflexions sur « A quel moment publier sur son blog pour préserver les performances de son serveur »

  1. avec la puissance des processeurs tu crois vraiment que publier un article a une certaine heure peut influencer ton serveur ?

    je ne sais pas combien de visite tu reçois simultanément mais même si le nombre de visites double ton serveur ne supporterais pas ?

    RépondreRépondre
  2. @lesaintsgeosmois: D’après ce que je sais, c’est pas forcément le processeur qui prend cher, mais plutôt la RAM. En fait (je sais plus où j’ai lu ça, il faudrait que je te le retrouve), 1 ressource = 10 Mo pour Apache. Donc il suffit que tu demandes une page qui contient 10 fichiers (incluant le HTML, le CSS, un ou deux JS, et toutes les images), et tu as tout de suite 100 Mo en mémoire.

    Si je prends mon exemple, pour la page http://www.abricocotier.fr/10189-un-nouveau-design-pour-cdiscount , j’ai calculé qu’elle contenait exactement 34 ressources sur le domaine AbriCoCotier. Donc 34×10 = 340 Mo en mémoire. Mon serveur n’ayant que 2Go de mémoire (si je me souviens bien), tu comprends qu’il suffit de peu de connexions simultanées pour arriver au bout.

    RépondreRépondre
  3. LOL . Pardon mais Louis faut pas faire ce genre d’articles 😀

    Ce qui prend cher c’est RAM *et* processeur quand tu publies mais encore plus quand les gens commentent. Car ça implique de regénérer des pages.

    Avec un bon cache et des lecteurs pas très actifs, pas trop de risques de faire surchauffer la bécane

    RépondreRépondre
  4. @Gonzague: Salut Gonzague 🙂

    En fait j’ai du mal à croire que c’est le processeur qui prend cher (même si je suis d’accord sur le fait qu’il est utilisé), dans la mesure où je ne pense pas que l’on voit une évolution flagrante des performances quand tu augmentes de beaucoup le potentiel du processeur. En gros, ce que je pense, c’est que le temps de calcul processeur est de toute façon négligeable par rapport au reste (notamment le rapport entre temps d’accès RAM et disque dur), et donc qu’augmenter les performances du processeur n’est pas la première chose à faire.

    RépondreRépondre
  5. je ne sais pas où tu as lu que je recommandais d’augmenter la puissance du processeur ? :-d

    Mise en cache efficace = moins d’appels au processeur (et éventuellement tu caches en RAM, d’où des bons temps d’accès)
    Utilisation d’un CDN = réduction des requêtes services par le serveur principal donc de l’impact sur le proco et la RAM

    RépondreRépondre
  6. @Joe: héhé, c’est ce que je suis en train de voir (impressionnant !). Malheureusement, le serveur sur lequel est AbriCoCotier actuellement (ça va changer !) n’est pas optimisable, et c’est pareil pour tous ceux qui sont sur des mutualisés :-/

    RépondreRépondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.