Partage
  • Partager sur Facebook
  • Partager sur Twitter

Optimisation du ration CPU/mémoire /réseau

dans le cadre d'un serveur TCP

    14 novembre 2017 à 17:01:44

    Bonjour,
    Je suis en train de tenter d'évaluer le meilleur choix en terme d'utilisation CPU, mémoire et encombrement réseau dans le cadre d'un serveur en mode TCP. Ce serveur sera multi-threading car multi-utilisateur.
    Chaque client est associé à un ID, un socket, un objectInputStream dans un thread et un objectOutputStream.
    J'hésite entre 3 choix : 
    1/ Utiliser une hashMap avec un couple clé-valeur pour stocker le couple ID-socket. Avantage : pas de mémoire utilisée pour stocker l'objectOutputStream. Inconvénient : je dois créer un nouvel ObjetOutputStream chaque fois que je veux envoyer un message et l'instanciation d'un objet semble être une tache gourmande en terme d'utilisation du processeur. De plus, cette création est peut être aussi consommatrice de bande passante.
    2/ Utiliser une ArrayList pour enregistrer tous les sockets pour le cas où je doive arrêter le serveur et donc, fermer proprement toutes les sockets ; et stocker dans une HashMap le couple ID-ObjectOutputStream. Avantage : pas de perte de temps à créer un nouvel ObjectOutputStream chaque fois que je veux envoyer un message. Inconvénient : je consomme de la mémoire pour stocker les ObjectOutputStream.
    3/ Toute autre solution élégante à laquelle je n'aurais pas pensé
    Note : j'ai besoin d'un ID pour les clients car cette valeur, associée au message, sera utilisée pour savoir à qui le serveur doit répondre après que le message reçu aura été traité dans un "MessageProcessor".
    Quelle serait la meilleure solution, et pourquoi ?
    Merci pour toutes vos réponses.

    -
    Edité par Dr_Click 14 novembre 2017 à 17:04:58

    • Partager sur Facebook
    • Partager sur Twitter
    Dr_Click
    Anonyme
      14 novembre 2017 à 17:29:49

      Salut !

      La place prise en mémoire par les éléments que tu cites (ObjectInputStream, Socket, ID...) ne devrait vraiment pas être une préoccupation pour toi, surtout en Java puisque tu ne gères pas la mémoire. Donc même si tu supprimes un objet, rien ne garantit qu'il sera libéré par la JVM immédiatement. De plus, ce sont des tailles ridicules par rapport à la mémoire dont tu disposes normalement sur un serveur. Donc tu devrais choisir la solution qui semble la plus propre et la plus sécurisée.

      -
      Edité par Anonyme 14 novembre 2017 à 17:31:27

      • Partager sur Facebook
      • Partager sur Twitter
        14 novembre 2017 à 17:49:25

        Dr_Click a écrit:

        Ce serveur sera multi-threading car multi-utilisateur.

        Il n'y a pas de lien de causalité dans cette phrase. Si tu fais un thread par utilisateur, ton serveur consommera simplement bien plus de ressource que ce qu'il a besoin.

        • Partager sur Facebook
        • Partager sur Twitter

        Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C

          14 novembre 2017 à 18:12:29

          Ksass`Peuk a écrit:

          Dr_Click a écrit:

          Ce serveur sera multi-threading car multi-utilisateur.

          Il n'y a pas de lien de causalité dans cette phrase. Si tu fais un thread par utilisateur, ton serveur consommera simplement bien plus de ressource que ce qu'il a besoin.


          Je souhaite que mon serveur écoute plusieurs clients à la fois (car je ne sais jamais quel client parlera ni quand) donc j'ai créé une classe "Recepteur" de type Runnable. J'utilise une instance de cette classe pour chaque client et à l'instanciation, je crée un ObjectInputStream. Une fois cette instance créée, je lance ma méthode "Run" qui contient une boucle infinie.

           La classe du récepteur est donc codée comme suit : 

          	private class Receiver implements Runnable {
          
          		private ObjectInputStream in;
          		private Socket client;
          		
          		public Receiver (Socket client) {
          			try {
          				this.client=client;
          				in = new ObjectInputStream(client.getInputStream());
          			} catch (IOException e) {
          				e.printStackTrace();
          			}
          		}
          
          		@Override
          		public void run() {
          			while (true) {
          				try {
          					Object objectReceived=in.readObject();
          					if (objectReceived instanceof Message) {
          						Message messageReceived=(Message) objectReceived;
          						System.out.println("ComServer.Receiver : "+messageReceived.getContent());
          						setChanged();
          						notifyObservers(messageReceived);
          					}
          				} catch (IOException e) {
          					e.printStackTrace();
          				} catch (ClassNotFoundException e) {
          					e.printStackTrace();
          				}
          				
          			}
          			
          		}
          	}



          Si je ne créait pas un Thread pour chaque "Recepteur", comment je pourrais écouter tous les clients en même temps ? Je suis preneur si tu as une idée plus élégante et performante.

          -
          Edité par Dr_Click 14 novembre 2017 à 18:14:28

          • Partager sur Facebook
          • Partager sur Twitter
          Dr_Click
          Anonyme
            14 novembre 2017 à 18:19:02

            Tu devrais te tourner vers la sélection de socket.
            • Partager sur Facebook
            • Partager sur Twitter
              14 novembre 2017 à 19:46:13

              PitchPitch a écrit:

              Tu devrais te tourner vers la sélection de socket.


              Heu... c'est à dire ? o_O
              • Partager sur Facebook
              • Partager sur Twitter
              Dr_Click

              Optimisation du ration CPU/mémoire /réseau

              × Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
              × Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
              • Editeur
              • Markdown