2010-03-10 6 views
0

Je dois écrire une application Java MultiThread qui sera utilisée pour tester le serveur MMS. Les transactions démarrent lorsque le serveur MMS indique à mon application Java MultiThreaded qu'un MMS est arrivé sur le serveur et que j'ai besoin de télécharger la pièce jointe qui fait partie du MMS du serveur MMS en utilisant le protocole supporté par le serveur MMS. Une fois que la pièce jointe est téléchargée avec succès, elle marque l'achèvement de la transaction. Comme c'est une application de test de charge pour le serveur MMS, le TPS attendu est supérieur à 1400 TPS, donc je dois fournir la configuration matérielle requise pour cette application. J'ai besoin d'une mise à l'échelle horizontale avec un équilibreur de charge et une connectivité réseau en GBPS pour télécharger les pièces jointes. Si j'ai 2 boîtes, alors chaque boîte doit gérer 700 TPS, est-ce faisable pour une application java multi-thread déployée sur une boîte Solaris pour atteindre cette performance de 700 TPS. N'hésitez pas à me faire part de vos réflexions sur l'architecture, le matériel et il me sera utile si je peux obtenir des suggestions sur le matériel Solaris à prendre en compte. J'ai Solaris T5220 dans mon esprit.Test de charge de l'application Java multithread 1400 TPS Obligatoire

Merci beaucoup d'avance pour toute votre aide.

+0

appelez-vous la sortie des tests rapports TPS :) –

Répondre

1

Je doute que vous ayez besoin d'une telle machine. Cela dépend de beaucoup de facteurs différents, dont la qualité du code est probablement la plus importante. En ce qui concerne l'utilisation du réseau, vous devriez vraiment trouver un nombre de Ko qu'une pièce jointe moyenne aura. Pour les pièces jointes de 10 Ko, 1400 TPS signifieraient 14 000 Ko ou 14 Mo par seconde. Pour 1 Mo, ce serait 1,4 Go par seconde - une grande différence, n'est-ce pas?

Pour 1,4 Go par seconde, vous pourriez également avoir de sérieux problèmes pour le stocker quelque part - si c'est une exigence du tout.

Le traitement lui-même ne devrait pas poser trop de problèmes (mais dépend encore d'une multitude de facteurs différents). La meilleure chose que vous pourriez faire est d'utiliser n'importe quel matériel gratuit (ou machine virtuelle) que vous pouvez prendre et exécuter quelques tests. Il suffit de voir les chiffres que vous obtenez et de décider où aller à partir de là.

+0

Si vous devez conserver les octets téléchargés du tout alors vous pouvez trouver votre outil de chargement basé sur Java va faire beaucoup de collecte des ordures qui pourrait devenir un facteur inhibiteur. – Benjamin

+0

Merci beaucoup pour votre réponse, Application Expectation est d'adresser 1400 TPS avec une taille de pièce jointe de 75 Ko en moyenne, d'où j'ai besoin d'avoir 100 MBPS réseau. Comme Benjamin l'a mentionné, je suis un peu inquiet de la Garbage Collection car je dois traiter près de 100 Mo de données par seconde. J'ai une question car le nombre de threads augmente aura-t-il un effet sur le TPS. Pour Ex: 1) J'ai un pool de connexion Thread avec 200 Threads pour traiter 1000 transactions 2) J'ai un autre pool de connexion Thread avec 500 Threads pour traiter les mêmes 1000 transactions Quelle option fournira une meilleure Performance/TPS – Vijay

+0

@Vijay encore une fois, cette dépend fortement de la mise en œuvre de votre client et d'autres caractéristiques. Si vous utilisez des E/S non bloquantes, je ne recommanderais pas d'utiliser beaucoup plus de threads que de cœurs disponibles. Si vous avez une implémentation bloquante, le nombre de threads dont vous avez besoin dépend du temps nécessaire à une transaction. Si une transaction prend 10ms, un seul thread peut gérer (proche de) 100 TPS, d'où 14 threads. Si une transaction prend 2 secondes pour terminer, vous aurez besoin de 2800 threads. Encore une fois, prenez du matériel, faites un test, identifiez les goulots d'étranglement et continuez. – sfussenegger