le mécanisme de lock et de log à base de fichier pénalise SPIP en terme de perfs.
Est-ce que syslog pourrait être proposé nativement, en alternative aux logs SPIP ?
le mécanisme de lock et de log à base de fichier pénalise SPIP en terme de perfs.
De quoi parles tu exactement ? Commencer par une proposition affirmative, définitive et non etayée n’est pas une super base de discussion.
Pour information, on a introduit des niveaux de logs dans Spip 3 avec pour conséquence directe qu’un site en prod ne log plus que les erreurs, soit pas grand chose en principe…
Est-ce que syslog pourrait être proposé nativement, en alternative aux logs SPIP ?
Ca peut aussi être l’objet d’un joli plugin (car c’est similaire à memoization)
Tu peux faire tout ce que tu veux en plugin, la fonction inc_log_dist est surchargeable.
Il sera alors temps de voir l’intérêt constaté en terme de perf et la portabilité.
le mécanisme de lock et de log à base de fichier pénalise SPIP en terme de perfs.
De quoi parles tu exactement ? Commencer par une proposition affirmative, définitive et non etayée n’est pas une super base de discussion.
En fait je parlais du constat qui avait été fait par Thomas à l’époque : http://passingcuriosity.com/2009/logging-the-locking-in-spip/
"The problem, it seems, lies in SPIP’s use of locking to serialise access to a number of files containing cached data. In essence: SPIP seems to deadlock when attempting to lock certain files in the /tmp/ directory. This hangs the PHP process (FastCGI, in our case) which consumes resources and, eventually, prevents the web-servers from being able to serve requests for PHP. "
Il a constaté le problème, et pour être honnête je ne sais personnellement pas si SPIP a changé de méthode depuis. Donc j’ai fais confiance en son analyse… qui date un peu…
Après, je m’excuse de m’être un peu mélangé les pinceaux entre les lock et l’utilisation de syslog…
Pour information, on a introduit des niveaux de logs dans Spip 3 avec pour conséquence directe qu’un site en prod ne log plus que les erreurs, soit pas grand chose en principe…
J’ai vu, c’est vraiment bien !!
Il existe un paramètre quelque part qui indique que le serveur est en production ou en développement ?
J’ai vu qu’on peut customiser le niveau de log, mais cela me semble moins explicite qu’une variable etat_du_site=[production|developpement]
– variable qui modifierait le niveau de log par défaut –
Tu peux faire tout ce que tu veux en plugin, la fonction inc_log_dist est surchargeable.
Il sera alors temps de voir l’intérêt constaté en terme de perf et la portabilité.
en fait pour les perfs, Thomas semble indiquer que c’est spip_fopen_lock() et spip_fclose_unlock() qui peuvent être optimisées.
(ce qui n’a rien à voir avec syslog )
)