racine uZine

Dans la même rubrique
Guide du webmestre et du bidouilleur SPIP
23 septembre 2001
2 juillet 2001
15 juin 2001
 
samedi 16 juin 2001

Rapidité du site public

par l’équipe de SPIP
 

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.

 
 
l’équipe de SPIP
Imprimer
format impression
l’équipe de SPIP
1er juin 2001
16 août 2002
1er juillet 2001
26 mai 2003
 
SPIP
Web indépendant


lenteur de Free... et un bug-report
11 septembre 2001, message de 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

 
Répondre
> lenteur de Free... et un bug-report, 11 septembre 2001

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.

Répondre
> > Merci ! et la 1.0.6 est pour quand ?, Arthur, 15 septembre 2001

merci !
et la 1.0.6 est pour quand ?
ciao

Répondre
> > > Merci ! et la 1.0.6 est pour quand ?, 15 septembre 2001

Elle vient de sortir ! Tu peux la trouver sur http://rezo.net/spip-dev/.

Répondre


> Rapidité du site public
7 septembre 2001, message de 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/avignon/o/optiquegregoire
(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

 
Répondre
> > Rapidité du site public, 7 septembre 2001

Difficile de répondre (même si le principe du cache tel que tu l’expliques est correct)...

- Peut-être Amen est-il plus rapide que notre machine, surtout lorsqu’il s’agit de fournir du HTML.

- Du côté de Amen, une unique requête, ça représente un temps de calcul dérisoire. De notre côté, note tout de même que le compteur des visites du site provoque, malgré le cache, quelques requêtes mySQL ; mais temps de calcul dérisoire également.

- Surtout... la page sur Amen que tu cites est d’une structure très très simple. Les pages sur uZine, à l’inverse, ont une structure HTML très complexe, avec un nombre très important de tableaux imbriqués, du texte justifié, de nombreux changements de polices de caractères, des boutons avec survol... dès lors, même si le temps de chargement dans l’absolu peut être rapide, l’affichage de cette page par le brouteur peut être plus long (parce que ton logiciel va effectuer beaucoup de calculs pour simplement l’afficher à l’écran).

Répondre
> > Rapidité du site public, 7 septembre 2001

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/avignon/o/optiquegregoire (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.

Répondre