Augmentez la vitesse de mise en cache des tuiles (TileStache)

Je sers des tuiles vectorielles en utilisant TileStache , j'ai tout configuré comme je veux. Mes données sont stockées dans Postgres et j'utilise le fournisseur VecTiles pour servir les tuiles GeoJSON .

Je veux mettre en cache toutes mes tuiles pour rendre les tuiles plus rapides. J'utilise tilestache-seed.py pour amorcer mon cache. J'utilise tilestache-seed sur plusieurs machines. Tilestache-seed a très bien fonctionné jusqu'au niveau de zoom 13, mais après cela, il faut beaucoup trop de temps pour mettre en cache les tuiles. Juste pour le niveau de zoom 16, j'ai 5023772 tuiles à mettre en cache, et je ne reçois que 100 000 à 200 000 tuiles par jour sur chaque machine.

Comment accélérer la mise en cache de mes tuiles ? Existe-t-il un moyen d'affiner tilestache-seed.py et de le rendre plus rapide?

Mise à jour: j'ai essayé de construire des index spatiaux sur mes tables (sur la colonne de géométrie et les colonnes utilisées pour filtrer les données via la clause where) et je n'ai toujours pas vu une augmentation significative de la vitesse de tuilage. À ce rythme, seul Zoom 17 me prendra un mois et cette fois-ci ne augmentera que de façon exponentielle lorsque je me dirigerai vers Zoom 21

Mise à jour 2: J'ai également essayé de créer des vues matérialisées et il n'y a aucun changement perceptible dans les performances, donc l'optimisation de la base de données ne fonctionne pas. Je pense que je devrai optimiser le tilestache-seed.py lui-même, ou imaginer une nouvelle façon de mettre en cache les tuiles.

Informations sur le matériel J'exécute les processus de mise en cache sur 8 PC différents, dont l'un est un i7 avec 32 Go de RAM et un autre est un i3 avec 4 Go de RAM, mais ils me donnent tous les deux la même vitesse de mise en cache (environ 100 000 tuiles par jour)

Je dirais que pour un zoom supérieur à 15, si vous divisez votre zone d'intérêt en zones plus petites (cadre de délimitation), vous pourrez les mettre en cache en beaucoup moins de temps en exécutant plusieurs processus sur une seule machine.

Par exemple, vous exécutez le zoom 16 (avec 50 000 000 tuiles) sur une machine et selon votre vitesse moyenne de mise en cache des tuiles, ce processus se terminera dans environ 40 à 50 jours. Disons que vous divisez ces tuiles en deux et que vous les exécutez simultanément sur la machine, alors vous pourrez les mettre en cache en 20-25 jours car le processus d'amorçage de tilestache utilise seulement environ 30% de votre processeur pour un processus de mise en cache de tuiles unique et je sais cela parce que j'ai le même problème une fois et jusqu'à présent, cela a résolu mon problème.

Cela n'affectera pas la vitesse de mise en cache des tuiles si vous exécutez un seul processus sur une machine ou plusieurs processus, mais l'utilisation du processeur sera augmentée.

J'espère que cela t'aidera.

Par défaut, shp2pgsql ne crée PAS d'index. Vous devez passer -Ipour lui faire générer un index spatial. http://postgis.net/docs/manual-1.3/ch04.html#id435762

Vérifiez si votre table a un index en exécutant \d tablenameen psql. Dans la liste des index devrait être une ligne avec "gist" (sauf si vous avez choisi un index différent) et le nom de votre colonne de géométrie.

Vous pouvez également en ajouter un après le fait, voir http://postgis.net/docs/manual-1.3/ch03.html#id434676 (ne laissez pas la note sur la perte vous effrayer):

CREATE INDEX [indexname] ON [tablename] USING GIST ( [geometrycolumn] );

Étant donné que vous utilisez probablement également des colonnes non spatiales dans vos requêtes, vous souhaitez généralement créer des index pour chaque colonne utilisée pour la recherche. Si par exemple vous avez une requête comme SELECT * FROM roads WHERE priority = 3;alors priorityest utilisé et l' ajout d' un index , il sera considérablement accélérer les choses en place:

CREATE INDEX idx_roads_priority ON roads(priority);.

Une autre chose à essayer si vous utilisez une requête standard est de créer une vue matérialisée à partir de la requête et de construire vos tuiles à partir de celle-ci: http://www.postgresql.org/docs/9.3/static/sql-creatematerializedview.html

Cela va vous faire une table qui stocke la requête (afin que vous puissiez potentiellement la mettre à jour à l'avenir). Assurez-vous d'avoir des indices spatiaux sur les MV enfants et vous serez alors aussi rapide que possible.

Ce qui pourrait arriver, c'est que vous avez un index spatial, mais vous ne sélectionnez alors que certaines des données, ce qui signifie que vous n'utilisez plus l'index spatial ...