Du coup, dans ce cas, les performances apportées par le service de cache ne serviront à rien car un cache local ferra le boulot, non?
Quel cache ? Par défaut tu as un cache en lecture sur le système de fichier et tu peux avoir quelque chose au niveau de ton driver de base de données. Ce sont des caches pour les quels tu as très peu de contrôle (politique d'éviction par exemple, politique d'insertion,...). Imaginons un cas tu accède à une API qui est payante ou qui limite ton débit (elle te demande à ne pas lui envoyer plus de N requêtes par seconde), tu va trouver dommage de te contenter d'un cache local.
Tout à fait, si tu fait du calcul intensif. Et tu as même la possibilité de partager de la donnée entre tes threads sans sérialisation. Mais tu as pleins d'autres paramètres que ça à prendre en compte. Le plus classique c'est que si tu as un gc tu veux des processus les plus petit possibles. Au niveau du système d'exploitation, tu perds toute flexibilité de monitoring et d'administration. Si tu veux privilégier les réponses aux requêtes (qui ne sont pas forcément toute en lien avec ton cache), tu va peut être demander à ton OS de privilégier l'un sur l'autre. Ton process va aussi être une cible de choix pour l'OOM killer. De manière moins précise je n'ai toujours eu que du positif à découper ce genre de chose mais là je n'ai rien de plus à présenter que ça donne l'impression que la machine « respire mieux ».
S'il est activé et que tu utilise fpm ou en module de ton serveur web.
souvent les caches c'est le premier truc que tu veux virer au démarrage d'une appli pour être dans un état connu,donc à priori, stable
Alors si tu es instable à cause de ton cache le problème c'est pas le cache :) Ce comportement vient surtout du fait qu'on veut mettre à jour le cache au démarrage on est pas sûr qu'il soit à jour et on préfère le détruire (c'est l'équivalent du shift+F5 sur ton navigateur). Si tu as la possibilité de savoir qu'il est à jour, il n'y a pas de raison de le détruire.
Ce "problème" (ou "faux problème"), [...]
Et hop ! On file dans la rhétorique. C'est toi qui te demandais si on est toujours dans l'informatique ?
[...] tu l'as pour les bases de données sous le nom de "driver" JDBC/ODBC/etc... développés et fournis par les développeurs des bases de données.
Alors ODBC c'est du "système" et l'idée c'est d'implémenter sous forme d'une bibliothèque partagée et que les langages puisse juste s'interfacer à un driver ODBC sans avoir à réimplémenter le driver... Comme quoi c'est un problème qui n'existe tellement pas que des gens essaient de le résoudre.
Tu trouvera JDBC et DBI qui sont des API respectivement en java et en perl qui définissent un driver standard (en natif dans leur langage ou ODBC) et proposent une API dessus. C'est la même idée.
Bon toutes ses API sont liées à SQL quand tu es un NoSQL tu peut abandonner l'idée de ce type de partage. Il y a quelques tentatives, mais c'est pas tr_s développé et plutôt compliqué.
Maintenant, si on regarde plutôt que de juger. Prenons quelques base de données NoSQL :
C'est une corrélation et pas forcément une causalité, mais disons que si des développeurs disent « on fait ça pour simplifier, la vie des développeurs de drivers » et ils ont semble-t-il1 plus de driver que les autres. C'est peut être un faux problème, hein ? Mais bon, il va falloir des arguments en plus pour me faire remettre en cause leur dire.
il serait possible de regarder le nombre d'implémentation quelque soit le langage, mais j'ai la flemme. ↩
[^] # Re: Formatage automatique
Posté par barmic 🦦 . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 3. Dernière modification le 04 mai 2020 à 09:48.
Quel cache ? Par défaut tu as un cache en lecture sur le système de fichier et tu peux avoir quelque chose au niveau de ton driver de base de données. Ce sont des caches pour les quels tu as très peu de contrôle (politique d'éviction par exemple, politique d'insertion,...). Imaginons un cas tu accède à une API qui est payante ou qui limite ton débit (elle te demande à ne pas lui envoyer plus de N requêtes par seconde), tu va trouver dommage de te contenter d'un cache local.
Tout à fait, si tu fait du calcul intensif. Et tu as même la possibilité de partager de la donnée entre tes threads sans sérialisation. Mais tu as pleins d'autres paramètres que ça à prendre en compte. Le plus classique c'est que si tu as un gc tu veux des processus les plus petit possibles. Au niveau du système d'exploitation, tu perds toute flexibilité de monitoring et d'administration. Si tu veux privilégier les réponses aux requêtes (qui ne sont pas forcément toute en lien avec ton cache), tu va peut être demander à ton OS de privilégier l'un sur l'autre. Ton process va aussi être une cible de choix pour l'OOM killer. De manière moins précise je n'ai toujours eu que du positif à découper ce genre de chose mais là je n'ai rien de plus à présenter que ça donne l'impression que la machine « respire mieux ».
S'il est activé et que tu utilise fpm ou en module de ton serveur web.
Alors si tu es instable à cause de ton cache le problème c'est pas le cache :) Ce comportement vient surtout du fait qu'on veut mettre à jour le cache au démarrage on est pas sûr qu'il soit à jour et on préfère le détruire (c'est l'équivalent du shift+F5 sur ton navigateur). Si tu as la possibilité de savoir qu'il est à jour, il n'y a pas de raison de le détruire.
Et hop ! On file dans la rhétorique. C'est toi qui te demandais si on est toujours dans l'informatique ?
Alors ODBC c'est du "système" et l'idée c'est d'implémenter sous forme d'une bibliothèque partagée et que les langages puisse juste s'interfacer à un driver ODBC sans avoir à réimplémenter le driver... Comme quoi c'est un problème qui n'existe tellement pas que des gens essaient de le résoudre.
Tu trouvera JDBC et DBI qui sont des API respectivement en java et en perl qui définissent un driver standard (en natif dans leur langage ou ODBC) et proposent une API dessus. C'est la même idée.
Bon toutes ses API sont liées à SQL quand tu es un NoSQL tu peut abandonner l'idée de ce type de partage. Il y a quelques tentatives, mais c'est pas tr_s développé et plutôt compliqué.
Maintenant, si on regarde plutôt que de juger. Prenons quelques base de données NoSQL :
C'est une corrélation et pas forcément une causalité, mais disons que si des développeurs disent « on fait ça pour simplifier, la vie des développeurs de drivers » et ils ont semble-t-il1 plus de driver que les autres. C'est peut être un faux problème, hein ? Mais bon, il va falloir des arguments en plus pour me faire remettre en cause leur dire.
il serait possible de regarder le nombre d'implémentation quelque soit le langage, mais j'ai la flemme. ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll