Recherche de la bande passante Internet du serveur via java pour la diffusion en continu

Question

Suite à ce sujet. Streaming large files in a java servlet.

Est-il possible de trouver la bande passante Internet totale disponible dans la machine courante via java? Ce que j'essaye de faire est en streaming des fichiers volumineux à travers servlet, basé sur le nombre de requête parallèle et la largeur totale de bande j'essaye de réduire le BUFFER_SIZE du flux pour chaque demande. avoir un sens?

Existe-t-il une méthode Java pure? (sans JNI)

Answer 1

Peut-être que vous pouvez chronométrer combien de temps l'application doit envoyer un paquet (le tampon). Et si cette valeur est supérieure à x millisecondes, réduisez la taille de votre tampon. Vous pouvez utiliser d'autres valeurs pour l'original bufferSize et if (stop - start > 700).

Ceci est basé sur le fil que vous avez remarqué:

ServletOutputStream out = response.getOutputStream(); 
InputStream in = [ code to get source input stream ]; 
String mimeType = [ code to get mimetype of data to be served ]; 
int bufferSize = 1024 * 4; 
byte[] bytes = new byte[bufferSize]; 
int bytesRead; 

response.setContentType(mimeType); 

while ((bytesRead = in.read(bytes)) != -1) { 
    long start = System.currentTimeMillis(); 
    out.write(bytes, 0, bytesRead); 
    long stop = System.currentTimeMillis(); 
    if (stop - start > 700) 
    { 
     bufferSize /= 2; 
     bytes = new byte[bufferSize]; 
    } 
} 

// do the following in a finally block: 
in.close(); 
out.close(); 

Answer 2

La seule façon de trouver la bande passante disponible est de la surveiller/mesurer. Sur Windows, vous avez accès à Net.exe et pouvez obtenir le débit sur chaque carte réseau.

Answer 3

Si vous diffusez le contenu via une servlet, vous pouvez calculer la vitesse de chaque flux de sortie de servlet. Collectez ces données pour tous les flux pour un utilisateur/une session, et vous pouvez déterminer au moins l'utilisation actuelle de la bande passante.

Un moyen possible de calculer le taux pourrait être au lieu d'écrire les gros fichiers à travers le servlet output stream, écrire à un nouveau FilterOutputStream qui garderait une trace de vos taux de téléchargement.

Answer 4

Le concept de «bande passante Internet totale disponible dans la machine actuelle» est vraiment difficile à définir. Toutefois, l'ajustement de la taille du tampon local n'a aucune incidence sur la quantité de données que vous pouvez transmettre à un client individuel.

La vitesse à laquelle un client donné peut prendre des données de votre serveur variera avec le client et avec le temps. Pour une connexion donnée, vous pouvez être limité par votre connexion amont locale à Internet (par exemple, serveur sur DSL) ou vous pouvez être limité quelque part dans le noyau (improbable) ou l'extrémité distante (par exemple, serveur dans un centre de données, client sur une ligne d'accès à distance). Lorsque vous avez de nombreuses connexions, chaque connexion peut avoir un goulot d'étranglement différent. La mesure de cette bande passante disponible est un problème difficile; Voir par exemple cette liste de research and tools sur le sujet. En général, TCP gérera toute la bande passante disponible de manière équitable pour toute connexion donnée (bien que, parfois, il puisse réagir plus lentement que vous le souhaitez aux changements de bande passante disponible). Si le client ne peut pas gérer plus de données, l'appel d'écriture bloquera.

Vous ne devez modifier la taille de la mémoire tampon dans la question liée que si vous constatez que la bande passante est faible et que la cause est insuffisante pour l'écriture sur le réseau. Une autre raison pour laquelle vous pourriez modifier la taille de la mémoire tampon est si vous avez tellement de connexions actives que vous manquez de mémoire. Dans tous les cas, la vraie réponse peut être de ne pas mettre de tampon mais de mettre vos fichiers statiques sur un serveur séparé et d'utiliser un thttpd pour les servir (en utilisant un appel système comme sendfile) au lieu d'un servlet. Cela permet de s'assurer que le goulot d'étranglement n'est pas sur votre serveur, mais quelque part sur Internet, hors de votre contrôle.

Answer 5

EDIT: Relisant ceci, c'est un peu confus parce qu'il est en retard ici. Fondamentalement, vous ne devriez pas avoir à le faire à partir de zéro; utilisez l'un des serveurs Java hautement évolutifs existants, car ils le feront mieux et plus facilement.

Tu ne vas pas aimer ça, mais en fait n'a pas de sens, et voici pourquoi:

• bande passante totale est indépendante du nombre de connexions (bien qu'il y ait quelques petits frais généraux), donc jouer avec les tailles de buffer ne va pas aider beaucoup
• Vos blocs de données sont de toute façon fragmentés en paquets de taille variable. Votre carte réseau et votre protocole s'en chargeront mieux que votre servlet.
• Le redimensionnement régulier des tampons est coûteux - mieux vaut réutiliser les tampons constants d'un pool de taille fixe et faire en sorte que toutes les connexions fassent la queue pour les droits d'E/S
• Il y a un milliard et demi bibliothèques qui aident à ce genre de serveur

Si cette moi, je commence à regarder E/S multiplexées en utilisant NIO. Vous pouvez presque certainement trouver une bibliothèque pour le faire pour vous. L'article IBM here peut être un point de départ utile. Je pense que l'argent intelligent vous donne un thread d'E/S réseau et un thread d'E/S disque, avec multiplexage. Chaque connexion demande un tampon à partir d'un pool, le remplit de données (à partir d'un réseau ou d'un disque partagé ou d'un canal), le traite, puis renvoie le tampon au pool pour une réutilisation. Pas de redimensionnement des tampons, juste un peu d'attente pour chaque morceau de données. Si vous souhaitez que la latence reste courte, limitez le nombre de transferts actifs à la fois et mettez en file d'attente les autres.