Decision to go for distributed application?

Question

I have a legacy product in financial domain.Using tomcat 6. We get millions of request 10k of request in hour. I am wondering at high level should i go for ditributed application where my mvc component is on one system and service/dao on another box(can use spring remote/EJB). The reason i am planning to go in this direction so that load is distribute and get better performance With this it becomes scalable also. I only see the positive side of it but somehow not able to figure out what can be the negative aspect of it?

If some expert can help what is the criteria i should consider to go for distributed model and pros/cons of it? I also tried googling where i could get some stats like how much load a given webserver (tomcat in my case)handle efiiciently with given hardware(16 gb ram, windows 7, processor ).

Yes i am going to do POC where i will be measuring performance with distributed model vs without bit high level input will be highly appreciated?

Answer 1

It is impossible to answer this questions without more details - how long does it take to reply to one request on the current server? How many resources are allocated for one request?

having 10k requests per hour means ~3 requests per second. If performing the necessary operations and replying to a request, using 1 CPU takes ~300ms - one simple machine is totally fine. This is simple math, and doesn't always work. I guess you still have peaks within those 10k requests per hour and they aren't gradually distributed.

If we assume, one reply can take up to 1 second, than you can handle as many replies per second as your system has CPUs (given that a CPU would be the bottle neck) If the CPU isn't the bottle neck for your application server, there's probably something wrong. You should set up the database(s) on a different machine and only perform computation tasks on the application server machine.

Especially in the financial sector with a legacy software, I wouldn't try splitting a running product. How old is the current server? I believe that a new Server should be cheaper than rewriting an application. Unless you expect 50-100k requests per hour very soon, I don't think, splitting up such small parts makes sense.

Instead - run it on an up to date server hardware, split application server and data storage and you should be fine.

Answer 2

I am wondering at high level if should i go for ditributed application where my mvc component is on one system and service/dao on another box(can use spring remote/EJB).

I'm not sure what you mean for "system" in this context, but if it means that you are planning to run your application in two servers, one dedicated to presentation and other dedicated to business layer, take in mind that a simpler approach (and probably more suitable for your app) is build a co-located architecture.

Basically, the idea is to replicate your app in several servers (at least two) and put in front of them a load balancer that routes the incoming requests among the available servers. All servers share the same database instance. This will give you vertical scalability and also will improve the availability of your system.

I only see the positive side of it but somehow not able to figure out what can be the negative aspect of it?

Distributing your business logic will probably involve a refactor of your application code, if the system is working well you will add some bugs for sure. The necessary remote calls will add latency and the fact that you execute your business logic in several servers doesn't resolve the performance problems on the presentation tier.

In Expert One-on-One J2EE Development Without EJB (pag. 65), you can find a good reading about why not distribute your business logic.