Comment servir efficacement des sitemaps massifs dans django

Question

J'ai un site avec environ 150K pages dans son sitemap. J'utilise le générateur d'index sitemap pour créer les sitemaps, mais en réalité, j'ai besoin d'un moyen de le mettre en cache, car construire 150 sitemaps de 1000 liens chacun est brutal sur mon serveur. [1]

JE POURRAIT mettre en mémoire cache chacune de ces pages sitemap avec memcached, ce que j'utilise ailleurs sur le site ... cependant, il y a tellement de sitemaps qu'il remplira complètement memcached .... de sorte que doesn ' t travail. Ce dont je pense avoir besoin, c'est d'un moyen d'utiliser la base de données comme cache pour ceux-ci, et de ne les générer que lorsqu'ils sont modifiés (ce qui signifie que l'index du sitemap ne change que le dernier plan du sitemap). pages, puisque le reste est toujours le même.) [2] Mais, aussi près que je peux le dire, je ne peux utiliser qu'un backend cache avec django.

Comment puis-je préparer ces sitemaps lorsque Google est lancé sans tuer ma base de données ou memcached?

Des pensées? [1] Je l'ai limité à 1 000 liens par page de sitemap car générer le maximum de 50 000 liens ne fonctionnait pas.

[2] par exemple, si j'ai sitemap.xml? Page = 1, page = 2 ... sitemap.xml? Page = 50, je n'ai vraiment besoin de changer sitemap.xml? Page = 50 jusqu'à ce qu'il est plein de 1000 liens, alors je peux à peu près ce pour toujours, et se concentrer à la page 51 jusqu'à ce qu'il soit plein, cache à jamais, etc.

EDIT, 2012-05-12: Cela a continué d'être un problème , et j'ai finalement abandonné le framework sitemap de Django après l'avoir utilisé avec un cache de fichiers pendant environ un an. Au lieu de cela, j'utilise maintenant Solr pour générer les liens dont j'ai besoin dans une vue très simple, et je les passe ensuite au modèle Django. Cette considérablement simplifié mes sitemaps, les a fait fonctionner très bien, et je suis à environ 2,250,000 liens dès maintenant. Si vous voulez faire cela, il suffit de consulter le modèle de sitemap - tout est vraiment évident à partir de là. Vous pouvez voir le code pour cela ici:

Answer 1

J'ai rencontré un problème similaire et j'ai décidé d'utiliser django pour écrire les fichiers sitemap sur le disque dans le média statique et de les faire servir par le serveur Web. J'ai fait l'appel pour régénérer le sitemap toutes les deux heures puisque mon contenu ne changeait pas plus souvent que cela. Mais cela dépendra de votre contenu à quelle fréquence vous devez écrire les fichiers.

J'ai utilisé une commande personnalisée django avec un travail cron, mais le curl avec un travail cron est plus facile.

Voilà comment je CURL, et je l'ai envoyer apache /sitemap.xml comme un fichier statique, et non par django:

curl -o /path/sitemap.xml http://example.com/generate/sitemap.xml 

Answer 2

Bon - je l'ai trouvé un peu plus d'informations sur ce sujet et ce que amazon faites avec leurs 6 millions ou plus d'URL.

Amazon simplement faire une carte pour chaque jour et y ajouter:

1. nouvelles urls
2. urls mis à jour

Cela signifie donc qu'ils finissent avec des charges de-cartes du site - mais le robot de recherche ne regarde que les plus récents - car les dates mises à jour sont récentes.J'étais sous la compréhension que l'on devrait rafraîchir une carte - et ne pas inclure une URL plus d'une fois. Je pense que cela est vrai. Mais, Amazon contourner cela comme les cartes du site sont plus d'un journal. Une URL peut apparaître dans une carte de site plus récente - car elle peut être mise à jour - mais Google ne regardera pas les cartes plus anciennes car elles sont périmées - à moins bien sûr que ce soit un ré-index majeur. Cette approche prend tout son sens car tout ce que vous faites est simplement de construire une nouvelle carte - dire chaque jour de contenu nouveau et mis à jour et ping sur google - donc Google n'a besoin que d'indexer ces nouvelles URL.

Cette approche de journalisation est synch à coder - tout ce dont vous avez besoin est un modèle de magasin de données statique qui stocke les données XML pour chaque carte. votre travail cron peut construire une carte - quotidienne ou hebdomadaire et ensuite stocker la page XML brute dans un champ blob ou quoi que ce soit. vous pouvez ensuite servir les pages directement à partir d'un gestionnaire et aussi la carte d'index aussi. Je ne suis pas sûr de ce que les autres pensent, mais cela ressemble à une approche très pratique et un chargement de son serveur - par rapport à la reconstruction de l'énorme carte juste parce que quelques pages peuvent avoir changé. J'ai aussi considéré qu'il était possible de calculer une semaine de cartes en une semaine et 4 semaines de cartes en un mois - donc vous vous retrouvez avec des cartes mensuelles, une carte pour chaque semaine dans le courant mois, puis une carte pour les 7 derniers jours. En supposant que les dates sont toutes maintenues, cela réduira le nombre de cartes en rangeant le processus - im pensant en termes de réduction de 365 cartes pour chaque jour de l'année à 12.

Voici un pdf sur les cartes du site et le approches utilisées par Amazon et CNN.

http://www2009.org/proceedings/pdf/p991.pdf

Answer 3

J'utilise django-staticgenerator application pour la mise en cache de sitemap.xml au système de fichiers et mettre à jour ce fichier lorsque les données mises à jour.

settings.py:

STATIC_GENERATOR_URLS = (
    r'^/sitemap', 
) 
WEB_ROOT = os.path.join(SITE_ROOT, 'cache') 

models.py:

from staticgenerator import quick_publish, quick_delete 
from django.dispatch import receiver 
from django.db.models.signals import post_save, post_delete 
from django.contrib.sitemaps import ping_google 

@receiver(post_delete) 
@receiver(post_save) 
def delete_cache(sender, **kwargs): 
    # Check if a Page model changed 
    if sender == Page: 
     quick_delete('/sitemap.xml') 
     # You may republish sitemap file now 
     # quick_publish('/', '/sitemap.xml') 
     ping_google() 

Dans la configuration nginx rediriger sitemap.xml dans le dossier de cache et django instance pour fallback:

location /sitemap.xml { 
    root /var/www/django_project/cache; 

    proxy_set_header X-Real-IP $remote_addr; 
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 
    proxy_set_header Host $http_host; 

    if (-f $request_filename/index.html) { 
     rewrite (.*) $1/index.html break; 
    } 
    # If file doesn't exist redirect to django 
    if (!-f $request_filename) { 
     proxy_pass http://127.0.0.1:8000; 
     break; 
    }  
} 

Avec cette méthode, sitemap.xml sera toujours mis à jour et les clients (comme google) obtient le fichier xml toujours de manière statique. C'est cool je pense! :)

Answer 4

Pour ceux qui (pour une raison quelconque) préfèrent garder leurs sitemaps dynamiquement générés (par exemple, la fraîcheur, la paresse). Essayez django-sitemaps. C'est une version en streaming des sitemaps standard. Remplacement Drop-in. Temps de réponse beaucoup plus rapide et utilise moins de mémoire.