[Problème] architecture nbr dossiers données images pour ne pas ralentir le site

[herve]

Bonjour,
Pour un site documentaire associatif en développement, je réfléchis à l'architecture des données quand le site comportera un grand nombre de ressources: plusieurs milliers de livres, films ...
Je m'aperçois que les images en différentes résolution sont stockées dans un dossier par article (custom fields plugin econa).

Théoriquement les systèmes hébergés sous Linux peuvent contenir plusieurs milliers de répertoires sous un répertoire mais je me pose des questions sur le temps d'accès ou autres problèmes notamment dans le cas ou le trafic devient important sur ces milliers de ressources!

Si problème avez-vous des pistes à suggérer avant de continuer à intégrer des fiches ressources ?

[lefabdu51]

Pour moi, l'impact serait visible si les éléments de contenu tels que les images seraient en base de données (image encodées en base64).Si ce sont des répertoires, il n y a pas de grandes latences au niveau des temps d'accès.

[woluweb]

bon, pour le volet Econa, ne l'utilisant pas je peux pas dire

mais de manière générale :
- imagerecycle.com qui peut être intégré à Joomla pour optimiser les images
- Dimitris "Grammatikos" a sorti tout récemment un plugin qui me semble super intéressant (mais que j'ai pas encore eu le temps de tester) : https://ttc-freebies.github.io/plugi...sive-images/#/

Pour le citer :

So there you have it: plugin #Joomla Responsive images got a total refactor. V3.0.0-beta:
- Support WebP
- Outputs picture elements
- Allows to use the code in any Component/ Module/ Template
- J4 ready
- Serves hot #performance gains fro free

[lefabdu51]

Apres, la limite est l'espace disque disponible. Regardes ce que les images pour un article occupe comme espace disque. Ensuite divise l'espace disponible par ce chiffre et tu sauras si tu doit modifier ton hébergement. C'est la ou cela peut coincer.

[herve]

Bonsoir,
lefabdu51
Ok cela me rassure; Effectivement il faudrait que je calcule l'espace total mais cela me semble moins problématique qu'un problème de performance du à lecture du répertoire globale lié à Econa.
Je lui ai demandé si c'était possible d'intégrer des sous répertoires en lien avec la catégorie de l'article mais cela ne l'intéresse pas car demande trop spécifique

woluweb
Oui j'utiliserai aussi imagerecycle par contre je n'ai pas compris le plugin, il n'a pas de page de présentation ou démo? Il s'agit aussi d'un équivalent pour compression d'image ? car ce n'est pas mon soucis pour l'instant

Merci à vous

[daneel]

Bonjour,

Je trouve assez surprenant l'idée d'avoir un repertoire par article, cela n'apporte rien de bon mais ce n'est que mon avis.

Le fait d'avoir plusieurs vignettes d'une même image peut représenter une taille assez impressionnante au fil des années. Je l'ai vu sur plusieurs sites, aussi bien pour un centre de documentation que pour une association qui conserve des galeries photos sur plusieurs années.

Pour des sites de plusieurs Gigas, j'ai fait le choix de delocaliser les ressources sur un autre espace, géré en sous-domaine CDN, avec un temps plus espacé entre les sauvegardes (1 par semaine). chaque site et leur base de données sont sauvegardés quotidiennement (la rétention étant sur 6 jours). Ce choix de deplacer les medias en sous-domaine est simplement du au fait que les sites que j'héberge sont sur des disques durs SSD ultra rapide mais la capacité est limitée contrairement à l'espace en sous-domaine.

Le plus important dans l'immédiat, c'est de définir le nombre de vignettes à ce qui est nécessaire. Le système de srcset me semble plus simple à gérer notamment avec le plugin de Dimitris (avec le support de webp) mais comme il est assez récent, il faut le tester !

En résumé, il ne faut pas se prendre la tête dans l'immédiat. Commencez par centraliser les medias en évitant de génerer des repertoires et fichiers inutiles. Des que les sauvegardes ont atteint une taille critique (par rapport à l'espace disponible), commencez par distinguer les repertoires afin d'exclure les medias de la sauvegarde quotidienne. Le fait d'améliorer en sous-domaine ou autre pourra toujours se faire par la suite (tout en conservant la qualité du référencement).

[herve]

Bonjour

Je trouve assez surprenant l'idée d'avoir un repertoire par article, cela n'apporte rien de bon mais ce n'est que mon avis.

Moi cela ne me choque pas. Ma crainte étant a court terme de partir avec la bonne architecture impossible a changer au bout de quelques années s'il y a plusieurs milliers d'articles.

Le fait d'avoir plusieurs vignettes d'une même image peut représenter une taille assez impressionnante au fil des années. Je l'ai vu sur plusieurs sites, aussi bien pour un centre de documentation que pour une association qui conserve des galeries photos sur plusieurs années.

Pour des sites de plusieurs Gigas, j'ai fait le choix de delocaliser les ressources sur un autre espace, géré en sous-domaine CDN, avec un temps plus espacé entre les sauvegardes (1 par semaine). chaque site et leur base de données sont sauvegardés quotidiennement (la rétention étant sur 6 jours). Ce choix de deplacer les medias en sous-domaine est simplement du au fait que les sites que j'héberge sont sur des disques durs SSD ultra rapide mais la capacité est limitée contrairement à l'espace en sous-domaine.

Le plus important dans l'immédiat, c'est de définir le nombre de vignettes à ce qui est nécessaire. Le système de srcset me semble plus simple à gérer notamment avec le plugin de Dimitris (avec le support de webp) mais comme il est assez récent, il faut le tester !

En résumé, il ne faut pas se prendre la tête dans l'immédiat. Commencez par centraliser les medias en évitant de génerer des repertoires et fichiers inutiles. Des que les sauvegardes ont atteint une taille critique (par rapport à l'espace disponible), commencez par distinguer les repertoires afin d'exclure les medias de la sauvegarde quotidienne. Le fait d'améliorer en sous-domaine ou autre pourra toujours se faire par la suite (tout en conservant la qualité du référencement).

Je n'en suis pas là mais je note cela
Je resitue quand même le contexte car j'ai fais un certain nombre de sites pour assos ou newbie et je n'avais pas envie de reproduire le problème d'emplacement, taille ou absence d'image sur un site avec potentiellement un grand nombre d'articles crées ou modifiés par ce type de profil

C'est pour cela que je suis parti sur un composant de cache qui intègre imageRecycle. Cela fonctionne plutôt bien et me donne satisfaction. Au début au moins, le problème de taille ne devrait pas être pénalisant.
J'ai ensuite choisi le plugin econa car il me permet de rendre obligatoire la saisie d'une image (reste à moi un ... jour de mieux la positionner dans le rendu d'un layout?)
l'intérêt aussi c'est que l'on peut paramétrer assez finement les vignettes générés par type (blog, article, modale ...). Ce qui explique le répertoire par article.
Après j'ai demandé à l'auteur un paramètre pour imposer un minimum et un maximum de la taille de l'image. Dans sa roadmap mais à priori pas dans les priorités des webmasters!?

J'ai l'impression que le plugin dont vous parlez du plugin gratuit Dimitris* qui optimise la taille mais ne résout pas les besoins dont j'ai parlé sauf erreur de ma part.
@+
*mais j'avais vu aussi https://onlinecommunityhub.nl/joomla...sponsiveimages en général je privilégie les plugins payants car j'ai l'impression d'une maj plus fréquente et c'est un petit soutien au dev'