Merci pour ce retour, j'ai testé sur vos conseils et il y a une tonne de conseils comme compresser, désactiver des fonctions..., je ne sais pas par quoi commencer et comment procéder pour ne pas faire plus de dégâts que la lenteur constatée aujourd'hui sachant que le problème viens surtout sur une lenteur importante lors d'une requête d'affichage d'une donnée pointant sur cette base de 130 000 items.
Là je sèche
Effectivement, impressionnant !
Néanmoins,
avec, selon PageSpeed, une page moyenne à 2 Mo, tu peux déjà alléger le poids des images et ensuite le poids additionné des fichiers CSS et JS par une compression Gzip.
La compression gzip est souvent intégrée dans l'admin des templates Yootheme.
Google recommande aussi d'activer le cache. Mais, sur ce sujet, les avis et expériences sont très partagés.
Un message d’erreur sur votre site Joomla ... ayez le reflexe de consulter lla base de connaissance : https://kb.joomla.fr
J'ai activé la compression GZIP au niveau du template et dans l'administration du CMS mais pas de résultat. Le problème de lenteur ne se produit quelorsque l'on requête sur la page qui affiche la base de données, le reste des rubrique est réactif et présent un affichage quasi instantané.
L'appli utilisée demande d'activer l'extension: Alternative PHP Cache (APC) et de paramétrer PHP Realpath Cache au delà de 512 k
Là ça se complique. Mon cms tourne sur 1 dédié 1&1
Là je sèche
SC
* si je vais sur
hortus-botanique.fr/index.php/fr/travaux-du-mois/category/septembre
Ca ne charge pas super rapide.
Allège au moins tes images de fond.
Une liste récente de compresseurs d'images en ligne :
Page weights have been spiralling out of control in recent years. Ada looks at 5 online image compression tools that might help get your pages in shape.
Quelle est la différence de construction entre "Glossaire botanique" et "Base Botanique". Hormis le volume d'entrée des données.
Le premier est nettement + rapide en chargement.
Un message d’erreur sur votre site Joomla ... ayez le reflexe de consulter lla base de connaissance : https://kb.joomla.fr
En réponse à la première question, la requête est bien sur le serveur hébergeant le site.
Les 2 thèmes "glossaire" et "Base botanique" sont construits avec la même appli jbzoo et paramétrés de la même manière. Je reste convaincu que c'est le tri dans la grande quantité de données qui pose problème.
Cdlt,
SC
Je reste convaincu que c'est le tri dans la grande quantité de données qui pose problème.
Alors suis la piste donnée par @lefabdu51 sur les réglage du serveur via les directives de php.ini
Comme :
PHP: Description of core php.ini directives - Manual
Je ne trouve pas le php.ini! en fait il y en a certainement plusieurs il faut trouver le bon
Dans la doc jbzoo, il me semblait que l'indexation était automatique lors d'insertions des nouvelles donnée, bon je vais réindexer, ça ne coûte rien.SC
Je ne trouve pas le php.ini! en fait il y en a certainement plusieurs il faut trouver le bon
Dans la doc jbzoo, il me semblait que l'indexation était automatique lors d'insertions des nouvelles donnée, bon je vais réindexer, ça ne coûte rien.SC
Quelles sont les tailles précides des 2 bases en question ?
Suivant les cas, il peut être nécessaire d'agir au niveau du paramétrage MySQL pour optimiser les grandes tables (ou si en hébergementg mutualisé, tenter d'obtenir un serveur SQL privé, configurable)
Pas de demande de support par MP.
S'il n'y a pas de solution, c'est qu'il n'y a pas de problème (Devise Shadok)
La + grosse table fait 207 Mo.
J'ai vu dans les conseils de paramétrage qu'il était conseillé d'installer sur mon serveur dédié "apc-alternative-php-cache-", je suppose que cela ne peut se faire qu'en ligne de commande via ssh?
J'ai accès aux tables via php myadmin sur quel paramètre il faut intervenir pour optimiser?
Cdlt
SC
S'agissant d'un serveur dédié, il y a une distribution Linux, et donc pour installer des paquets genre php-apc, utiliser le gestionnaire de paquets de la distribution (apt-get pour les debian et dérivés genre Ubuntu, yum pour les RHEL et dérivés CentOS ou Fedora ou zypper pour opensuse ou dérivés).
Pour la maintenance d'un serveur dédié, il faut également installer les mises à niveau de paquets, le tout bien entendu via ssh. Suivant la distribution ce sera apt-get update, yum update ou zypper up qu'il faut utiliser.
La configuration de PHP globalement est en général en /etc/php.ini (RHEL et dérivés) ou /etc/php5/apache2/php.ini, selon la distribution concernée.
Pour l'optimisation de MySQL, avec une table (MyISAM ou InnoDB ?) de plus de 200 mégas, il vaut mieux utiliser le modèle de configuration de type medium.
Ces modèles de configuration sont en général dans /usr/share/doc/mysql
Pour optimiser MySQL, reprendre chaque paramètre et l'ajuster aux besoins. Attention, avec les versions récentes de Joomla!, de très nombreuses extensions (et Joomla! lui même depuis la version 3) utilisent le storage engine InnoDB, et non plus MyISAM. Bien vérifier tous les paramètres de cet engine dans le fichier my.cnf, en particulier les autogrow, chunks, etc.
Ces configurations se font via ssh, en pensant à redémarrer les services concernés après chaque modification (service restart httpd ou service restart apache2 après modifications du php.ini ey service mysql restart ou service mysqld restart pour mysql)
Pas de demande de support par MP.
S'il n'y a pas de solution, c'est qu'il n'y a pas de problème (Devise Shadok)
par contre, desactives le cache joomla si tu utilise le cache apc...
Sinon tu peut avoir des conflits entre les deux et cela va conduire au resultat inverse (2 systeme de cache sur un site, c est comme deux antivirus sur un pc, c est pas du tout recommandé).
Commentaire