Christie Poutrelle a écrit 388 commentaires

Oui désolé j'ai répondu un peu vite, je voulais dire "dans ton cas, celui où tu as choisi Redis, alors tu es dépendent d'un autre serveur", mais bref. Ça ne change en rien que je trouve ça relativement mal documenté, mais après vu que j'ai passé des heures dessus, ça à l'air suffisant après trois relectures (essayez donc la doc de Microtik, faut s'accrocher sec par endroits).

TL;DR ("Trop Long; Pas Lu" pour les francophones refractaires): ce n'est simplement pas vrai, de manière générale dans le libre, une PR est rejetée par défaut.

Version longue:

C'est un peu plus compliqué que ça, je contribue à pas mal de logiciels open source, mais il y a toujours une communauté, des développeurs écoutés et tout puissants au milieu, et sur ce genre de logiciel plus que d'autre, qui est un produit mené par une société et non un logiciel dont le développement est basé sur la "do-ocratie", une roadmap claire et définie sur le long terme par une équipe au coeur, intriquée à la société qui développe le produit.

Et sans tenir compte que bien souvent, malheureusement, le premier réflexe d'un développeur est une méfiance systématique envers les nouveaux développeurs, plus spécifiquement quand ils font des critiques attraits au design même du logiciel.

Je pense que tout ce qui touche au fondement du logiciel (sans vouloir faire de jeu de mot), et la gestion du cache dans une application dont la performance est critique en fait partie, est sujet à ne pas évoluer sauf si un développeur déjà connu de l'équipe se saisi du sujet sur le long terme, ou apporte une idée de génie avec un proof-of-concept qui n'en est pas un sur lequel il a déjà travaillé des jours durant.

Bref, je n'ai aujourd'hui ni le temps ni l'envie de passer par toutes étapes d'introduction, gain de confiance, "beginner issues", et tout ce qui s'en suit, un process qui dans l'absolu dure des jours, semaines, mois, tout ça pour dénoncer une erreur de débutant sur la gestion du cache (ce qui serait relativement mal pris, connaissant l'égo de pas mal de développeurs) pour une application que je n'utilise plus depuis un an et des bananes.

Nextcloud est un excellent produit, de bonne qualité, je l'ai utilisé depuis que le fork a été officiellement annoncé (j'utilisais déjà Owncloud avant) et je l'ai beaucoup apprécié, cependant je suis repassé sur un ensemble de logiciels plus simples qui proposent des solutions unitaires, atomiques, à chaque besoin auquel répondait Nextcloud parce que c'est plus facile à maintenir comme ça. Nextcloud, bien qu'excellent, à un problème systématiques sur les mises à jour (j'ai du aller débugguer et patcher moi même moult fois, si ce n'est à chaque mise à jour).

Bref, je n'ai pas l'envie d'aller contribuer à ce logiciel, je le fais déjà sur suffisamment d'autres pour avoir payé ma dette au logiciel libre. Bien qu'étant un excellent logiciel dans son ensemble, ce n'est pas parce que je ne vais pas y contribuer que je n'ai pas le droit d'en soulever les points noirs et donner un avis critique (surtout que ça touche directement à mon métier quotidien), si le logiciel n'en valait pas la peine je n'en parlerais juste pas.

Et bien si, le server redis, je ne parle pas d'une autre box physique.

D'ailleurs en fait quand je vois l'implémentation de base https://github.com/nextcloud/server/blob/905e1918d2796b9a79025283cd6edf2c40f49d77/lib/private/Memcache/Cache.php le fait qu'ils servent des méthodes magiques de l'interface ArrayAccess m'indique que lorsqu'ils ont écrit ce code (c'était peut être il y a longtemps) ils ne connaissait finalement que peu ou mal les bonnes pratiques et l'outillage de la communauté PHP en général.

Juste pour info: de manière générale mettre un cache dans APCu est dangereux, les développeurs ne pensent souvent pas à tous ces petits détails, c'est extrêmement compliqué que le gérer intelligemment et sans effet de bord.

D'ailleurs quand je regarde l'implémentation https://github.com/nextcloud/server/blob/905e1918d2796b9a79025283cd6edf2c40f49d77/lib/private/Memcache/APCu.php ça semble un peu faiblard de prima-bord, j’espère qu'ils ont un contrôleur ou un décorateur autour qui gère ces problématiques (d'ailleurs, un décorateur est probablement le meilleur pattern pour s'en sortir parce que de fait il devient utilisable pour les autres implémentations).

Mon serveur fonctionne avec php-apcu uniquement et je n'ai jamais eu aucun problème

Bien entendu, avec un PHP correctement configuré de base c'est normal que ça marche. Et le fait même que tu précises "mon serveur" indique que tu n'es pas dans un scénario ou les desync sont possibles, tout simplement parce que tu ne disposes que d'un serveur.

Mais attention cependant, le cache APCu du cli, et le cache APCu du serveur web ne sont pas les mêmes, il est très probablement inutile en cli d'ailleurs puisqu'il ne persiste pas au delà de l'exécution de la commande.

Donc même dans ton scénario, pendant un temps, la desync est possible: si tu lances une commande cli qui effectue des modifications dans le cache, ton serveur web restera sur l'ancienne version du cache, puisqu'il dispose de son propre cache en mémoire partagée avec lui même.

J'espère honnêtement que l'équipe de nextcloud a prévu au moins un sémaphore sur fichier, ou dans la base, ou n'importe où qui persiste, pour indiquer une date seuil de validité des enregistrements du cache, afin que ça n'arrive pas.

Ouais alors:

• ils documentent que ce n'est pas requis,
• ils ne documentent pas comment le désactiver,
• des gens se retrouvent bloqués lors d'une mise à jour.

Ça me semble un peu bancale tout ça. Une implémentation par défaut sur le SQL aurait fait le job, c'est ce que beaucoup de frameworks ou outils font quand on choisit de ne pas configurer.

Un cache sur le SQL souffrira que si le serveur est lui même en souffrance mais sur une utilisation plus calme va offrir le même niveau de performance qu'un cache sur un service dédié (Redis, Memcache ou autre).

Le cache dans un pool APCu est relativement dangereux, si on décide de scaler (passer à l'échelle horizontalement) on va avoir des sérieux problèmes, car il ne sera pas partagé entre les différents front, et en cas d'effacement du cache on va se retrouver avec des front qui auront des caches désynchronisés, ce qui force à passer par un composant supplémentaire qui permet de servir de sémaphore, pour éviter les accès concurrents, mais aussi d'historique de synchronisation, pour éviter les problèmes de désynchronisation.

Utiliser APCu dans une conf par défaut n'est absolument pas une bonne pratique, c'est offrir par défaut la plus instable et dangereuse des implémentations.

Ah, donc choisir une implémentation basée sur un serveur ou extension supplémentaire est obligatoire :)

C'est sûr mais c'est résolument débile que l'implémentation par défaut ne soit pas dans la base de donnée, sachant que Nextcloud en requière une, et que pour le commun du mortel, c'est à dire la petite gens qui ne fait pas de cloud, qui ne gère pas des milliers d'utilisateurs concurrents, ça serait une implémentation efficace et qui fonctionnerait sur tous les environnements, et ne nécessiterait pas de configuration.

Dépendre explicitement d'APCu et ne même pas faire de check au runtime, ça me paraît être une sacré erreur. De plus, je me demande bien pourquoi ils peuvent le rendre obligatoire ? Au mieux, ils peuvent essayer de s'en servir de cache (mais c'est PAS bien, enfin si c'est pour des gros caches, c'est pas fait pour ça, c'est fait pour des petites choses) mais de plus, leur algo de mise en cache est probablement moisi, si le backend ne répond pas ou ne renvoie rien, il faut faire un fallback sur un recalcule des données nécessaires, sans planter.

Enfin bref, y'a quelque chose qui cloche dans leur implémentation.

En vrai, c'est faux, le pseudo c'était IRC, mais sur Facebook, tout le monde sait qui tu es dans le monde réel.

C'est vrai, mais l'ado peut simplement aimer comprendre le monde autour de lui, pas besoin de le ou la transformer en développeur/développeuse, mais simplement faire comprendre des choses basiques, comme par exemple, qui gère les droits, comment il décide de tel ou tel fonctionnalité du logiciel, où les données sont stockées, et comment on ne peut pas avoir le contrôle dessus, qu'une photo sur Google Photos, donc anciennement Picassa, accepte implicitement que ses photos personnelles puissent être utilisées dans des publicités de l'autre côté du monde, etc…

J'aime beaucoup l'allégorie de la façade de la maison ! C'est très expressif.

C'est bien d'avoir attendu le 2 avril pour poster ça :)

Mais je n'ai rien de magique si ce n'est tâtonner 🪄.

Je m'attendais un peu à cette réponse, mais merci pour les pistes, je vais me garder ça dans un coin au chaud, surtout schema crawler qui l'air de mettre des options pas trop idiotes.

Merci !

Hello, merci pour le partage d'expérience, c'est un besoin récurrent que l'on a aussi.

Dans les outils qui peuvent parfois sortir quelque chose de convenable, il y a pgadmin (pour postgresql) MySQLWorkbench (pour MySQL), et sinon de mon côté, vu qu'on utilise un DBAL (DataBase Access Layer) custom qu'on maintien sur nos projets, je rejoints ta solution et utilise un générateur de GraphViz branché sur un visiteur qui parcoure le schéma (outillage intégré à notre DBAL).

Par contre, j'ai toujours beaucoup de soucis avec dot, je n'arrive jamais à trouver un jeu d'options correct pour afficher convenablement les graphs, as-tu des options particulières à conseiller ?

Le but du C était quand même de rester assez proche de la machine

Même si les constructions du langage se convertissement facilement en langage machine, pour le reste il me semble que c'est une fausse affirmation, une croyance de la "jeune" (ayant débuté dans les année 80~90) génération de développeurs.

Le C a apporté des concepts très haut niveau à l'époque où il été créé comparé à ce qui existait à l'époque, et c'est ça qui a fait tout son succès. C'est d'ailleurs ce qui le rend portable.

Après j'ai pas envie de lancer un débat sur le C, et je ne pense pas que ton commentaire était fanatique ou autre, il est même plutôt pertinent.

mais on a un truc bien plus haut niveau que du pur assembleur (donc plus portable) et tout aussi proche (ce qui est nécessaire puisqu'il s'agit de programmation système.)

Par contre sur cette affirmation, je suis vraiment sceptique, avec les compilateurs modernes le code que tu écris en C n'a plus vraiment rien à voir avec ce qui généré à la fin.

On va pas s'écharper hein ?

C'était pas le but :)

La détection rapide montre que les tests sont faits

Et bien dans ce cas concret, ce ne sont pas des tests qui l'ont trouvé, mais des benchmarks sur Phoronix (mine de rien, il trouve des régressions souvent) c'est plus une détection par accident qu'un vrai résultat de test car le but ultime de ces benchs est de mesurer la performance, le fait qu'un build de test de perfs (mais pas tous) utilise un fichier de swap plutôt qu'une partition ou pas de swap ici semblait purement accidentel, d'après l'auteur. Je persiste à dire qu'ici, c'est vraiment de la chance que ça ait été trouvé avant que ça aille plus loin. D'ailleurs le fait que ça ait été trouvé sur la dernières RC montre bien que ça aurait pu passer inaperçu très facilement.

A prendre avec des pincettes toujours, le projet musl est très actif et mes retours s'arrêtent à ceux que j'ai eu il y a deux ou trois ans. Je pense que c'est très probablement un projet très sérieux, et stable.

Ah ah non, mais le débat sur musl on en trouve un peu des bouts partout, reddit, forums de gentoo, et autres. Souvent des benchmarks passent sur des sites tiers aussi, c'est un débat intéressant en vrai, je ne faisais que synthétiser ce que j'en avais agrégé dans les deux trois coins de l'internet de mon boulot ou j'en ai entendu des bout :) Je le répète encore, je peux me vautrer grave sur le sujet, alors tes contradictions sont les bienvenues.

Tiens j'avais pas fait gaffe:

All of these figures were obtained using my libc-bench suite, in UTF-8 locales, on one particular Intel Atom N280-based machine. They are not intended to be rigorous, only to give a rough idea of relative order-of-magnitude performance.

Ça me paraît assez bancale comme benchmark, la glibc contient beaucoup de code et optimisations qui sont spécifiques à certaines architectures, les résultats varieraient probablement beaucoup selon les machines.

Quel rapport ? pagefile.sys ce n'est pas la swap de linux, même si la fonctionnalité est la même, la techno et les paradigmes de l'OS sont eux bien différents. Je suis désolé, mais je dois dé-pertinenter ton commentaire.

(PS je ne disais pas qu'utiliser de la swap est marginal, mais le fait de ne pas la mettre sur sa propre partition).

Oui tout à fait, ça semble très différent de la dernière fois que je l'ai consulté, mais musl a eu le temps de mûrir ces dernières années !

Oui c'est vrai, ça manque de documentation, déjà tu peux essayer de manger ça: http://www.etalabs.net/compare_libcs.html

D'ailleurs, de ce que je vois, l'aspect performance ne semble plus être vrai à l'heure actuelle, musl à des résultats qui semblent très proches de la glibc.

Je ne sais pas si c'est représentatif, mais on peut rechercher les CVE pour la sécurité: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=musl vs http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=glibc avec encore une fois un résultat qui me contredit. Mais c'est à prendre avec des pincettes pour deux raisons:

• l'engouement pour musl est relativement récent comparé à la durée de vie du projet glibc,
• ensuite il faudrait comparer par gravité / type de CVE,
• il faut garder en tête que musl il y a peu était encore beaucoup moins utilisé que glibc, moins de trous trouvés ne veut pas dire moins de trous tout court.

Ensuite, je ne fait que reporter sûrement avec beaucoup d'imprécisions ce que d'autres m'ont dit (enfin, des gens en qui j'ai confiance et qui font de l'infra).

EDIT: Ah et j'aime beaucoup exagérer, quand je dis "90% du temps" il faut entendre "parfois" :)