2016-02-16 3 views
0

Nous avons un énorme fichier d'URL différentes (~ 500K - ~ 1M URL).
Nous voulons utiliser Grinder 3 pour distribuer ces URLs aux travailleurs de manière à ce que chaque travailleur appelle une URL unique et différente.
Grinder - comment distribuer invocation d'URL à partir du fichier

Dans le script JY nous pourrions:

  • Lire le fichier une fois par Agent

  • Allouer ligne numéro-gammes par agent

  • Chaque travailleur aurait obtient une ligne/url en fonction de son identifiant d'exécution à partir de sa plage de numéros de ligne d'agent.

Cela signifie encore le chargement d'un énorme fichier en mémoire et à écrire un code à un problème qui pourrait être commun à plusieurs.

Des idées pour une solution plus simple/prête à l'emploi?

Répondre

0

J'ai utilisé Grinder d'une manière similaire il y a quelque temps, et j'ai écrit un utilitaire pour l'ingestion unique et multi-thread d'URL à partir d'un fichier volumineux. Voir https://bitbucket.org/travis_bear/file_util - en particulier, le lecteur séquentiel.

Je vous recommande d'utiliser l'utilitaire de ligne de commande split (ou similaire) pour donner des segments distincts du fichier maître à chaque agent avant d'exécuter votre exécution Grinder.

+0

Cela aide certainement dans la lecture réelle du fichier, mais encore nous supposerions qu'il existe un code standard pour distribuer le travail aux agents et aux travailleurs. – user3139774

0

J'aurais pris une approche différente si vous aimez puisque c'est un énorme fichier, Combien de threads prévoyez-vous de générer. Je crois que vous savez déjà que vous pouvez obtenir Grinder.ThreadNo pour obtenir le thread en cours d'exécution. Vous pouvez réellement diviser le fichier en utilisant un pré-processeur avec un nombre égal d'enregistrements en nombre de threads et les nommer 0, 1, 2 etc qui correspond au nom du thread. Pourquoi je suggère ceci est que le traitement du fichier ressemble à une pré-tâche ce qui est important sont son contenu. Le traitement du fichier ne doit pas interférer lorsque les threads sont en cours d'exécution.

Maintenant, chaque thread aura son propre fichier et aucune collision. Par exemple, 20 fils 20 fichiers, mais votre nombre de threads doit être choisi avec soin et peut être + 50% de pointe.