Fils spécialisés ou généralistes

Question

Fils spécialisés ou généralistes.

Salut, je travaille sur un système où les objets passent par certaines étapes.

1er. Principalement des requêtes de base de données

2ème. Principalement l'analyse d'E/S et de xml hd

3ème. Communication de Webservice principalement

4e. Sérieusement la sérialisation et la désérialisation de Xml

5ème. Certains travaux optionnels

Le système doit fonctionner avec des milliers d'objets par heure, donc j'utiliserai beaucoup de threads, mais ma question est, quelle est la meilleure approche?

• Certains sujets spécialisés pour chaque étape: comme 5 fils de discussion sur chaque étape, certains threads obtenir des objets sur 1ère étape, le travail sur eux, mettre à jour le statut de ces objets, si un autre thread de spécialiste 2ème étape obtenir ces objets et travaille sur ça.

• Tous les sujets généralistes, chaque thread obtenir un objet de la première étape et va jusqu'à la fin de l'étape 5.

Answer 1

Coincidence, nous avons eu une discussion similaire il y a un certain temps. Nous avons soulevé ces points qui devraient être pris en considération avant la décision:

1. Combien de temps en moyenne une étape prend? -> Si chaque étape prend un minimum de temps, en général il est préférable d'avoir un thread faisant toutes les étapes ou le changement de contexte devient un overhead
2. Chaque étape est-elle spécifique au domaine? -> Si c'est le cas, il est préférable de les garder dans des fils séparés. Bien que les gens puissent argumenter qu'il suffit de séparer le code d'exécution, mais je pense que ce n'est pas toujours le cas. Par exemple un fil particulier pourrait avoir besoin de prioveleges spéciaux ou d'une priorité plus élevée.
3. Coût des changements de contexte? -> Pas besoin d'expliquer
4. Modèle et ressources de filetage -> Par exemple. votre système est à court de threads et une demande de priorité plus élevée est venue. Laisserez-vous des faibles pré-requis pour répondre à cette demande?

Il y a quelques points supplémentaires que je vais ajouter dans les commentaires car je me souviens !!

Answer 2

J'imagine que vous souhaiterez peut-être limiter le nombre d'appels DB et WS simultanés, de sorte que vous puissiez bénéficier de niveaux de concordance différents à différents stades de votre pipeline. Par conséquent, je pourrais bien envisager l'utilisation de spécialistes. Cela tendrait à augmenter la complexité globale de la solution. Donc, je voudrais d'abord commencer par construire et tester les performances de l'approche généraliste. Si vous obtenez votre débit désiré, alors gardez-le simple, laissez-le bien seul.

Answer 3

Quelques choses à considérer

• Mode d'échec: Qu'advient-il si une étape échoue? Le travail effectué doit être réessayé ou abandonné? Y aura-t-il des modes de défaillance où les threads meurent et se recréent ou les threads restent éternels?Si le travail doit être réessayé, les threads spécialisés ont plus de sens, car en cas d'échec, les objets sont récupérés dans la file d'attente. Coordination: Dans les threads spécialisés, l'objet de scénario vivra généralement plus longtemps dans la structure partagée si les étapes sont strictement sérielles, ce qui peut nuire à votre débit. Donc, si toutes les étapes sont strictement sérielles, il est plus facile d'avoir des threads généralistes pour réduire les efforts de coordination.