En fait, le mod est fait pour construire des liste énormes. Il a été testé sur des listes de pus de 15 000 url :

Premier affichage, avec construction du cache :

Code: Tout sélectionner

<!-- URL list generated in  5.04085 s  - 29 sql - 16092 URLs listed -->
<!--  Output started from cache after 5.04821 s -  sql -->
<!--  Output from cache ended up after 6.55133 s -  sql -->

Premier affichage, depuis le cache :

Code: Tout sélectionner

<!-- URL list generated in  5.04085 s  - 29 sql - 16092 URLs listed -->
<!--  Output started from cache after 0.00191 s -  sql -->
<!--  Output from cache ended up after 2.22686 s -  sql -->

La première ligne n'étant pas mis à jour, c'est le temps qu'il a fallu pour faire le cache la première fois. Il a effectivement fallu 0.00191 s de travail avant de commencer à envoyer le cache dans ce cas, le fichier en cache pèse tout de même 3.25Mo sans compression gunzip. Il ne pèse plus que 383ko avec la compression, ce qui accélère d'autant l'envoi du fichier (ici plus de 2 seconde pour 3.25Mo) qui est envoyé tel quel (c'est le navigateur qui décompresse).

A noter également qu'il s'agit d'un test en mod rewrite avancé, le plus lourd donc, mais le serveur test est puissant.

Donc, le truc, c'est qu'on ne peut pas faire un requête sur 16092 sujet d'un coup, alors on découpe en plusieurs requêtes. C'est ça les cycles SQL.

Un cycle de 200 fera des requêtes sur 200 sujet à la fois, soit 5 requêtes pour lister 1000 sujets.
Modifier ce paramètre n'influence pas les sujets listé, simplement la façon de construire la liste.
Le truc est donc d'activer l'affichage des stat du module, sans compression gunzip pour les voir tous, et sans cache pour voir le résultats des modifs en cours, et de jouer un peut avec ces paramètres.
Il faut lister le plus d'éléments possible tout en ne dépassant pas les 50 requêtes et 7/8secondes pour la génération du cache.
Ces réglages sont spécifiques à chaque config, ils permettent de tirer le meilleur de chaque serveur.

Ensuite, la limite absolue de 2500 par défaut, c'est déjà pas mal. Cela veut dire que tu listera les 2500 dernier sujets actifs de chaque forum, c'est une limite par plan de site, pas pour l'ensemble de ceux ci.

Les réglages par défaut devrait convenir à tous les forums, et en tous cas, il est inutile de les modifier si tu n'as pas plus de 2500 sujets dans au moins un de tes forums.

Pour rss et urllist, le principe est le même, sauf que le but n'est pas de lister autant d'urls. Le module permet aisément de lister plusieurs milliers d'éléments dans les flux rss, mais bon, personne n'utilise des flux avec autant d'url, quelque centaine devrait convenir dans la plupart des cas.
La seul différence est qu'il y a pour les flux rss des réglages de cycles différents pour les flux avec et sans messages, cela permet de mieux régler car d'afficher les messages est notablement plus lourd que simplement afficher les flux et on peut donc affiner nos limites au mieux pour les deux types de flux, avec ou sans messages.

Pour la durée du cache, c'est comme tu veux, 1 heure pour les flux rss mes parait amplement suffisant, pas la peine de descendre en dessous.

++

Le cycle sert a adapter la charge serveur et permet de découper les requetes mysql pour construire les listes

une doc en cours de rédaction a écrit:Cycle SQL
Comme il n'est pas question de faire une seule requête SQL qui devrait ramener des milliers de résultats d'un coup lors de la génération de listes conséquentes, le procédé est divisé en cycles. On multiplie le nombre de requêtes sql pour ne pas surcharger le serveur. Le paramètre cycles sql vous permet d'influer sur cette répartition de charge. Le réglage par défaut est de 200 éléments ramenés en une requête sql, ce qui signifie qu'une liste de 1000 éléments au total sera étalée en 5 requêtes pour la seule récupération des éléments. Si vous voulez alléger la charge de votre serveur, vous pouvez augmenter le nombre d'itérations en diminuant le nombre de résultats récupérés en un cycle SQL (mettre moins que 200)

--> on ne fait bien que des groupes de 200, on ne perd aucune info.

la meme doc non encore disponible a écrit:Limite URLs
Il s'agit d'un nombre maximal d'adresses que peut contenir un plan de site google. La limite "physique" imposée par le standard sitemap est de 50 000 adresses. Chaque sitemap individuel peut donc contenir jusqu'a 50000 urls. D'où l'avantage de subdiviser vos plans, comme le fait le mod GYM sitemaps en créant un sitemap par forum, ce qui permet d'avoir au total plus que 50000 urls, ce qui ne serait pas possible avec un seul sitemap.
Ce paramètre vous permet donc tout autant que le précédent de maîtriser la charge de votre serveur, car évidemment, plus vous demanderez d'urls dans un plan de site, plus longue sera la génération de la liste en question.

La limite de 2500 (par défaut) est un peu légère non? Ne faudrait-il pas la monter? ... Car si je comprends... Plus tard, si j'ai plus de 2500 Urls dans mon sitemap google.... Les plus anciennes seront supprimées non?

N'oublie pas qu'il s'agit d'une limite par forum, vu que chaque sitemap ne traite qu'un seul forum.
Apres on part du principe que les vieilles urls qui ne se retrouveraient eventuellement plus dans la sitemap maintenant (car elle ne sont plus dans les 2500 premieres) ont deja été indexées précedemment, car elles étaient dans un sitemap il y a x semaines/mois.

Evidemment, si tu as plus de 2500 urls par forum et que tu viens d'installer GYM, une facon de faire indexer tous les topics est d'augmenter la limite de 2500 urls par forum. Mais apres, tu peux la baisser.

Durée du cache : c'est un arbitrage. Si google ne reclamme le sitemap que tous les 3 jours, pas la peine de mettre une durée de validité que de 6 heures. Au contraire si google réclamme le sitemap plus frequemment, faut baisser la paramètre. Tout dépend en fait de la fréquence de passage de google sur ton site.

Pour les flus rss, si on s'inscrit donc un cadre plus orienté vers l'utilisateur (et non pas le moteur de recherche), le mieux est d'avoir des flux raffraichis le plus frequemment possible, sans pour autant surcharger le serveur.




edit : GRRRRRRRRRRRRRRRRRRRRRRRRRRR !

Pour le coup, on peut pas vraiment faire pus complet comme réponse

Et ben dis donc.... C'est vrai qu'on ne peut pas vraiment mieux faire ^^

1) Bon Donc si je comprends bien... le nombre max d'élément que j'ai actuellement pour le flux rss (dans la configuration par défaut) est de 100 ==> Limite par défaut = 100 .... Est-ce celà? Si jamais j'ai tort ... Quelle est l'option qui limite les "éléments" dans le flux rss (si il y en a une... Car je me demande aussi si ce n'est pas simplement en fonction de la durée ==> 60 jours )

Après pour ce qui est histoire de liste longue / courte je ne vois pas trop la différence car je n'utilise pas le flux rss (et je sais pas trop à quoi ça correspond ^^ ).... Donc j'ai désactivé tout ca... Est-ce que vous me conseillez tout de même d'activer "Listes longues" , "Autoriser les Flux Courts", "Autoriser les Flux Longs" ?

2) Un autre question ^^ .... Est-ce que je dois activer la compression G-zip pour GYM sitemaps dans "configuration générale"? (quelle est la différence de cette compression? Le serveur travaillera "plus"? "moin"? ... Celà change quoi exactement?) ...
Si jamais vous me conseillez de l'activer... Je dois la mettre à quelle niveau?


Car voici mon soucis principal: Je n'aimerais pas que 1&1 me coupe mon compte car j'utilise trop la BD ... Tout en ayant les capacité de GYM sitemaps au maximum des possibilité de ma BD ...

Voici ce que dis 1&1 au niveau de la base de données:

Une base de données MySQL ne doit en aucun cas être utilisée pour des évaluations de log, des clics publicitaires, des systèmes de chat, des systèmes de rotation de bannières, ou toute autre application qui pourrait encombrer votre base de données de charges trop importantes. ..... Car eslle est placée sur un serveur dédié patati patata

Merci à vous ^^

Bon W-E

oui, pour les limites rss, la limite par défaut est celle des flux par défaut sans texte, il y a son pendant avec texte, et la limite temporelle s'y ajoute.

Listes longues et courtes, c'est pas super primordial, ça peut servir pour par exemple construire un série de flux de 10 liens pour justement afficher des listes de liens (avec magpie par exemple), et des listes plus longues dans le cas général.
C'est le genre d'option que l'on est surtout content d'avoir quand on en a l'usage (sic).

La compression gunzip est une sérieuse économie de ressource pour peu que tes flux soit un minimum utilisés.
Le serveur travail juste un peu plus (pas grand chose) pour compresser le cache, mais ensuite, il envoie dix fois moins de données lors des lectures de celui ci, et là, ça gagne à chaque affichage. C'est le navigateur qui décompresse.
Tant qu'a la mettre, autant la mettre à 9 je dirais.

Question requêtes sql, avec le cache, ce mod est vraiment ton ami. Toutes les requêtes servant à construire la liste sont évités quand on lit le cache.

Donc, si tu as des craintes, ne fait pas de trop grosse listes, (2500 c'est assez petit pour les sitemaps ) et ne régénère pas ton cache trop souvent, plan de site Google une fois par jour, c'est en général largement suffisant, pour les flux rss, bon, ça dépends, je ne trouve pas que deux ou trois heures (voir plus ) de délais soit si important, ça dépend de l'utilisation.

++

dcz a écrit:Tant qu'a la mettre, autant la mettre à 9 je dirais.

Hum, pas vraiment. Le gain devient de plus en plus marginal.
Tests effectués avec un fichier de départ de 2322 url soit 489 Ko :

sans compression :
URL list generated in 0.93257 s ( Mem Usage : 556.05 Kb ) - 19 sql - 2322 URLs listed
489 Ko

compression :
0 :
URL list generated in 0.89890 s ( Mem Usage : 556.06 Kb ) - 19 sql - 2322 URLs listed
489 ko

1:
URL list generated in 0.89559 s ( Mem Usage : 556.06 Kb ) - 19 sql - 2322 URLs listed
70 Ko

2:
URL list generated in 0.90054 s ( Mem Usage : 556.06 Kb ) - 19 sql - 2322 URLs listed
68 Ko

3:
URL list generated in 0.93337 s ( Mem Usage : 556.06 Kb ) - 19 sql - 2322 URLs listed
67 Ko

4:
URL list generated in 0.89912 s ( Mem Usage : 556.06 Kb ) - 19 sql - 2322 URLs listed
62 Ko

5:
URL list generated in 0.92979 s ( Mem Usage : 556.06 Kb ) - 19 sql - 2322 URLs listed
61 Ko

6:
URL list generated in 0.90148 s ( Mem Usage : 556.06 Kb ) - 19 sql - 2322 URLs listed
60 Ko

7:
URL list generated in 0.95228 s ( Mem Usage : 556.06 Kb ) - 19 sql - 2322 URLs listed
59 Ko

8:
URL list generated in 1.06799 s ( Mem Usage : 556.06 Kb ) - 19 sql - 2322 URLs listed
59 Ko

9:
URL list generated in 0.90604 s ( Mem Usage : 556.06 Kb ) - 19 sql - 2322 URLs listed
58 Ko