Renaud (Nel) Morvan a écrit :
On 16 fév, 15:07, Stephane <steph...@rezo.net> wrote:
Gilles Quiniou a écrit :
Dans quelle mesure avons-nous besoin du cron? De cet appel jquery? Y a-t-il un moyen de les contourner?
Le cronspipl'utilise pour certains truc genre l'indexation, ou les mises à jours de cache, je sais plus trop. Ca sert en gros à executer une tache un peu lourde de temps en temps.
le cron est fait pour que les traitement asynchrones soient fait de
facon asynchrone => ne ralentissent pas l'affichage de la page
Tout fichier inclus dans une page particulièrement en tête de html,
ralenti le chargement d'une page. S'il est placé en fin de code comme
le font les outils de stats classiques ne ralentisse pas l'affichage
de la page mais au moins l'envenemement 'onload'
Je vous invite à lire la série des articles de yahoo à ce sujet:
YUI Library
Et moi je t'invite à TESTER avant de sortir des âneries.
#SPIP_CRON est appelé comme une image de fond généralement la dernière appelée.
L'*affichage* de la page n'est pas ralentit.
En l'occurrence la question n'est pas est-ce que ca ralenti la page
par rapport au fait que ce soit calculé au cours de la page ou dans
une deuxième requête à la page mais est-ce que ca ralenti la page tout
court.
La question est : est ce que l'utilisateur a l'impression que ca rame ou non, c'est la seule qui compte.
La réponse est oui, comme n'importe quelle requête http, sauf
que celle ci est de surcroit dynamique donc plus lente.
Donc, non, tout faux, pour nous, l'important, c'est l'utilisateur, d'ou ce choix d'"architecture".
Pour ce qui est de jquery c'est carrement débile car si vous aviez le fichier static correspondant jquery.js vous gagneriez 1/3 du temps de chargement de la page. Avoir un fichier dynamique le dessus est une erreur de conception.
ce qui est carrement debile, c'est de raconter des conneries pareilles
sans savoir ce que l'on dit.
1- le systeme de cache joue pleinement son role et le serveur n'est
réellement sollicité que très rarement (calcul 1 fois par semaine,
chargement effectif une fois par semaine et par utilisateur)
2- ca permet au contraire d'eviter beaucoup de hits sur le serveur
puisqu'on construit un fichier unique et compressé au lieu d'en appeler
4 non compressés (ce qu'on conserverait pour des questions de
maintenabilité)
Je suis navré de voir votre manque de compétence en terme
d'optimisation d'architecture.
c'est surement pour ca que je n'ai pas beaucoup de travail et que je suis mal payé alors...
Mais je suis pris d'un doute.
As tu au moins compris qu'il suffisait de copier dist/inc-head.html dans /squelettes et de le modifier pour faire autrement ?
Sais-tu au moins ce qu'est un squelette ?
Comparer un fichier static à un cache
dynamique en terme de performance c'est comme comparer la course à
pied à la course à vélo. Aussi bon que soit l'athlète il n'arrivera
jamais à la cheville du cycliste du dimanche.
RE debilité !
il faut comparer ce qui est comparable.
ici, nous avons en source 4 fichiers javascripts non compressés, ce qui est un choix de *maintenabilité* et de *lisibilité*.
C'est donc à la lecture de ces *4 fichiers non compressés* qu'il faut comparer la méthode retenue :
Avantages :
- 4 fois moins de requetes HTTP
- sans doute 3 fois moins de bande passante utilisée
Idem :
- Le cache du navigateur jouant son role, le fichier n'est effectivement chargé qu'une fois par semaine
Inconvénient :
- 1 recalcul par semaine (compression des 4 fichier et ecriture d'un cache statique)
- traitement PHP avant de renvoyer le cache statique (gestion de cache de Spip), l'utilisation de FASTCACHE (plugin) permettant de revenir aux performances d'un fichier statique
Il est impossible de faire plus performant qu'un fichier static en
terme de temps de réponse, celui est optimisable de millier de facon
(cache via etag, reverse proxy, gzip de base...).
c'est bien.
Et tu fais des modifs dans les fichiers javascripts compréssés toi ?
Tu es trop fort !
Mais Spip, c'est fait pour etre utilisable aussi par les nuls comme moi... alors c'est mieux comme c'est la.
Chez l'hébergeur lambda vous n'aurez ni cache navigateur
???
quel rapport avec l'hebergeur ?
il faut se renseigner un peu sur Spip : il sait tres bien gerer les entetes HTTP...
, ni gzip
La compression de flux est intéressante pour gagner de la bande passante, mais ca ralentira l'affichage de la page pour des petites pages, c'est pour ca que ca a été écarté au profit de la compression du fichier avant mise en cache.
et
les temps de réponse php seront incomparablement plus lent.
un eval PHP fait perdre du temps, donc meme l'accès à un cache statique (ce qui est le cas pour la page jquery) est plus lente effectivement.
C'est pour ca que Fil a mis au point FASTCACHE et Cedric Expresso.
Sans compter que dans le cas spécifique de spip, ca va demander
beaucoup d'appel fichier (chargement des libs spip, puis recherge du
cache, dzipage du cache ...). Bref une usine à gaz pour un fichier qui
ne change jamais.
si on parle de la /dist, en effet.
Mais l'avantage, c'est qu'il peut etre personnalisé (différent pour les utilisateurs authentifiés), ce qui ouvre beaucoup de possibilités.
Quand tu fais ca, tu vois bien l'interet du peiti traitement à chaque hit...
Rien ne vous empêche de livrer dans la release spip une version
compressée et d'avoir dans svn la version en clair qui sera compressé
lors du packaging, ou même de livrer les 2.
Rien ne t'empêche de développer un CMS, meme de forker Spip si tu penses vraiment pouvoir faire mieux.
Après, ce genre de discussion, on l'a sur la liste de développement, en étant courtois, et en partant du principe que les choix n'ont pas été fait au hasard.
Arriver en disant : vous etes nuls faut faire ca, c'est perdu d'avance et cela est vrai pour tout projet open source.
Le temps passé du cron nuit-il à la charge de l'hébergeur? Nuit-il à l'affichage ou, se produisant à la fin, s'exécute-t-il une fois le reste chargé et affiché par le navigateur?
Il nuit à l'hébergeur dans le sens ou à chaque page chargé ca charge une deuxième page,
Et on aurait mis les traitement directement dans le hit principal, ca
changerait quoi pour le serveur ?
2 fois moins de hit dynamique, 2 fois moins de chargement des
librairies spip nécessaire à cette tache. Et si sur la machine du
dev@localhost ca ne change rien, chez l'hébergeur qui héberge des
milliers de spip, ca se voit.
Sauf que ca donne la souplesse de déclencher le CRON uniquement dans les pages souhaitées, donc, par exemple, pas sur la page d'accueil.
Chacun peut faire ses reglages en fonction du trafic et de la quantité de taches de fond à traiter.
RIEN !
Par contre l'utilisateur attendrait la fin de l'indexation pour voir sa
page... genial !
La question de fond, est que vient donc faire l'indexation chez
l'utilisateur du site web. Ca n'est pas sa place, l'indexation est un
problème coté serveur, à traiter coté serveur par l'administrateur.
N'hesites surtout pas à nous expliquer comment tu fais une tache CRON chez Free ....
Et surtout pense à laisser tes coordonnées pour faire les formations utilisateurs.
Sur cette liste, pour 90% des utilisateur, CRON c'est un gros mot, alors dis toi que tu as du boulot....
Une des contraintes que se sont fixés les développeurs de Spip est de faire un outil accessible aux non informaticiens.
Ca passe avant l'optimisation...
Comment peux tu critiquer un outil sans savoir à quoi il sert ?
La
présence de ce mode de fonctionnement est un workaround pour faciliter
la vie de l'installateur lambda d'un spip. C'est louable mais c'est
une pustule d'un point de vue architecture et scalabilité, qui
gagnerait à être externalisé dans un cron particulièrement sur des
spips avec bcp de visiteur.
Sauf qu'il suffit de supprimer l'appel à #SPIP_CRON et de mettre ce qu'on veut dans le "vrai" cron si on en a les compétences et la possibilité.
Mais celui qui ne sait meme pas ce qu'est un CRON peut quand meme utiliser Spip et l'installer en 5 clics chez Free.
D'ailleurs il est probable que la présence de ce cron.php uniquement
dans la partie admin serait nettement suffisant mais je ne connais pas
suffisament ce que signifie l'indexation dans spip pour pouvoir en
discuter en connaissance de cause.
Visiblement tu ne connais pas grand chose sur Spip.
Tu n'as sans doute meme pas pris la peine de lire un peu cette liste, sinon tu saurais que le problème principal et récurent des taches CRON, c'est que les sites avec tres peu de visite ont du mal à exécuter l'ensemble des taches.
Il n'y a pas que l'indexation d'ailleurs, il y a la syndication, l'envoi de mail, des optimisations de base et tout ce que l'utilisateur peut y ajouter (plugin)
ce qui double la charge pour l'hébergeur par rapport à chaque page vue. Ca ralenti l'affichage pour vos coopérateurs uniquement si l'appel à cette page se situe au début du code html, sinon ca ralenti juste le démarrage des javascripts.
c'est un appel en image de fond, ca ne ralentira rien du tout.
Qui raconte ce genre de connerie ?
Faudrait peut etre lui conseiller de se renseigner un peu avant de
l'ouvrir...
Malheureusement sans vouloir rentrer dans le jeu de la flame war entre
nous deux vous êtes celui qui connait le mieux de spip ca ne fait
aucun doute mais également celui comprend le moins les réalités du
développement web et des contraintes d'architecture ou de scalabilité.
Je suis consultant informatique, chef de projet et architecte J2EE et amené, dans ce cadre, à conseiller des grands groupes.
Jusqu'ici les clients chez qui j'interviens n'ont pas l'air de cet avis, mais il est probable qu'ils se trompent, tout comme tous ceux qui sont inscrits sur cette liste et utilisent bêtement Spip.
Ceci dit, si j'ai une contrainte forte de scalabilité, je déconseille tout simplement les langages interprétés...
Mais il faut savoir quand meme que Spip est utilisé par des grands groupes avec des grands nombres d'utilisateurs et que la scalabilité est un des arguments de ce choix (ou disons que Spip est le seul outil PHP qui n'est pas exclus d'office)
Mais on attend avec impatience ton "CMS qui marche mieux que Spip parce que Spip c'est nul".
Tant que tu y es, tu devrais aussi parler de programmation objet et appeler ton projet agora, tu verras, ca va faire un carton.
Bon, aller, j'arrete.
Mais la base avant de critiquer, c'est quand meme de se renseigner un minimum et de ne pas se croire plus intelligent que ceux qui ont fait le boulot.
Et au lieu de répondre des conneries, d'aller poser la question à ceux qui connaissent les réponses (spip-dev).
Je ne dis pas que Spip est parfait, ni que les choix d'architecture sont les meilleurs, mais ce sont des choix, il faut donc comprendre leurs motivations avant de les critiquer.
Maintenant SPIP est en GPL, tu as le droit de modifier ce qui ne te convient pas.
Avec le système de surcharge et de pipeline, tu peux meme le faire avec très peu d'effort.
Mais tu vas sans doute nous dire que tout cela est une hérésie architecturale (car si il faut travailler sur qqchose pour les perfs, c'est clairement du coté de find_in_path et des nombreux function_exists qu'il faut agir)
@++
