Contrairement à la plupart des systèmes de publication gratuits, SPIP intègre un système de cache permettant d’accélérer l’affichage du site public. Quelques pistes pour comprendre ce qui influe sur la rapidité de votre site...
Optimiser un site
Si vous vous inquiétez pour la rapidité de votre site, il est bon de vous intéresser aux pistes suivantes :
Votre hébergement Web offre-t-il des performances de bonne qualité ?
Evidemment, c’est subjectif. L’expression « mauvaise qualité »
recouvre à coup sûr la plupart des hébergeurs gratuits (notamment Free).
« Bonne qualité » inclut forcément une machine dédiée
(i.e. qui ne sert qu’à votre site) de fabrication récente, mais
aussi des hébergeurs commerciaux pas trop au rabais. Entre les
deux, ça devient très subjectif, en fonction de vos exigences,
de la taille de votre site....
Si la qualité de votre hébergement laisse à désirer, vous aurez
intérêt à ne pas créer de squelettes trop complexes, i.e.
qui demandent à SPIP d’afficher trop d’informations différentes.
Cela vaut pour tout type d’informations :
tout ce qui, dans les squelettes, est susceptible d’être
transformé par SPIP en données affichables. Notez, en particulier,
que les squelettes fournis par défaut démontrent au maximum
les possibilités de SPIP, et par conséquent génèrent
des pages assez lourdes.
N’oubliez pas non plus de régler les délais d’expiration des
différents types de pages. Ainsi, si votre site contient un
grand nombre d’articles en archives, vous avez peut-être
intérêt à augmenter la durée d’expiration des articles,
sinon les articles consultés peu souvent ne bénéficieraient
pas du système de cache.
L’influence du cache
La présence du cache change quelque peu la donne en matière de rapidité. Ce n’est pas tant le nombre de visites de votre site qui sera le point critique, que la capacité de votre serveur à recalculer les pages dans le temps imparti au script PHP (en effet, sur la plupart des serveurs, une limite de durée d’exécution par appel de script est fixée afin d’éviter les abus et les erreurs de programmation). Par contre, si la page demandée est dans le cache et n’a pas expiré, la réponse du serveur devrait être quasi-instantanée (dans le cas contraire, votre serveur est vraiment très chargé).
La qualité des performances devient ainsi objectivement mesurable si, lors du recalcul d’une page du site, on obtient un « timeout », c’est-à-dire que le serveur a dépassé le temps maximal d’exécution d’un script PHP. Alors il faut soit changer d’hébergement, soit se résoudre à afficher des pages plus simples : pour cela, modifier les squelettes pour afficher moins d’informations sur une même page.
Sur une machine dédiée
Si vous utilisez votre propre machine, il faut vous assurer qu’elle pourra tenir la charge. N’importe quelle machine récente devrait en être capable ; pour donner des chiffres très approximatifs, mettons qu’il faut au minimum un processeur à 200 MHz, et 128 Mo de mémoire.
Par contre, l’utilisation de SPIP, par rapport à d’autres systèmes de publication, permet de mutualiser les ressources techniques entre plusieurs sites. En effet, tant que le cache est utilisé, la machine est peu sollicitée, donc plusieurs sites peuvent cohabiter sans problème (sauf s’il y a vraiment un très grand nombre de visites).
Version 1.2 - Le moteur de spip a été entièrement refondu dans la version 1.2. Sous le nom de code « Pantagruel » il comporte désormais deux phases de « cache » : la première lors de la lecture initiale des squelettes (elle crée les fichiers CACHE/skel_nomdusquelette.php3) ; la seconde lors de la lecture des données dans la base mySQL. Chacune des étapes du calcul des pages a été revue et optimisée. Le gain total permet d’obtenir une génération de page en moins de la moitié du temps nécessaire pour la version 1.0.
RSS 2.0
Vos commentaires
# Le 7 septembre 2001 à 18:47, par topper
Tout d’abord , je tiens à vous engager dans votre projet.
Je le trouve trés pratique et il devrait grandement simplifier le travail de tous ( et économiser les serveurs mutualisés )
Pourriez vous m’expliquer pourquoi ce page, http://www.uzine.net/article997.html
qui pèse 25 Ko + 15 ko environ de gif, met ¢ 10 secondes à s’ouvrir, alors que celle-ci par exemple :
http://www.leche-vitrines.com/avign...
(hébergement amen).
ne met que 6 secondes alors qu’elle est fait 120 ko ( avec un script PHP de 50 lignes et une requette MYSQL).
( connection ADSL )
J’ai lu votre article sur le cache, et je ne comprends pas pourquoi il y à une telle différence .
En effet et si j’ai bien compris, le cache d’un article( si il existe) est inclu directement dans la page dynamique (article.php3), sans passer par la base de donnée.
Cela equivaut donc à un include d’un fichier qqconque.
Cordialement, Jean-Guillaume
# Le 7 septembre 2001 à 19:08, par ?
Difficile de répondre (même si le principe du cache tel que tu l’expliques est correct)...
# Le 7 septembre 2001 à 20:49, par ?
Pourriez vous m’expliquer pourquoi ce page, http://www.uzine.net/article997.html qui pèse
25 Ko + 15 ko environ de gif, met ¢ 10 secondes à s’ouvrir, alors que celle-ci par exemple :
http://www.leche-vitrines.com/avign... (hébergement amen). ne met que
6 secondes alors qu’elle est fait 120 ko ( avec un script PHP de 50 lignes et une requette
MYSQL). ( connection ADSL )
Pour comparer réellement des durées d’exécution, il faut faire des tests
en local sur le serveur. Là tes tests sont entachés par la bande passante
de ton fournisseur, la nôtre, et celle des tuyaux qui sont entre toi et nous.
Par exemple et pour indication, la page que tu cites sur uzine ne prend
que trois secondes à charger chez moi (graphiques compris). Mais c’est
déjà beaucoup.
Par contre, si je teste directement sur le serveur Web d’uZine (en utilisant Apache Bench,
un programme permettant de mesurer les performances d’un serveur),
la page http://www.uzine.net/article997.html est retournée en exactement
vingt millisecondes. Tu vois que le cache SPIP fonctionne plutôt pas mal ;))
a+
Antoine.
# Le 11 septembre 2001 à 11:01, par Arthur
Bonjour
D’abord, est-ce que la gestion des images marchera un jour sur Multimania ?
Serait-il possible de faire un site SPIP chez Free.fr (chez qui la gestion des images fonctionne) et de connecter la base de données non pas à sql.free.fr mais à un compte Multimania (plus rapide) ?
Sinon, une autre possibilité consiste à faire le site chez Free complètement puis de le déplacer en exportant la base de données et les images vers Multimania, mais c’est une manipulation plutôt lourde pour les néophytes... pourrait t’on intégrer à SPIP une telle fonction, qui en un clic envoie par FTP la base de donnée mise à jour et les images nouvelles ?
Enfin, est-ce que Free ne pourrait pas accélérer un peu ses serveurs, vu que visiblement ce qui ralentit tout est le serveur proxyphp3.free.fr qui semble filtrer tout le traffic (même si lasécurité serait moindre...) ?
Enfin, un bug je crois : un clic sur les logos d’articles ainsi que la validation (SUBMIT) d’une recherche (formulaire) amènent tous deux à une erreur 404, car le lien se refère à un fichier "interdire_scripts.php3", qui est introuvable...
Bravo pour votre travail, j’en ai rêvé, uzine l’a fait ! ça fait des années que j’attendais un système comme ça, sans avoir le temps de men occuper moi même...
Merci d’avance pour vos réponses,
Arthur
# Le 11 septembre 2001 à 12:04, par ?
Salut Arthur,
D’abord, est-ce que la gestion des images marchera un jour sur Multimania ?
Il faut leur demander... ;)
Serait-il possible de faire un site SPIP chez Free.fr (chez qui la gestion des
images fonctionne) et de connecter la base de données non pas à sql.free.fr
mais à un compte Multimania (plus rapide) ?
Non, ça ne marchera pas, la plupart des hébergeurs interdisent de se connecter
à leurs bases de données depuis l’extérieur.
Sinon, une autre possibilité consiste à faire le site chez Free complètement
puis de le déplacer en exportant la base de données et les images vers
Multimania, mais c’est une manipulation plutôt lourde pour les néophytes...
pourrait t’on intégrer à SPIP une telle fonction, qui en un clic envoie par FTP la
base de donnée mise à jour et les images nouvelles ?
En un clic non. Par contre tu peux toujours transférer la base en utilisant
"sauvegarde/restauration de la base". Pour les images, la seule solution
est de transférer tout le dossier "IMG".
Enfin, est-ce que Free ne pourrait pas accélérer un peu ses serveurs, vu que
visiblement ce qui ralentit tout est le serveur proxyphp3.free.fr qui semble
filtrer tout le traffic (même si lasécurité serait moindre...) ?
Il faut leur demander ... !
Enfin, un bug je crois : un clic sur les logos d’articles ainsi que la validation
(SUBMIT) d’une recherche (formulaire) amènent tous deux à une erreur 404,
car le lien se refère à un fichier "interdire_scripts.php3", qui est introuvable...
Oui, effectivement, c’est un bug de la 1.0.5. Désolé...
a+
Antoine.
# Le 15 septembre 2001 à 21:04, par Arthur
merci !
et la 1.0.6 est pour quand ?
ciao
# Le 15 septembre 2001 à 21:17, par ?
Elle vient de sortir ! Tu peux la trouver sur http://rezo.net/spip-dev/.