2009-10-17 7 views

Répondre

6

Un RAMDirectory est plus rapide mais n'est pas écrit sur le disque. Il n'existe que tant que votre programme est en cours d'exécution et doit être créé à partir de zéro chaque fois que votre programme s'exécute.

Si votre index est assez petit pour tenir confortablement dans la RAM, et que vous ne le mettez pas à jour fréquemment, vous pouvez maintenir un index sur le disque puis créer un RAMDirectory à partir du constructeur RAMDirectory(Directory dir). La requête qui devrait alors être plus rapide que l'interrogation de celui sur le disque, une fois que vous avez payé la pénalité de le charger. Mais mesurez la différence - si l'index peut entrer dans la mémoire en tant que RAMDirectory, alors il peut également tenir dans le cache disque, de sorte que vous ne verrez peut-être pas beaucoup de différence.

+0

Merci pour les entrées ur .. puis-je savoir comment petit est "assez petit"? – user43498

+0

J'imagine plus petit que votre RAM physique disponible. –

4

Vous devez profiler l'utilisation de RAMDirectory. Au moins sous Linux, l'utilisation de RAMDirectory n'est pas plus rapide que l'utilisation de FSDirectory par défaut, en raison de la façon dont le système d'exploitation met en mémoire tampon les E/S.

12

Je compare FSDirectory et RAMDirectory.

    taille de l'index
  • est 1.4G
  • Centos, 5G mémoire

recherche 1000 mots-clés, la moyenne/min/max Temps de réponse (ms) est ici

  • FSDirectory
    • première exécution: 351/7/2611
    • deuxième manche: 47/7/837
    • troisième run (app restart): 53/7/2343
  • RAMDirectory
    • première course: 38/7/1133
    • deuxième manche: 34/7/189
    • troisième run (app restart): 38/7/959

Donc, vous pouvez voir que RAMDirectory est plus rapide que FSDirectory, mais après que le 'os file cache warm up', l'écart de vitesse n'est pas si différent. Quel est l'inconvénient de RMADirectory? Dans mon test

  • Il mange beaucoup plus de mémoire, le fichier 1.4G nécessite environ 2G pour le charger en mémoire. tandis que FSDirectory utilise seulement 700m. Ensuite, cela signifie plus de temps pour le gc complet.
  • Il faut plus de temps pour charger, en particulier lorsque le fichier d'index est volumineux. Il faut copier les données du fichier en mémoire lors de l'ouverture de l'index. Cela signifie que les demandes seraient bloquées pendant plus de temps lors du redémarrage de l'application.
  • Il n'est pas très pratique de maintenir deux index en même temps. Parce que notre application change d'index toutes les quelques heures.Nous voulons que l'index se réchauffe tandis que l'ancien index fonctionne toujours dans le même tomcat.
Questions connexes