Cómo servir eficientemente los mapas de sitio masivos en django

Question

Tengo un sitio con aproximadamente 150,000 páginas en su mapa del sitio. Estoy usando el generador de índices del mapa del sitio para hacer los mapas de sitio, pero en realidad, necesito una forma de almacenarlo en la memoria caché, porque crear 150 mapas de sitio de 1,000 enlaces cada uno es brutal en mi servidor. [1]

PODRÍA guardar en caché cada una de estas páginas del mapa del sitio con memcached, que es lo que estoy usando en otra parte del sitio ... sin embargo, este es un gran número de sitemaps que llenarían completamente memcached ... entonces eso no t trabajo.

Lo que creo que necesito es una forma de utilizar la base de datos como caché para ellos, y solo generarlos cuando hay cambios en ellos (lo que como resultado del índice de sitemap significa solo cambiar los últimos par de sitemap páginas, ya que el resto son siempre las mismas.) [2] Pero, por lo que puedo decir, solo puedo usar un backend de caché con django.

¿Cómo puedo tener estos sitemaps listos para cuando Google venga a rastrear sin matar mi base de datos o memcached?

¿Alguna idea?

[1] Lo he limitado a 1,000 enlaces por página de sitemap porque generar el máximo, 50,000 enlaces, simplemente no estaba sucediendo.

[2] Por ejemplo, si tengo sitemap.xml? Page = 1, page = 2 ... sitemap.xml? Page = 50, solo necesito cambiar sitemap.xml? Page = 50 hasta que está lleno con 1,000 enlaces, entonces puedo hacerlo casi para siempre, y enfocarme en la página 51 hasta que esté lleno, almacenarlo en caché para siempre, etc.

EDITAR, 2012-05-12: Esto ha seguido siendo un problema , y finalmente abandoné el marco de mapa de sitio de Django después de usarlo con un caché de archivos durante aproximadamente un año. En cambio, ahora estoy usando Solr para generar los enlaces que necesito en una vista realmente simple, y luego los paso a la plantilla de Django. Este enormemente simplificó mis sitemaps, los hizo funcionar muy bien, y hasta ahora tengo hasta 2,250,000 enlaces. Si quieres hacer eso, solo echa un vistazo a la plantilla del mapa del sitio; todo es realmente obvio a partir de ahí. Puede ver el código aquí: https://bitbucket.org/mlissner/search-and-awareness-platform-courtlistener/src/tip/alert/casepage/sitemap.py

Answer 1

Tuve un problema similar y decidí usar django para escribir los archivos del mapa del sitio en el disco en el medio estático y hacer que el servidor web los sirva. Hice la llamada para regenerar el mapa del sitio cada dos horas ya que mi contenido no cambiaba más a menudo. Pero dependerá de su contenido con qué frecuencia necesita escribir los archivos.

Utilicé un comando personalizado django con un trabajo cron, pero curl con un trabajo cron es más fácil.

Así es como yo uso rizo, y Apache he enviar /sitemap.xml como un archivo estático, no a través de Django:

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

Answer 2

bien - He encontrado algo más de información sobre este y lo que Amazon está haciendo con sus 6 millones o así URLS.

Amazon simplemente hacer un mapa para cada día y añadir a ella:

1. nuevas direcciones URL
2. URLs actualizados

Así que esto significa que terminan con un montón de-mapas de sitio - pero el bot de búsqueda solo verá los últimos, ya que las fechas actualizadas son recientes.Estaba enterado de que uno debe actualizar un mapa y no incluir una url más de una vez. Creo que esto es verdad Pero, Amazon lo soluciona ya que los mapas del sitio son más un registro. Una url puede aparecer en un mapa del sitio posterior, tal vez actualizado, pero Google no mirará los mapas antiguos ya que están desactualizados, a menos, por supuesto, que haga un re-índice importante. Este enfoque tiene mucho sentido, ya que todo lo que hace es simplemente crear un nuevo mapa, digamos cada día de contenido nuevo y actualizado, y hacer ping en Google, por lo que Google solo necesita indexar estas nuevas URL.

Este enfoque de registro es un código de sincronización, ya que todo lo que necesita es un modelo de almacenamiento de datos estático que almacena los datos XML para cada mapa. su trabajo cron puede construir un mapa, diario o semanal, y luego almacenar la página XML sin formato en un campo blob o lo que sea. a continuación, puede servir las páginas directamente desde un controlador y también el mapa de índice también.

No estoy seguro de lo que otros piensan, pero esto suena como un enfoque muy viable y un servidor de carga en comparación con la reconstrucción de un mapa enorme solo porque algunas páginas pueden haber cambiado.

También he considerado que es posible reducir el tamaño de una semana de mapas en un mapa de una semana y 4 semanas de mapas en un mes, por lo que se terminan con mapas mensuales, un mapa de cada semana en el actual mes y luego un mapa de los últimos 7 días. Suponiendo que todas las fechas se mantienen, esto reducirá el número de mapas que ordenan el proceso. Estoy pensando en términos de reducir 365 mapas para cada día del año a 12.

Aquí hay un pdf en los mapas del sitio y el enfoques utilizados por Amazon y CNN.

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

Answer 3

estoy usando django-staticgenerator aplicación para sitemap.xml almacenamiento en caché de sistema de archivos y actualizar ese archivo cuando se actualizan los datos.

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() 

En la configuración de nginx vuelvo a dirigir a sitemap.xml carpeta de caché y Django ejemplo de retorno:

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; 
    }  
} 

Con este método, sitemap.xml siempre se actualizará y los clientes (como google) obtienen el archivo xml siempre de forma estática. Eso es genial, creo! :)

Answer 4

Para aquellos que (por cualquier razón) preferirían mantener sus sitemaps generados dinámicamente (por ejemplo, frescura, pereza). Pruebe django-sitemaps. Es una versión de transmisión de los mapas de sitio estándar. Reemplazo directo. Tiempo de respuesta mucho más rápido y utiliza menos memoria.