* Jean-Marie Malsacre tapotait, le 03/04/2007 08:44:
Jacques PYRAT a écrit :
* Pierre LASSALLE tapotait, le 02/04/2007 22:26:
Je ne sais pas, j'ai fait évoluer les squelettes après le passage sur ouvaton3.
Personnellement, je m'y suis un peu perdu avec ces injonctions contradictoires.
Dans un premier temps, j'ai cru lire sur les forums d'aide un encouragement à utiliser SPIP
lorsqu'on souhaitait avoir un CMSDans un deuxième temps, ce fut "Mettez à jour vos versions de SPIP"
Et comme généralement, le squelette ne colle plus avec la nouvelle version, on met aussi à jour le squelette.
Et je crois entendre maintenant : "Oui, mais maintenant cette dernière version est dévoreuse de ressources".
En ce qui me concerne, c'est mon squelette qui est *vraiment* gourmand (parce que puissant).
En local aussi, il est de plus lent qu'avant.
Préalable : ça fait déjà 2 ans que je me dis que mon site est trop lourd pour la plate forme ouvaton.
J'ai retardé au maximum mon départ parce que j'aime bien l'esprit coopératif d'Ouvton.
Là, je suis parti parce que j'avais besoin que mon site soit en ligne.
Ce n'est donc pas sur un coup de tête, et c'est à regret.
Bon, je me suis contenté le lire les différents posts sur ces erreurs 500 que le spip nouveau générait.
Spip est un tres bel outils, très utilisé, mais dont le developpement fait qu'il devient une usine a gaz consommatrice de ressources, voir un gaspillage de celles-ci.
Est-ce que tu pourrais être factuel ?
Comment SPIP consomme les ressources ?
Lesquelles (filer, mysql, ram, cpu...) ?
Les developpeurs de Spip mettent les hebergeurs devant le fait accompli en changeant de version sans crier gare. Ouvaton doit compter plusieurs milliers de Spip sur sa plate-forme et si 1/4 des cooperateurs passent en version 1.9x, ca fout la plateforme en l'air (ou du moins ca lui met du plomb dans l'aile).
Les dev de SPIP sont preneurs de retours, de coopération, d'amélioration.
Ils ont fait de gros effort sur la possibilité de mutualiser le code source pour faciliter la maintenance de fermes SPIP pour les hébergeurs.
Mais jusqu'à présent, ils n'ont pas eu de retour probant (quelques échanges de mails en privés à ma connaissance... tu pourrais nous en dire plus JMM ?).
Il y a une fonctionnalité de la 1.9 qui doit bouffer pas mal de ressources filer, c'est find_in_path qui n'a pas de cache 
.
Mais le reste ?
La 1.9.2 a changé radicalement la gestion du cache : à chaque changement dans la base (ou post dans un forum), c'est l'intégralité du cache qui est invalidé (mais pas effacé : il s'efface au fur et à mesure des recalculs).
On a beaucoup trollé sur le fait que les squelettes en cache de SPIP étaient chargés par eval() et ne bénéficiaient donc pas de l'optimisation php accellerator. Mais quels tests ont étés faits ?
Sur une palteforme mutualisée comme la notre, on ne peut pas se permettre de faire des reglages trops larges car il faudrait au moins doubler les ressources en serveurs afin de repondre au besoin de ces scripts gloutons de memoire et temps cpu. Une limitation est necessaire, forcement, et ceci afin de ne pas penaliser les autres cooperateurs qui eux n'utilisent pas spip et qui ne verraient pas d'un bon oeil le fait que leur petits copains piquent les ressources a leur detriment et ce sans contrepartie.
Mais c'est sur que, comme pour la Mondialisation, on est devant le fait accompli, et il va falloir nous organiser afin de trouver une solution.
Et c'est surtout dans ce sens (trouver des solutions) que j'aimerais bien que la discussion tourne.
- installer plus de serveurs? OK, mais qui va payer?
- proposer un hebergement en 'serveur de course' (moyennant un tarif special) pour les sites qui demandent plus de puissance/capacités?
Pourquoi pas ?
Mais sans procédure de migration manuelle SVP !
- limiter le nombre de Spip?
Impossible à imposer !
Ma position est que les techniciens d'Eiole comprennent bien qu'il n'est pas normal pour nous d'accepter qu'un nombre important de cooperateurs soient penalisés par une limitation du systeme, surtout quand on connait le remede a apporter.
Mais je refuse de partir dans une course à la debauche de moyens sous pretexte que des developpeurs d'une application, meme si c'est Spip, ne font pas tout, de leur coté, afin de limiteer la consommation de ressources de leur bébé. Ils sont entrain de scier la branche sur laquelle ils développent leurs rameaux.
Bref, c'est pas si facile que cela a gérer.
Mais si vous avez des solutions/propositions (plutot que des 'plaintes'), on peut discuter de cela en toute sérénité.
Je propose que tout comme il y a eu la feria de SPIP, la coding party, la design party, il y ait une Hosteurs Party avec Ouvaton/Eiole, Lautre.net, ... et des devs de SPIP pour permettre à chacun de mieux comprendre les besoins, les possibilités, les contraintes.