views:

93

answers:

1

Hi All,

I need to write a MultiThreaded Java Application that will be used to load test the MMS Server. Transactions starts when the MMS server indicates to my MultiThreaded Java Application that a MMS has arrived on the server and then i need to download the attachment that is part of the of the MMS from the MMS server using the protocol supported by the MMS Server. Once is successfully download the attachment, then it marks the completion of the Transaction, Since its a load testing application for the MMS Server, the expected TPS is above 1400 TPS, hence i need to provide the hardware requirements for this application, I feel that i need a horizontal scaling along with a load balancer and a network connectivity in GBPS to download attachments. If i have 2 boxes, then each box has to handle 700 TPS , is it feasible for a multi threaded java application deployed on a Solaris box to acheive this performance of 700 TPS. Please let me know your thoughts from a architecture, hardware and it will be helpful if i can get suggestion on which Solaris hardware needs to be considered. I have Solaris T5220 in my mind.

Thanks a lot in advance for all your help.

+1  A: 

I doubt that you'll need such a big machine. This depends on a lot of different factors though, of which quality of code probably is the most important one.

Regarding network usage, you should really come up with a number of KB an average attachment will have. For 10 KB attachments, 1400 TPS would mean 14,000 KB or 14 MB per second. For 1 MB it would be 1.4 GB per second - quite a difference, isn't it?

For 1.4 GB per second, you could also get some serious problems to store it somewhere - if this is a requirement at all.

The processing itself shouldn't be too much of a problem (but again, depends on a multitude of different factors).

The best thing you could do is to use any free hardware (or virtual machine) you can grab and run some tests. Just see what numbers you get and decide where to go from there.

sfussenegger
If you have to hold on to the downloaded bytes at all then you may find your Java-based load tool will be doing a lot of garbage collecting which could become an inhibiting factor.
Benjamin
Thanks a lot for your reply, Application Expectation is to address 1400 TPS with 75KB attachment size on an average, Hence i need to have 100 MBPS Network. As Benjamin mentioned i am little bit worried from the Garbage Collection since i need to address nearly 100MB of data per sec. I have a question as the no of threads increases will it have a effect on the TPS. For Ex: 1) I have a Thread Connection Pool with 200 Threads to address 1000 transactions 2) I have another Thread connection pool with 500 Threads to address the same 1000 transactions Which option will provide better Performance/TPS
Vijay
@Vijay once again, this depends strongly on the implementation of your client an some other characteristics. if you use non-blocking IO, I wouldn't recommend to use much more threads than you have cores available. If you have a blocking implementation, the number of threads you need depends on the time a transaction takes to complete. If a transaction takes 10ms, a single thread can handle (close to) 100 TPS, hence you'd need 14 threads. If a transaction takes 2 seconds to complete, you'd need 2800 threads. Once again, grab some hardware, run a test, identify the bottlenecks and go on.
sfussenegger
and if you think that the client or network (don't forget about the network hardware - cheap office switches might become a problem) is a problem, distribute the load across several clients and try to avoid unnecessary networking (try to connect your clients and server using nothing else but crossover cables if possible)
sfussenegger
Thanks a lot for you reply, it is guiding me in towards a prototype implementation, will implement the same and identify the bottlenecks.
Vijay