Publier un service sur Internet, c'est gérer la montée en charge, ce ne sont pas 2-3 évaluations sur un environnement de développement (ou une production non surchargée) qui permettront de choisir la meilleure conception en développement pour que tout se passe bien en production ultérieurement.
Utiliser une base de données en écriture, c'est générer des locks qui pénaliseront inévitablement les select à titre de statistiques (alors que ces derniers pourraient être fait en asynchrone, sur une "base" de la veille par exemple). Si les logs sont bien formatés, rien n'empêche de déporter les imports dans une base décorrélée du service principal (consulter des images, en soumettre) pour l'exploiter à des fins de statistiques.
Combien de sites subissant l'effet /. (se faisant linuxfriser en bon françois) ont dû désactiver piwigo qui utilise le même genre de conception ?
Par ailleurs, utiliser une base sqllite compliquera le fonctionnement concernant les accès concurrents en écriture s'il y a plusieurs serveurs web (avec une seule base centralisée, devenant le SPOF par nature et du fait de la conception).
Ne t'en déplaise, contrairement à toi, je continuerai à pertinenter Kerro< pour ses avis, demandant parfois d'être approfondis ou explicités, il est vrai, mais pointant un vrai sujet la plupart du temps (bon, parfois il peut raconter de mauvaises vannes, comme tout le monde :D).
En outre, un tail -t /var/log/production.log | grep xxxxxx permettra de surveiller ce qui se passe en direct, en cas de surcharge, sans avoir à désactiver les statistiques... Il pourra même y en avoir plusieurs en parallèle (chacun ne traitant que la sortie courante), plutôt que plusieurs select en parallèle, bloqués par les écritures en base et nécessitant d'avoir les index chargés en mémoire pour être efficaces...
[^] # Re: Curieux la base de donnée
Posté par BAud (site web personnel) . En réponse à la dépêche Lut.im, un service d'hébergement d'images gratuit, libre et anonyme. Évalué à 3.
tout est dit :-)
Publier un service sur Internet, c'est gérer la montée en charge, ce ne sont pas 2-3 évaluations sur un environnement de développement (ou une production non surchargée) qui permettront de choisir la meilleure conception en développement pour que tout se passe bien en production ultérieurement.
Utiliser une base de données en écriture, c'est générer des locks qui pénaliseront inévitablement les select à titre de statistiques (alors que ces derniers pourraient être fait en asynchrone, sur une "base" de la veille par exemple). Si les logs sont bien formatés, rien n'empêche de déporter les imports dans une base décorrélée du service principal (consulter des images, en soumettre) pour l'exploiter à des fins de statistiques.
Combien de sites subissant l'effet /. (se faisant linuxfriser en bon françois) ont dû désactiver piwigo qui utilise le même genre de conception ?
Par ailleurs, utiliser une base sqllite compliquera le fonctionnement concernant les accès concurrents en écriture s'il y a plusieurs serveurs web (avec une seule base centralisée, devenant le SPOF par nature et du fait de la conception).
Ne t'en déplaise, contrairement à toi, je continuerai à pertinenter Kerro< pour ses avis, demandant parfois d'être approfondis ou explicités, il est vrai, mais pointant un vrai sujet la plupart du temps (bon, parfois il peut raconter de mauvaises vannes, comme tout le monde :D).
En outre, un
tail -t /var/log/production.log | grep xxxxxxpermettra de surveiller ce qui se passe en direct, en cas de surcharge, sans avoir à désactiver les statistiques... Il pourra même y en avoir plusieurs en parallèle (chacun ne traitant que la sortie courante), plutôt que plusieurs select en parallèle, bloqués par les écritures en base et nécessitant d'avoir les index chargés en mémoire pour être efficaces...