Quel est le moyen le plus efficace pour lister tous les fichiers dans un répertoire (y compris les sous-répertoires)?

Question

J'écris une servlet qui va examiner un répertoire sur le serveur (externe au conteneur web), et rechercher récursivement certains fichiers (par certains fichiers, je veux dire des fichiers qui sont d'une certaine extension ainsi qu'une certaine convention de nommage). Une fois ces fichiers trouvés, la servlet répond avec une longue liste de tous les fichiers trouvés (y compris le chemin d'accès complet aux fichiers). Mon problème est qu'il y a tellement de fichiers et de répertoires que mon servlet est extrêmement lent. Je me demandais s'il y avait une meilleure pratique ou une servlet existante pour ce type de problème? Serait-il plus efficace de simplement compiler la liste complète des fichiers et de faire le filtrage via js/jquery côté client?

Answer 1

accès disque est lent et que le nombre de fichiers et répertoires augmente, vous rapidement atteindre un point où votre servlet sera inutile lors de l'utilisation de la recherche récursive classique par l'arborescence du répertoire. Vous atteindrez particulièrement cette limite rapidement si vous avez un grand nombre d'utilisateurs simultanés effectuant la même recherche en même temps. Il est préférable d'utiliser un travail par lots externe pour générer la liste des fichiers qui peuvent ensuite être lus dans le servlet via un appel de base de données ou même simplement en analysant un fichier contenant tous les noms de fichiers séparés par un caractère de nouvelle ligne. . L'utilisation de "find" sur Linux est un moyen simple de le faire: par ex.

find <path_to_directory> -name '*.bin' > list_files.txt 

Ce serait la liste de tous les noms de fichier qui se termine par .bin dans un répertoire particulier et la sortie dans un fichier nommé list_files.txt. Votre servlet pourrait alors lire dans ce fichier et créer la liste des fichiers à partir de là.

Answer 2

Si vous avez vraiment beaucoup de fichiers, vous pourriez envisager de générer un processus externe pour effectuer la recherche. Si vous utilisez un serveur de type unix (comme linux), vous pouvez obtenir des gains de vitesse en ayant la commande "find" faire la recherche pour vous, et analyser sa sortie.

Vous pouvez google pour de nombreux exemples d'utilisation de "trouver".

Answer 3

Je pense que votre servlet fonctionne lentement à cause de la vitesse du disque dur. si la liste des fichiers d'un permanent vous devez charger la mémoire

Answer 4

Je vois deux raisons possibles pour lesquelles ce processus pourrait aller lentement:

1) E/S disque prend trop de temps. Ce sera une véritable contrainte que vous ne pouvez pas faire grand chose. Habituellement, le système d'exploitation est assez bon pour garder les structures en mémoire qui lui permettent de trouver les fichiers dans vos dossiers beaucoup plus rapidement. Si c'est trop lent, vous devrez peut-être créer un index en mémoire. Tout dépend de la façon dont vous le faites. En tout cas, si c'est le problème (vous pouvez essayer de mesurer), alors il n'y a aucun moyen d'aider le côté client de filtrage, car cela ne devrait pas prendre beaucoup de temps, peu importe où vous le faites. Au lieu de cela, vous allez ralentir le client en lui envoyant plus de données à trier.

2) Il y a un problème avec la traversée de votre répertoire. Vous dites que c'est "récursif". Si vous voulez dire que c'est réellement récursif, c'est-à-dire une méthode qui s'appelle chaque fois qu'il rencontre un nouveau répertoire, alors cela pourrait bien vous ralentir (les frais généraux s'ajoutent vraiment). Il ya quelques trucs sur tree traversal sur wikipedia, mais fondamentalement il suffit d'utiliser une file d'attente ou une pile pour garder une trace de l'endroit où vous êtes dans la traversée, au lieu d'utiliser votre état de méthode pour le faire.

Notez qu'un système de fichiers n'est pas réellement un arbre, mais je suppose que c'est dans ce cas. Ça devient un peu plus poilu autrement.

Je ne suis pas d'accord avec les autres affiches que vous ne pouvez pas mettre en œuvre en cours. Cela devrait fonctionner assez bien jusqu'à un certain point, pas besoin de tâches par lots pour le moment.