10
votes

E / S non bloquant par rapport à l'utilisation de threads (quelle est la vitesse de contexte?)

Nous utilisons beaucoup les sockets dans un programme que je travaille et nous traitons des connexions allant jusqu'à environ 100 machines simultanément. Nous avons une combinaison de E / S en utilisation avec une table d'état à gérer Il et les sockets Java traditionnels qui utilisent des threads.

Nous avons assez de problèmes avec des prises non bloquantes et j'aime personnellement utiliser des threads pour gérer beaucoup mieux les sockets. Donc, ma question est:

Combien d'économie est faite en utilisant des prises non bloquantes sur un seul fil? Dans quelle mesure le contexte est-il impliqué dans l'utilisation de threads et combien de connexions simultanées pouvez-vous évoluer à l'utilisation du modèle fileté en Java?

java multithreading sockets

0 commentaires

3 Réponses :

2
votes

Pour vos questions, la meilleure méthode pourrait être de créer un programme de test, d'obtenir des données de mesure durs et de prendre la meilleure décision sur la base des données. Je fais habituellement cela lorsque vous essayez de prendre de telles décisions et que cela aide à avoir des chiffres difficiles à apporter avec vous pour sauvegarder votre argument.

Avant de commencer cependant, combien de threads parlez-vous? Et avec quel type de matériel exécutez-vous votre logiciel?

1 commentaires

Bonne idée, le programme que je travaille est pair-to-peer où un seul pair pourrait parler à plus de 100 autres. Les pairs peuvent être Linux / Windows / Mac (diverses saveurs) et il fonctionnera généralement sur des PC généralement assez bien spécifiés dans un environnement de bureau (c'est-à-dire 2 cmps).

10
votes

Sélection d'E / S d'E / S et non bloquantes dépend de votre profil d'activité de serveur. Par exemple. Si vous utilisez des connexions de longue date et des milliers de clients d'E / S peuvent devenir trop coûteux à cause de l'épuisement des ressources système. Cependant, les E / S direct qui ne répondent pas à la cache de la CPU sont plus rapides que les E / S non bloquantes. Il y a un bon article sur cela - écrire des serveurs multithreads Java - Quoi de neuf est nouveau .

À propos de Context Commutateur Coût - c'est une opération plutôt sur la puce. Considérons le test simple ci-dessous: P>

public class Exchanger<V> {
   ...
   private static final int NCPU = Runtime.getRuntime().availableProcessors();
   ....
   /**
    * The number of times to spin (doing nothing except polling a
    * memory location) before blocking or giving up while waiting to
    * be fulfilled.  Should be zero on uniprocessors.  On
    * multiprocessors, this value should be large enough so that two
    * threads exchanging items as fast as possible block only when
    * one of them is stalled (due to GC or preemption), but not much
    * longer, to avoid wasting CPU resources.  Seen differently, this
    * value is a little over half the number of cycles of an average
    * context switch time on most systems.  The value here is
    * approximately the average of those across a range of tested
    * systems.
    */
   private static final int SPINS = (NCPU == 1) ? 0 : 2000;

2 commentaires

Merci beaucoup, agréable d'avoir un cas de test.

Merci d'avoir publié le lien pour "écrire des serveurs multithreads Java - Quel est le vieux". J'avais oublié son nom et je ne pouvais pas le trouver.

1
votes

Pour 100 connexions sont peu susceptibles d'avoir un problème de blocage IO et d'utiliser deux threads par connexion (un pour lecture et écrire) c'est le modèle le plus simple IMHO.

Cependant, vous pouvez trouver utiliser JMS est un meilleur moyen de gérer vos connexions. Si vous utilisez quelque chose comme Activemq, vous pouvez consolider toutes vos connexions.

0 commentaires