Optimiser le temps de chargement d'un site

le Sam 1 Oct 2011 16:35

Bonjour à tous,

J'ai une question qui me trotte dans l'esprit depuis hier soir :
J'ai cru comprendre qu'optimiser son fichier css (supprimer les espaces, les div non utilisées etc) permet d'améliorer le temps de chargement d'un site web.

En est-il de même pour les fichiers php ? Par exemple, les commentaires dans le code ralentissent le chargement d'une page ?

Existe-t-il d'autres moyens pour optimiser le temps de chargement de son site ?



Avatar de l’utilisateur   
T0n10
Like Rank Total : 1.5    
Actif
 
Messages : 68
Inscription : Lun 12 Sep 2011 14:03
Localisation : Bayonne







    
 

le Sam 1 Oct 2011 16:51

Effectivement supprimer les commentaires des pages, optimiser son css, etc, permet de diminuer le chargement d'une page. Mais améliorer le chargement d'une page ne se limite pas qu'à ça.

tu peux déjà tester ta page sur http://pagespeed.googlelabs.com/pagespeed/ , tu pourras voir ce que tu as à amméliorer ;)


6 crédits nécessaire (1 ligne(s) + 3 Lien(s) en signature + 0 profil WWW + 0 mise(s) en forme)
Vous avez seulement 4 crédits de disponible :(
Vérifiez les nouvelles rêgles des signatures du forum, SVP

taeky    
Actif
 
Messages : 656
Inscription : Jeu 6 Mai 2010 08:08

le Sam 1 Oct 2011 16:53

Tout ce qui peut permettre à un crawleur d'indexer un contenu plus rapidement est bon ;)

Les images aussi... :mrgreen:


8 crédits nécessaire (1 ligne(s) + 4 Lien(s) en signature + 0 profil WWW + 0 mise(s) en forme)
Vous avez seulement 5 crédits de disponible :(
Vérifiez les nouvelles rêgles des signatures du forum, SVP

Avatar de l’utilisateur   
referenceur
Like Rank Total : 3.5    
Actif
 
Messages : 2000
Inscription : Sam 31 Oct 2009 19:21
Localisation : Lyon

le Dim 2 Oct 2011 15:36

Les notes donnés par page speed sont très élevés je trouve sur des sites qui rament


Pokergang: poker,freeroll

reglisse531
Like Rank Total : 3    
Actif
 
Messages : 298
Inscription : Mer 20 Juil 2011 10:51

le Dim 2 Oct 2011 19:41

Donnes nous une adresse, mais souvent on commence par le poids des images, système de cache ou non, ensuite l'opti dans les css et javascript et vraiment s'il y a encore des soucis il faut voir le codage PHP ou autre langage du site.


Choppez du BL sur l'annuaire Tabbos et Cp tourisme

Avatar de l’utilisateur   
shelko
Like Rank Total : 2    
Actif
 
Messages : 458
Inscription : Sam 30 Avr 2011 20:03

le Dim 2 Oct 2011 19:45

tout ce qui a été dit est vrai mais ne répond pas à ta question tonio: non, rien à cirer de ce que tu as comme commentaire dans ton php, ça ne changera rien au temps de chargement de tes pages. C'est uniquement sur la taille du html qu'il produit qu'il peut être intéressant de réflechir.


Réparer son iphone, trouver des pièces de portable, c'est sur http://comptoir-iphone.com/ que ça se passe

Avatar de l’utilisateur   
36positions
Like Rank Total : 1.5    
Actif
 
Messages : 2297
Inscription : Mar 9 Aoû 2011 12:10
Localisation : Caen

le Lun 3 Oct 2011 08:32

Le temps de chargement devient un critère important comme le montre notre message Basculement à J+26

La priorité doit porter sur la réduction des images, et sur le nombre de fichiers. Tu peux ensuite réduire les CSS, puis les HTML.

Comme le dit 36positions, réduire les commentaires PHP ne sert pas à grand puisque le PHP n'est pas affiché : il est uniquement traité par le serveur avant la création de la page Web. La différence de temps de traitement est presque négligeable, et je ne suis pas certain que ce délai soit pris en compte par les bots : j'ai plutôt l'impression qu'ils ne commencent à tester la durée qu'à partir de la réception des données.

J'ajoute qu'il est ridicule de retirer les indentations HTML. Il faut au contraire indenter pour mieux pouvoir s'y retrouver plus tard, et détecter plus facilement les erreurs. Il est par contre important de virer toutes les lignes vides et de remplacer les espaces par des tabulations.

Je te propose de regarder comment nous avons procédé sur notre site.


La qualité et le savoir-faire à la française... Utilisez l'Editeur php phpDesigner 8. C'est la nouvelle version.

Avatar de l’utilisateur   
phpDesigner
Like Rank Total : 1    
Actif
 
Messages : 695
Inscription : Sam 13 Aoû 2011 08:54
Localisation : Clermont-Ferrand

le Lun 3 Oct 2011 09:43

phpDesigner a écrit:(...)
J'ajoute qu'il est ridicule de retirer les indentations HTML.
Si c'est du html généré, ça fait toujours quelques octets en moins.
phpDesigner a écrit:(...)
Il est par contre important de virer toutes les lignes vides et de remplacer les espaces par des tabulations.
(...)
Pas dit qu'avec la compression gzip ça prenne plus de place.


SAPA, N°1 du traitement termite depuis 1964: http://www.sapahabitat.com/

Avatar de l’utilisateur   
36positions
Like Rank Total : 1.5    
Actif
 
Messages : 2297
Inscription : Mar 9 Aoû 2011 12:10
Localisation : Caen

le Lun 3 Oct 2011 11:46

Architecture

C'est en fait d'abord la structure du code lui-même qui doit être vu en premier. Il faut virer les routines inutiles, restreindre le nombre de chargements de fichier (chaque ouverture de fichier prend du temps), diminuer au maximum la capacité de chacune des images, et dimensionner les images.

Indentation

:D Nous avons effectivement testé sur notre site avec et sans indentation.
  • Sur le CSS, cela joue un rôle important, raison pour laquelle nos CSS ne possèdent ni espaces ni tabulations inutiles.
  • Sur le JavaScript cela joue également un rôle important, mais moindre.
  • Sur le HTML, le temps de chargement de la page est sensiblement le même avec et sans indentation. Donc inutile de se priver de cet excellent outil de suivi dans le temps. Nous avons également conservé les vrais commentaires (c'est toujours utile) : cela ne nous pénalise visiblement pas.

Compression

Après compression gzip, le résultat final du temps de chargement est meilleur lorsque toutes les lignes inutiles ont été retirées et que toutes les espaces multiples ont été remplacées par des tabulations.

Astuce

Bon à savoir : une image CSS sera chargée sur toutes les pages qui utilisent ce CSS, ce qui peut donc générer du temps d'ouverture de fichier inutile, puis du temps de chargement inutile, à contrebalancer avec le temps mis à charger un nouveau CSS.


Essayez la technologie et le savoir-faire français grâce à l'Editeur de html phpDesigner 8 nouvelle version.

Avatar de l’utilisateur   
phpDesigner
Like Rank Total : 1    
Actif
 
Messages : 695
Inscription : Sam 13 Aoû 2011 08:54
Localisation : Clermont-Ferrand

le Lun 3 Oct 2011 14:05

Ok, tous vos points de vus et vos conseils sont super intéressants. J'me posais pas mal de questions et vous m'avez éclairé 8-) , merci beaucoup les gars.

Je travaille sur l'amélioration du temps de chargement de mon annuaire depuis hier et j'ai déjà bien avancé grâce à vous.
Le widget "PageSpeed" de Chrome/Firefox m'a aussi beaucoup aidée. Encore quelques détails à régler et ce sera parfait ;)

Merci encore.



Avatar de l’utilisateur   
T0n10
Like Rank Total : 1.5    
Actif
 
Messages : 68
Inscription : Lun 12 Sep 2011 14:03
Localisation : Bayonne

le Lun 3 Oct 2011 14:48

;) Ta page Accueil s'affiche en 4.7 secondes alors qu'il n'y a rien dessus. Elle devrait pouvoir s"afficher en 1.8 seconde depuis un CMS et 0.9 (ou moins) si tu la réécrit depuis un vrai IDE.


phpDesigner 8 nouvelle version rend simple l'utilisation de n'importe quel Framework, y compris le vôtre...

Avatar de l’utilisateur   
phpDesigner
Like Rank Total : 1    
Actif
 
Messages : 695
Inscription : Sam 13 Aoû 2011 08:54
Localisation : Clermont-Ferrand

le Ven 7 Oct 2011 12:32

Dans ce cas là il s'agit des chargements de chaque petite image qui fait aboutir à un score de 6,57s

Personnellement je pense qu'il faut d'abord optimiser le temps de chargement des pages, déjà en optimisant le sql, puis le code, puis un cache, servir les contenus statiques sous un autre sous domaine. Puis d'optimiser Apache, mysql tuner, utilisation mémoire du serveur.

Je ne pense pas que retirer des sauts de ligne ou indendations soit réellement déterminant .. surtout quand la compression gzip est mise en place


4 crédits nécessaire (1 ligne(s) + 2 Lien(s) en signature + 0 profil WWW + 0 mise(s) en forme)
Vous avez seulement 3 crédits de disponible :(
Vérifiez les nouvelles rêgles des signatures du forum, SVP

Avatar de l’utilisateur   
nyx    
Actif
 
Messages : 80
Inscription : Sam 26 Fév 2011 00:37
Localisation : Genève

le Dim 9 Oct 2011 12:46

il y a déjà une discussion à ce sujet avec une foule de réponses (où :?: ) mais il faut savoir que toutes les solutions ne sont pas acceptées par tous les serveurs ;)


fonds d'écran gratuits - fonds d'écran NARUTO -

Avatar de l’utilisateur   
bg62
Like Rank Total : 6    
Actif
 
Messages : 995
Inscription : Dim 26 Déc 2010 16:54

le Sam 19 Nov 2011 05:23

C'est un sujet super large et il y a énormément de levier sur lesquels jouer. C'est une de mes spécialités.

Je pense que je m'en sort pas mal sur mon site http://www.weebio.fr/. Et je trouve que les temps présenter de 6,5 secondes sont énorme :o

Quel est le poids de la page ?

A savoir que PHP n'est que très rarement le facteur qui ralentira le chargement des pages web mais ! Oui il y a toujours un mais, certain détail à savoir comme le faite de bien configurer dans le php.ini (et pas dans un fichier php avec ini_set()) le timezone du serveur peut faire gagner de précieuse dizaine de millisecondes (ce qui est énorme à ce niveau pour un simple réglage).
Compacter les fichiers PHP à la manière des javascript ou css ne te fera gagner qu'un ou deux micro seconde sur l'interprétation et encore. Cela n'en veut pas la peine.

Bref généralement on retrouvera les conseils classiques partout et les outils comme pagespeed par exemple comme cité avant résume bien les choses.

Déjà il faut que tu identifies ou est-ce que c'est lent ? (la requête DNS, la connection au serveur http, le temps de génération de la pages, la récupération des données mysql, le temps de téléchargement de la page (et contenu associés)) etc... à partir de là tu sauras quelle partie il faut optimiser.

A savoir pour pagespeed, si vous déférer les contenus statiques à un sous domaine c'est pas juste histoire de faire joli et que les éléments statiques ai un nom à eux. C'est surtout que derrière le sous domaine il y a un serveur optimiser pour délivrer du contenu statique.
Donc ne vous embêter pas à créer un sous dom pour le plaisir des yeux à pagespeed si derrière c'est le même serveur que votre site dynamique qui déssert les contenus.


Boutique de cosmétiques bio

azes    
Actif
 
Messages : 23
Inscription : Jeu 17 Nov 2011 02:47
Localisation : Nantes

le Lun 21 Nov 2011 01:37

Bonjour,
Pour optimiser un site, il y a différents choses à effectuer:
Avoir un code propre !
Requêtes sql à optimiser au maximum !
Se service des fonctions ( function {} ) que de reprendre X fois un code !
Mettre un système de cache sur le site sur les requêtes les plus demandée !
Un CMS compact !
Voilà, bonne continuation



Avatar de l’utilisateur   
slyckers    
Actif
 
Messages : 22
Inscription : Lun 17 Mai 2010 23:29
Localisation : Grasse

le Lun 21 Nov 2011 04:46

Excuse moi slyckers mais je ne suis pas d'accord avec ce que tu dis. Les bonnes pratiques c'est bien et c'est ce que tu essaies de pronner ici c'est une bonne chose en général sauf quand on parle d'optimisation.

slyckers a écrit:Avoir un code propre !


Propre ou sale ne changera pas l'optimisation mais propre c'est mieux.

slyckers a écrit:Requêtes sql à optimiser au maximum !

Avant de passer au crible les requêtes SQL du site à coup de explain :
1° La base de donnée est-elle un frein ?
2° Le BDD est-elle solicitée en écritures ou en lectures majoritairement ?

En écriture:
1- Vérifier les verrous qui mettent en file d'attente d'autres requêtes.
2- Si le 1- ne suffit pas, vérifier que la qualité des IO sur le disk.
3- Si le 2- ne suffit pas, déferer les écritures pour les grouper si possible, vérifier les requêtes.
4- Si le 3- ne suffit pas, scaler la BDD.

En lecture:
1- Vérifier la montée correct en cache (ram, temp table) des jeu de résultat.
2- Si le 1- ne suffit pas, mettre le log des slow query en route, vérifier les indexes sur les requêtes loguées.
3- Si le 2- ne suffit pas, optimiser les requêtes (clause limit, join, créer des vues...).
4- Si le 3- ne suffit pas, scaler la BDD.

slyckers a écrit:Se service des fonctions ( function {} ) que de reprendre X fois un code !


Généralement c'est le contraire qu'il faut faire pour optimiser, cela s'appelle mettre en ligne une fonction ceci pour deux raisons:
1- Avec du code en ligne, le code n'a pas de saut à faire, les registres du processeurs n'ont pas besoin de d'être sauvegarder dans la pile ou le tas etc... un appel de fonction d'une manière général fait parti des éléments qui prennent le plus de temps dans l'exécution du code.
2- Généralement la factorisation (utiliser qu'une seul fois le code) se fait dans un fichier séparer ce qui signifie inclure ce fichier à l'exécution or l'inclusion de fichier est un appel système (lecture sur disque). C'est très lent à l'exécution.

Toutefois ceci est à pondérer en fonction du nombre d'appel de la fonction et du compilateur. il vaut mieux factoriser avec un interpréteur JIT et du code monté en ram alors que pour du compilateur (le compilo fera le job pour toi quand c'est utile de toute façon) ou un interpréteur non optimisant avec du code sur disque vaut mieux mettre en ligne.

Mais attention et ceci vaut pour tous les sujet (code, bdd, serveur), il ne faut optimiser que ce qu'il est nécessaire d'optimiser. Généralement toute optimisation anticipée se retourne contre son auteur (c'est à dire qu'elle ralentit au lieu d'accéléré). Donc je me répète avant de s'amuser à mettre en ligne des fonction, fait un test avec siege ou ab pour vérifier quelle est la patie lente. si c'est la génération de la page. Profiler le code pour vérifier si c'est le bootstrapping, le code ou la base de donnée qui est lent. Si c'est le code vérifier quelle partie est fautive et n'optimiser que ceci.

slyckers a écrit:Mettre un système de cache sur le site sur les requêtes les plus demandée !


C'est généralement un bon principe sauf si le système de cache génère plus d'IO, sauf si la page génère des écritures, sauf si la page doit être en temps réel. La cache (au niveau global) est vraiment à limiter au maximum. c'est rarement la première à faire.

slyckers a écrit:Un CMS compact !


Utiliser surtout un système qui réponde à son besoin.


Boutique de cosmétiques bio

azes    
Actif
 
Messages : 23
Inscription : Jeu 17 Nov 2011 02:47
Localisation : Nantes

le Lun 21 Nov 2011 05:10

Ma réponse était compact et je ne pense pas avoir tort étant donné que l'un de mes plus gros site possède 34 000 membres et plusieurs connectés/jour.
Côté serveur, j'en ai pas parlé , car c'est un vaste sujet à aborder (prix du serveur, proco, ram, etc...)

Un code propre c'est certain que cela change du tout au tout:
Connexion non fermée etc... sans parler des while à répétition...
Donc un code propre optimise une page et là je certifie.
Pour la fonction, là je ne suis pas du tout d'accord avec mais alors d'un point qui me dit que tu as zapé quelque chose:

Exemple: j'ai 10 fonctions qui sont appelées comme ceci,
function picture{ } qui comporte par exemple des milliers de photos
puis dis autres..
Je fais juste un petit cache sur les requêtes de mes fonctions et le tour est joué !
Exemple:
Code: Tout sélectionner
///Debut du cache au dessus de ma requète/////
$cache_expire = '120'; //en minutes
$url_server = $_SERVER['REQUEST_URI'];
$url_server = str_replace('/', '-', $url_server);
$cache_file = 'cache/cache'.$url_server;
if ($cid =='24'){$cache_file = NULL;}
if (@filemtime($cache_file) < (time() - ($cache_expire * 120))) {
ob_start();
/////////
CODE
//fin du cache////
$cache_contents = ob_get_contents();
ob_end_flush();
$fd = fopen($cache_file, 'w');
if ($fd) {
fwrite($fd, $cache_contents);
fclose($fd);
}
} else {
  include ($cache_file);
}
////////


Après je n'ai pas trop envie de commenter ce que tu dis car cela va se finir a 10h du matin !

Le sujet étant " Optimiser le temps de chargement d'un site "
Donc au vu de mes différentes citations (sans rentrer dans les détails) sont des directions à prendre pour vérifier si tout est fait à ce niveau là. Sinon il est clair que chaque site est différent et un pré-diag peut se faire sur la machine et sur le script du site.
Après parler des heures, on peut, mais je ne pense pas que cela soit le sujet.

Voilà bonne journée à tous.
Anthony.



Avatar de l’utilisateur   
slyckers    
Actif
 
Messages : 22
Inscription : Lun 17 Mai 2010 23:29
Localisation : Grasse

le Lun 21 Nov 2011 06:01

Mon expérience concernant les optimisations vient essentiellement d'un site de VP que j'ai créé et qui (à mon départ de la société) possédait 6 millions de membres et tous les jours entre 9 et 10H le matin dépassait les 100 000 membres connectés en simultanné et cela pouvait monté à plus de 300 000. (surtout qu'à l'époque ça tournais sur du P4 avec 256 ou 512Mo de ram par server, on rigolais bien).

Je suis certains que ta propre expérience t'en a appris beaucoup sur les optimisations à faire. Et tu peux t'appuyer sur la mienne si tu le souhaite ou pas. Mais je t'assure si ton site connais de la croissance, tu seras surpris de ce que tu auras à faire ;)

Sinon un code juste pour reprendre ce que tu as dit, parlons des mêmes choses, un code qui ne ferment pas une ressource ouverte est un code incorrect. Je parle uniquement de code sale autrement dit, qui ne suis pas une convention d'écrire, qui n'est pas correctement indenter, dont le nom des variable ou fonction n'est pas explicite.

Concernant la mise en ligne, un bon exemple serai de te référé au mot clé « inline » des langages C et C++ et à la manière dont fonctionne un compilation comme GCC, G++ ou encore LLVM etc...
Et sur les IO avec PHP simplement vers toutes les présentation de Rasmus Lerdorf (le papa de PHP) concernant les optimisations en PHP.

Ton exemple de cache est une cache partielle, comme je l'ai dit la cache globale est rarement une bonne idée, la cache partielle c'est différent.

Comme tu le dis, le sujet est optimiser un temps de chargement, le sujet est large et complexe si on se plonge profondément sur la chaine de réponse d'un site internet. Je n'ai pas parlé en plus du fait qu'il faut identifier si le problème survient à faible charge, en montée en charge ou à pleine charge car les solutions à apporter (et les problèmes) sont alors différents.
Mais j'ai supposés au vu des messages précédent que c'était un soucis permanent et ma réponse reste la même, d'abord identifier l'élément de la chaine qui fait bouchon.


Boutique de cosmétiques bio

azes    
Actif
 
Messages : 23
Inscription : Jeu 17 Nov 2011 02:47
Localisation : Nantes

le Ven 23 Déc 2011 23:39

Bonjour,

Parmi les techniques utilisés pour accélérer l'affichage des sites internet (pour les robots), ont néglige souvent le temps de résolution DNS des liens qui se trouve sur la page !

Si vous utilisez des liens extérieurs à votre site pour charger des fichiers css, images ou autres, alors il est important de déclarer ce nom de domaine dès le début du script pour que le robots fasse sa résolution DNS dans le header pour qu'arrivé au lien proprement dit, la résolution soit terminé !

Ainsi, pas de perte de temps !



Avatar de l’utilisateur   
cssfr    
Débutant
 
Messages : 9
Inscription : Ven 23 Déc 2011 22:43
Localisation : Toulouse

le Ven 23 Déc 2011 23:51

Très bonne remarque, j'en profite pour rajouter que pour les liens internes au site donc sous le même domaine, utiliser des liens relatif plutôt qu'absolue élimine la requête DNS. Ce qui est encore meilleur.


Boutique de cosmétiques bio

azes    
Actif
 
Messages : 23
Inscription : Jeu 17 Nov 2011 02:47
Localisation : Nantes

le Sam 24 Déc 2011 00:03

Bonjour je viens vous partager une infime partie de mon projet, en effet ce dernier tourne sur un système que personne ne connait apparemment en France il s'agit de "LNAMP", un système optimisé par un chinois, je suis en train de tester ça, c'est vraiment une bombe. Donc en gros LNAMP c'est comme LAMP mais avec NGINX en sus; ce dernier, d'après ce que j'ai compris est configuré pour mettre en cache le contenu statique d'un site, dont les images, de plus eaccelarator,gzip,memcache sont incorporés dans le script. Le contenu du package sur Google se trouve ici: http://code.google.com/p/lnamp-web-server/updates/list.
Vous pouvez le voir en action sur mon serveur.


mon premier site de tchat

weboost
Like Rank Total : 1    
Actif
 
Messages : 75
Inscription : Sam 17 Déc 2011 11:28

le Sam 24 Déc 2011 01:00

weboost je suis perplexe.

Je viens de regarder lnamp et c'est juste un nginx monté en proxy cache par dessus un lamp, il n'y a rien de plus banal.

Si comme tu dis personne ne connais lnamp, cette solution est utilisé depuis des années. Après chacun l'appel comme il veut ;)

Actuellement ce qui a le vent en poupe c'est plutôt Varnish (en remplaçant de Squid) pour la cache et vaut mieux utiliser comme web Nginx - php-fpm plutôt qu'Apache - mod_php à l'heure actuelle...


Boutique de cosmétiques bio

azes    
Actif
 
Messages : 23
Inscription : Jeu 17 Nov 2011 02:47
Localisation : Nantes

le Sam 7 Jan 2012 13:21

Je me dis que je suis à l'ouest, mais si on prend l'exemple de Drupal, certains experts préconisent l'utilisation de caches proxy. Le truc c'est que leur utilité je la vois que sur des sites ou des pages à très fort trafic et fortement statiques. (et même, finalement je vois pas trop la différence avec un nginx)

Si quelqu'un peut m'éclairer (et les autres) sur ce sujet ça m'intéresse.

Sinon j'ai déjà combattu seul pour optimiser les temps de chargement insatisfaisants sur plusieurs sites, et il y a des points qui reviennent :
- Utiliser des bibliothèques javascript aussi peu que possible est à garder en tête, car j'ai trouvé assez fréquent que le chargement de jQuery donne une forte sensation de lenteur.
- Utiliser des feuilles de sprite : comme quand on fait un jeu vidéo en 2D, on crée des sprite sheets, concept que je conseille de chercher sur le web. On gagne du temps sur une page, car on peut réduire très fortement le nombre de requêtes HTTP nécessaires à son affichage.
- Regrouper les JS et les CSS en des fichiers uniques.
- Concevoir correctement (des fois une conception un peu lourde peut sauver les performances dans le futur) sa base peut aider dans certains cas
- Profiler le code lent peut réserver de bonnes surprises
- Nettoyer, optimiser ou configurer sa base de données peut aider
- Faire les images les plus petites possibles (des fois un JPG à 70% fait l'affaire, des fois un GIF ou un PNG sera plus léger)
- etc


Site de rencontre gratuit

Avatar de l’utilisateur   
artscoop    
Actif
 
Messages : 52
Inscription : Mar 31 Aoû 2010 05:58
Localisation : France

le Sam 7 Jan 2012 14:26

@artscoop :

Nginx peut créer la confusion assez facilement car il peut être utilisé de 2 manières différente :

• Nginx peut être utilisé comme serveur web (comme Apache) et servir du document statique ou être couplé à des langages comme PHP, Python, Ruby etc...
• Nginx peut être utilisé comme proxy-cache (comme Squid, Varnish (ce nom me fera toujours penser à de la lessive)).

Comme tu l'as dis un proxy-cache enregistre des pages statiques et les ressert au client ce qui soulage le serveur qui produit les documents et la base de donnée etc...
Les sites à fort trafic les utilisent comme tu le dis car ils n'ont guère le choix, le passage par ces solutions est plus ou moins obligatoire à partir d'un certain trafic si l'on ne veut pas multiplier les serveurs et avoir des couts de fonctionnement exorbitant.

Donc lorsque l'on est confronté à des problèmes de performance on essaie d'abord d'optimiser le code etc... puis on essaie de rendre statique le plus possible ses contenus dynamiques afin de pouvoir faire intervenir de la cache et gagner donc en performance.

Il existe énormément de solutions possible à se niveau. Prenons un exemple pratique assez classique : Le cas d'un site e-commerce.

Au premier regard sur un site e-commerce, il semble impossible de mettre une page en cache car le site à un haut de page qui affiche des informations personnelles : si le client est connecté ou non et son panier.
Chaque page affichée, même si 99% de son contenu est identique, est donc personnalisée pour chaque utilisateur. On ne peut donc pas cacher les pages pour les re-servir à un autre utilisateur.

Pourtant il existe plusieurs solutions afin de ne pas être bloqué par cette situation :

1: La cache partielle

On utilise le langage dynamique qui sert a produire le site, on enregistre (dans un fichier, en ram, où l'on souhaite...) les parties statiques de la page et on se contente de générer les parties dynamiques.
Ici on trouve déjà un gain de performance assez important, le processeur tourne moins, la base de données est moins solicitée, les pages sont déservient plus vite.
Cette cache est très maniable, on cache ce que l'on veut, ou l'on veut etc... Généralement pour améliorer encore les performances de ce type de cache, plutôt que d'enregistrer les éléments cachés dans des fichiers (les accès disques c'est toujours lent) on va faire intervenir des serveurs spécialisé comme Memcache, ou des base NoSql (en mode non persistant) comme Redis, Mongodb qui ont le gros avantage de tout stocké en RAM (ces mêmes solutions sont très utile pour stocker les sessions).
Ces serveurs sont très efficace pour enregistrer beaucoup de petits contenus mais deviennent très vite moins performant pour enregistrer plusieurs Ko ou Mo de données (surtout Memchache).

Ceci-dit, au bout d'un moment cela ne suffit plus en terme de performance, surtout aujourd'hui ou les frameworks atténuent beaucoup les performances des caches partielles car le bootstrapping du framework (routage, frontController, controller, vue etc...) est toujours exécuté, bootstrapping qui peut parfois voire souvent être la cause des problèmes de performance.

2 : Les SSI (Server Side Includes)

Un peu comme vous avez appris le PHP pour beaucoup les SSI fonctionnent de la même manière. On créer du code HTML qui contient des appels vers d'autres fichiers pour les inclure.
Cette technique revient au gout du jour un petit peu alors qu'elle avait presque disparue sous le règne d'apache.
A la différence avec PHP c'est que c'est le serveur web (Apache, Nginx, Lighthttpd) qui se charge de faire l'inclusion.
L'avantage est certain car vous pouvez pour votre site e-commerce générer une page HTML qui, a la place d'avoir l'entête avec le login et le panier, contient un code pour inclure cette entête dynamique.
La page deviens donc statique et appelle sa partie dynamique au moment de l'envoie au visiteur. Cette technique peut être utilisée avec des proxy cache qui se chargent alors des inclusions.
Personnellement je n'ai jamais eu l'occasion de travailler sur cette technique alors je n'en dirai pas plus sur ses bienfaits ou méfaits.

3 : La solution javascript

Et oui pourquoi exécuter un travail sur le serveur quand le poste du client peut le faire pour vous ?
A la manière des SSI vu juste avant, on supprime l'entête dynamique de la page web ce qui permet de la rendre statique et de la cacher entièrement.
Par contre on ajoute un code javascript à la page qui, une fois la page chargée chez le client, fera une nouvelle requête (Ajax) sur le serveur pour récupéré les informations dynamiques manquantes et les inclure. Le javascript créée alors le contenu manquant pour terminer la page.

C'est cette technique que j'emploie actuellement sur mon site e-commerce.


Drupal étant une énorme machine à gaz (capable de faire de bien belle chose ceci-dit). C'est un système conçu pour créer une page de toute pièce et Drupal va utiliser beaucoup de processeur et de temps pour créer une page web. Page web, qu'il faut voir comme le résultat d'un calcul mathématique par exemple.

Et c'est bien dommage d'utiliser beaucoup de ressource, qui pourrait être utile ailleurs, pour effectuer toujours ce même calcul. D'autant plus quand celui-ci demande du temps, vaut mieux enregistrer le résultat.

C'est pour cela que dernière un gros CMS comme Drupal il convient de lui fournir des solutions de cache. Cela permet au server d'occuper son processeur à d'autre chose comme servir plus d'utilisateur par exemple, cela augmente le confort de l'utilisateur qui reçoit sa page plus rapidement, cela soulage l'administrateur du site qui à moins de travail à maintenir une machine moins chargée.

C'est vrai que l'on voit ces solutions sur des sites à fortes charges principalement parce que pour eux c'est devenu vital mais rien n'empêche de les utiliser sur un site qui n'a pas encore trop de trafic car:
- le jour ou tu as un pic de trafic ça évite bien souvent de crasher de le server
- ton temps de chargement se réduisant cela joue sur ton référencement (en mieux)
- c'est aujourd'hui connu, quelque milliseconde de gagner peuvent faire beaucoup transactions en plus sur un site e-commerce par exemple.

Ce que je n'ai pas mentionner tout à l'heure c'est que ces solutions peuvent être cumulées.

Voilà j'espère que cela t'aura éclaircie sur l'utilité des caches. J'ai écris cela en 2 minutes alors faudra me pardonner les fautes de grammaire partout. Je ne parle pas de php-fpm avec nginx ou de APC etc... car c'est un autre sujet totalement différent (même si APC fait de la cache... mais d'opcode).

Dernière édition par azes le Sam 7 Jan 2012 14:49, édité 1 fois.

Boutique de cosmétiques bio

azes    
Actif
 
Messages : 23
Inscription : Jeu 17 Nov 2011 02:47
Localisation : Nantes

le Sam 7 Jan 2012 14:43

Très clair et utile. La solution Ajax est facile à mettre en place pour les webmasters pour délester le serveur.


depannage informatique - referencement

Avatar de l’utilisateur   
rsw
Like Rank Total : 10    
Actif
 
Messages : 2084
Inscription : Mar 24 Mai 2011 13:43
Localisation : Paris

le Dim 8 Jan 2012 03:37

Merci azes, ça répond parfaitement à ma question et même plus.
Je me disais bien que l'utilisation du javascript pouvait être couplée à de tels caches.
Je doute que ça soit pratique si la page est très personnalisée, mais sur un site, c'est rare que toutes les pages le soient. On peut donc mélanger cette technique avec d'autres.

Par exemple, le bigpipe de Facebook est un bon moyen de donner une impression de vitesse (car le contenu de la page est affiché progressivement, plutôt qu'affiché une fois la page totalement chargée). Facebook n'utilise d'ailleurs pas de proxy-cache je crois, mais des tonnes de serveurs memcache.


Site de rencontre gratuit

Avatar de l’utilisateur   
artscoop    
Actif
 
Messages : 52
Inscription : Mar 31 Aoû 2010 05:58
Localisation : France

le Dim 8 Jan 2012 11:42

Merci :)

Le chargement dynamique est une bonne idée c'est clair. C'est une des techniques les plus utilisées à l'heure actuelle. Son plus gros inconvénient est qu'elle ne présente rien au moteur de recherche pour ceux qui n'exécutent pas le JS. C'est pour cela qu'utiliser plusieurs technique et d'en faire sa soupe à soit est recommandé si je peux dire ça comme ça.

Il faut savoir rationaliser certaines choses. C'est à dire éviter de s'enflammer en disans je vais monter un serveur Apache avec APC et Memcache et un base NoSql Cassandra et tout mettre en ram (que des solutions performantes en soit) pour servir un blog Dotclear sur une machine qui a 256 Mo de ram. ça serait beaucoup de travail pour un résultat certainement très lent au final et un serveur qui risque de crashé très rapidement.

Il faut bien voir la chose sous cet angle, chaque technique existe car elle présente des avantages et aussi des inconvénients, mais SURTOUT certains avantages n'existe qu'a un certains niveau de charge et deviennent par la suite de gros inconvénients.

Par exemple la cache disque est simple, peu chère, idéale pour cacher des gros volumes de données (en totalité on peu caché des Giga de data) et de grosse section (ex, une grosse page html de plusieurs Ko). C'est d'autant plus vraie si on a des disques en raid 0 ou encore mieux un SSD mais moins vrai si on a du raid 1. (Ceci dit pour le SSD faut un ratio lecture/écriture avec très peu d'écriture).
La cache disque est surtout limitée par le nombre d'accès, à un certains nombre d'accès concurrent le disque va saturer et à ce moment là c'est tout le serveur qui va tomber.

En bref la cache disque est idéale pour un petit site (< 10 000 vis./mois mettre la cache en ram n'aidera guère dans la règle générale). Surtout que les petits sites (dans le sens peu de Ko cette fois ci) retrouverons leur cache disque dans la mémoire cache du disque (oui faut suivre) et donc c'est comme si la cache était déjà en RAM. (oui il ne faut pas oublier que le matériel à ses propres systèmes de cache et il faut en profiter).

Après si cette cache ne suffit pas c'est qu'il y a trop de connexion, ou que c'est pas assez rapide, on songe alors à monter en ram.
L'inconvénient de la RAM c'est que c'est limité (presque faux de nos jours par rappart à y'a dix ans quand je me battait pour optimiser les perfs), et si l'on a trop de connexion, elle est généralement utilisée ailleurs (toujours vrai par contre). Il faut alors déporté la solution de cache sur un (ou plusieurs) serveur externe, on perd alors tout le bénéfice du gain en vitesse on ne fait plus que soulager la pression sur les serveur.
On utilise alors les serveurs Memcache etc... non plus pour leur faculté à mettre en ram la cache (bien que la rapidité soit toujours requise) mais pour leur scalabilité (voir Facebook).

Je m'étale pas plus car il faudrait des pages et des pages pour rationaliser les coûts en fonction des situations de chaque solution.
Donc une solution de cache ça se réfléchis bien car elle peut autant faire gagner des points qu'en faire perdre beaucoup.


Boutique de cosmétiques bio

azes    
Actif
 
Messages : 23
Inscription : Jeu 17 Nov 2011 02:47
Localisation : Nantes

le Dim 8 Jan 2012 15:49

J'ai lu ta réponse en deux fois aujourd'hui, je vais commencer par le dernier paragraphe avec les clusters de Memcache : en effet, c'est logique mais on n'y pense pas forcément : si le memcache n'est pas local (et réparti sur différentes machines, plus ou moins loin d'ailleurs du serveur d'application), on perd le gain de performances mais c'est sûr, il reste le second attrait principal de la technologie, à savoir la « scalabilité ».
Enfin je suis très loin d'être aussi pointu que toi, ça ne fait que deux ans que je m'intéresse aux solutions du type (et très sporadiquement) sans en avoir testé beaucoup de techniques (tout ce qui est cluster ou réplication, je ne m'y connais pas tellement)


Site de rencontre gratuit

Avatar de l’utilisateur   
artscoop    
Actif
 
Messages : 52
Inscription : Mar 31 Aoû 2010 05:58
Localisation : France







    
 

Retourner vers Développement d'un site web




Autres sujets proches :
Un blog pour optimiser mon site       22/12/2010
Pourquoi mon site est peu référencé       28/07/2010
Votre Site dans 20000 Annuaires       14/04/2009
pb de référencement sur un site de bijoux : winaretta       22/04/2009
Référencement site étrangé       16/12/2010
Comment choisir le domaine d'un site?       11/05/2009
Référencer un nouveau site       16/08/2009
référencer son site en page 1 de google       10/09/2009