Post to Facebook
Tweet about this
Share at LinkedIn
Invite participants
Reference this page
Moi-meme - Par ailleurs, à quoi sert exactement la table "versions" ? Chez moi elle fait plus de 12mo, c'est beaucoup. N'y a-t-il pas moyen de l'alléger ?
-----
Plugin Firefox : Search (new)
Nouvelles fonctions suggérées <- centralisation perso
l'atelier ordinaire des innovations
Je ne m'attarde pas, j'ai mon yacs en double file...
Yacs on my blog | Suivez le blog Yacs | Yacs Showroom | Plugin Firefox de recherche dans Yetanoz |
Moi-meme - Ok je crois avoir pigé ce qu'est la table "versions" de la base de données. Elle enregistre tout l'historique des modification, pour pouvoir revenir à une version antérieure d'un article (restauration).
Je croyais moi depuis toujours que l'historique disparaissait automatiquement au bout d'un certain temps. Ou alors qu'une purge des éléments cachés de la base l'effacait.
Donc, j'ai 2161 enregistrements dans cette table (v7.6.3), probablement toutes les modif faites depuis... 2006. Je n'ai pas encore regardé si c'était expurgable dans les récentes versions de YACs, mais si tel n'est pas le cas, je suggère vivement cette nouvelle fonction de purge.
En ce qui me concerne je retrouverais une partie des 12Mo que prend cette table...
-----
Plugin Firefox : Search (new)
Nouvelles fonctions suggérées <- centralisation perso
l'atelier ordinaire des innovations
Je ne m'attarde pas, j'ai mon yacs en double file...
Yacs on my blog | Suivez le blog Yacs | Yacs Showroom | Plugin Firefox de recherche dans Yetanoz |
Christian - Une suggestion : ne pourrai-t-on pas automatiser cette purge (ou certaines d'entre elles) avec un cron. Par exemple on pourrait aussi supprimer les articles dans la date de fin de publication est dépassée depuis 1 mois
http://actupro.fr
Actupro
quelques sites yacs : création site internet annuaire pro
Moi-meme - Effectivement ce serait pratique aussi.
Cependant, je ne sais comment tu l'envisages au niveau du choix pour l'associé, mais j'y vois une sorte de confrontation avec Redondance et régularité des dates
-----
Plugin Firefox : Search (new)
Nouvelles fonctions suggérées <- centralisation perso
l'atelier ordinaire des innovations
Je ne m'attarde pas, j'ai mon yacs en double file...
Yacs on my blog | Suivez le blog Yacs | Yacs Showroom | Plugin Firefox de recherche dans Yetanoz |
Moi-meme - A propos des sections qui enegistrent des données automatiquement et grossissent comme des pates à pizza, Yetanoz accuse à ce jour plus de 4000 liens cliqués...
-----
Plugin Firefox de recherche dans Yetanoz
Nouvelles fonctions suggérées <- centralisation perso
Je ne m'attarde pas, j'ai mon yacs en double file...
Yacs on my blog | Suivez le blog Yacs | Yacs Showroom | Plugin Firefox de recherche dans Yetanoz |
Neige1963 - Bonjour,
Depuis quelques jours sur mon site, je reçois parfois des messages "impossible d'accèder au serveur de données" la page étant mystérieusement rédirigé vers /control...
je suppose qu'il y a peut être un souci chez ovh, que j'ai avisé mais j'ai aussi un énorme ralentissement de mon site, pour certaines périodes... ce matin entre autre, il fallait 4 minutes pour ouvrir une page sur mon site!
Je ne sais pas de quoi ça dépend mais ma bd fait 11 mo... j'y ai beaucoup de texte mais si c'est possible de faire plus comme purge je suis preneuse
Entre autre si ce qui a été supprimer est quand même conserver? c'est vrai que j'aimerais bien optimiser ma bd... je n'y connais rien en sql et en php... mais serait il possible de "transférer" certaines données au bout d'un certain temps sur un fichier txt et donc, de récupérer l'espace concerné?
Je fais régulièrement la maintenance et toute les purges proposés dans le panneau de contrôle s'il y a autre chose à faire, je le ferai!
Bonne journée à tous
Neige1963 - re-bonjour
Le problème que j'avais constaté était du à OVH... c'est règlé...
mais pour ce qui est de la base de données, il me conseille que
la base soit indexé et que les requêtes soient optimisées
heu...
Ces opérations sont faites avec l'option "maintenance de la base de données" n'est ce pas?
Est ce que les pros peuvent me dire à quel fréquence il est idéalement recommender de le faire?
Merci
ThierryP - Personnellement, je le fait deux à trois fois par semaine, en fonction des ajouts de contenu qui sont fait.
Les dernière version offre une purge supplémentaire pour "Récupérer l'espace disque inutilisé dans la base de données." (à partir de la 8.5 et fonctionnel depuis la 8.6 si je ne me trompe pas...)
Jamais eu trop de problème avec la DB de mon coté, mais il n'y a pas de communauté, donc des requêtes SQL forcement réduite...
Un annuaire propulsé par YACS - Skins pour Yacs : YordPress - Yacs couleurs Wordpress - Bonbon Skin 1.3.2 : Le graphisme "Green" - Totem 930 : L'équilibre pour petits écrans
Communiqués de Presse : Site de Communiqués de Presse à propulsion Yacs -
Création de sites, Référencement et webmastering - Skins pour Yacs : YordPress - Yacs couleurs Wordpress - Bonbon Skin 1.3.2 : Le graphisme "Green" - Totem 930 : L'équilibre pour petits écrans
Bernard - Neige, je confirme que yacs fait un grand usage des index, et que les requêtes sont pas mal optimisées. Serait-il possible d'avoir quelques indications sur les opérations faites chez ovh pour améliorer les performances de votre site ?
Neige1963 -
Bonjour Bernard,
voici ce qui est recommandé et j'avoue que je n'y comprend pas grand chose...
:
Pourquoi optimiser une base ?
Il faut entretenir sa base de données pour qu'elle soit toujours performante. Ce que l'on entend par performante, c'est le fait que les informations contenues dans la base soient le plus rapidement envoyées au script qui les demande. Pour cela, il faut une base bien structurée et optimisée. Dans ce guide, nous allons vous montrer comment optimiser au mieux votre base.
Sur la base
- Indexer la base :
Pour augmenter la rapidité des recherches lors d'une requête, il faut mettre un index sur les champs qui sont utilisés dans les clauses WHERE.
Exemple :Vous faites une recherche de personne par rapport à la ville. Il faut indexer le champ "ville" avec la requête suivante :
heu... ici, je crois que c'est yacs qui fait ces opérations?
- Purger la base :
Certaines de vos données ne sont plus consultées. Pourquoi ne pas les archiver ? Vos tables seront moins pleines et les recherches iront plus vite.
Bien d'accord à archiver... mais je n'ai aucune idée du comment faire..
Ce qui suit, je ne sais pas ce que je dois faire pour le réaliser.. (désolé...)
Dans les scripts
- Limitation d'affichage :
Limiter l'affichage des enregistrements à un nombre restreint (genre 10 par page) avec la partie LIMIT de la requête.
- Regroupement des requêtes :
Regrouper vos requêtes en debut de script comme cela :
connexion_base
requete1
requete2
...
deconnexion_base
Affichage ...
Traitement des donnees
Boucles ...
Affichage ...
...
- Faire du cache :
Si vous avez des infos qui sont tirées de la db et qui ne changent pas souvent, mettez-les en cache. Par exemple, générez la page html quand vous modifiez les infos, ce genre d'astuce diminuera drastiquement vos accès. Par exemple une page de news. Si le fichier (cache) html existe, vous l'utilisez (simple include) sinon, vous le générez. Et au moment où vous postez une nouvelle news, vous pouvez inclure dans le script qu'il supprime le fichier html : il sera ainsi regénéré la prochaine fois qu'un visiteur la demande. Vous pouvez aussi faire du cache de session. Mettre les résultats de requête en variable de session, après la même requete vous ne l'exécutez plus, vous récupérez les variables de session.
- Prendre uniquement le necessaire :
Dans vos requêtes SQL verifiez que vous ne selectionnez que ce dont vous avez besoin, et surtout que vous n'avez pas oublié les liaisons entre les tables (where table1.champs = table2.champs2) car sinon ça prend énormément de temps (meme si apres avec le where il vous sort un truc correct).
- Eviter les options très gourmandes :
Evitez d'utiliser HAVING c'est aussi une usine à gaz, idem pour GROUP BY. Bien sûr, parfois c'est obligatoire, mais parfois pas.
Neige1963 - Le poblème venait de OVH, ils me l'ont confirmés... et ils l'ont résolu...
Il y a actuellement quelques problèmes de charge sur
l'espace sur lequel vous etes installé, c'est en cours de
résolution. Cela touche aussi bein le FTP que l'accès au
Web.
et la purge de Yacs est efficace ma base faisait 36 mo (je n'ai pas pensé à aller voir, par phpmyadmin ce qui prenait tant de place mais après une purge de tous les points proposé sur la page "purge" ma base est revenu à 11 mo...
mais je vois là que la table members a 6 747 enregistrements!!! après c'est la base articles qui arrive en deuxième avec 1956 enregistrements...
en troisième, la base Links avec 671 enregistements
bref la purge a fait une grande différence de 25 mo!
là, j'ai imprimé le contenu de ma base ... comme ça, je pourrai comparé la prochaine fois..
Comme j'édite beaucoup ces temps ci, il faut que je purge plus souvent... et je fais aussi la maintenance de la base de donnée, une fois par semaine...
Bernard - Il n'y a pas que le nombre d'enregistrements à regarder. La taille de chaque enregistrement est aussi importante.
Pour la table des liens, potentiellement mise à jour par apport extérieur (importation RSS, trackback, ou simple clic), la version 8.6 apporte deux améliorations majeures :
- Meilleure contrôle de la limite à 1000 liens extérieurs. Le test de purge effectué précédemment était pris en défaut lors qu'un même lien est mentionné dans plusieurs importations successives. Le résultat, c'est une table des liens qui grossit au fur et à mesure de l'intération RSS. Un autre test est mis en oeuvre dans la version 8.6 pour faire une chasse impitoyable aux liens extérieurs surnuméraires.
- Par sécurité, une commande de purge additionnelle est fournie dans le panneau de contrôle pour éliminer d'un coup tous les liens extérieurs.
Le résultat, visible sur le panneau de contrôle de ce site, est une réduction drastique de la table des liens.
