J'ai fait mumuse avec un code proche de ta solution et en y ajoutant la TPL.
Ben pour tous, c'est grosso modo la même chose... J'ai pas fait l'étape sauvegarder dans un fichier car flemme mais ca n'a rien de bloquant.
A chaque fois on est capable de chronométrer le temps par appel et le temps total. Ca supporte aisément plus de 64 tâches (je n'utilise pas de WaitHandle.WaitAll)
En fait, ce qui est surtout déterminant (et en fait ce qui est complètement masqué dans ton article) c'est la capacité du client à traiter les tâches de manière concurrente. Tu remarqueras que dans mon exemple j'utilise un WCF en console pour avoir totalement la main sur le parallélisme. Toutes les requêtes sont indépendantes et une instance de service par requête.
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple, InstanceContextMode = InstanceContextMode.PerCall)]
1 2 3 4 5
| <serviceBehaviors>
<behavior name="HelloWorldBehavior">
<serviceThrottling maxConcurrentCalls="10"/>
</behavior>
</serviceBehaviors> |
D'après moi c'est au fournisseur de brider son service en fonction de ce qu'il peut recevoir et non pas au consommateur. Du coup, y'a pas vraiment de raisons de brider côté client. Et quand bien même tu voudrais brider, tu pourrais totalement avec le sémaphore.
Partager