things to consider while building java app for computer that can handle 1000 logins at a time?

[Mohan Mehra]

Hi, I really don't know in which section to ask this question. I thought its java based app so chose this section.

I will be building a leave management system using java,jsp, and mysql.(please tell if this is a good idea). it will be used by employees of a company with thousand strength. if all these employees use this application at once, how do i go about building it to handle such a situation.

[Abhay Agarwal]

first thing -. you need to consider about how to handle DB connection pooling. Probably need to consider hardware and software architecture of application. think about load balancing - horzontal / vertical scaling ... cachine etc

[Ulf Dittmer]

You need to clarify what you mean by "1000 logins at a time". 1000 concurrent user sessions is not large number; any modern server should be able handle that (assuming that the web app and the DB are performant). If you actually mean that 1000 users are accessing the server at the same instance in time -1000 concurrent requests instead of 1000 concurrent sessions- then you probably need to think about load balancing. I'm not exactly sure what a "leave management system" would be doing, but it doesn't sound particularly taxing in its complexity.

[Mohan Mehra]

Ulf Dittmer wrote:You need to clarify what you mean by "1000 logins at a time". 1000 concurrent user sessions is not large number; any modern server should be able handle that (assuming that the web app and the DB are performant). If you actually mean that 1000 users are accessing the server at the same instance in time -1000 concurrent requests instead of 1000 concurrent sessions- then you probably need to think about load balancing. I'm not exactly sure what a "leave management system" would be doing, but it doesn't sound particularly taxing in its complexity.

1000 users are accessing the server at the same instance in time

[Tim Cooke]

Assuming you haven't actually started building this system yet then I think that you're getting way ahead of yourself.

Your primary consideration at this point should be working out what the functional requirements are for the system and getting those working. Concurrency is of course one of these considerations but in terms of functional design you only have 3 scenarios to consider: Zero, one, and many users. You know that your target company has 1000 employees so you're interested in the "many users" scenario but don't get sucked into doing Premature Optimization. Start small, get it working with 2 concurrent users first then, and only then, use a profiler to simulate 100, 500, 1000, 2000, 5000, 10000 concurrent users to see when or even if your system performance starts to degrade. Only with this information are you ready to decide whether any further performance optimizations are required. A widely used mantra for this is Make It Work, Make It Right, Make It Fast.

[Paul Clapham]

Tim Cooke wrote:You know that your target company has 1000 employees...

Actually, no. We are told that 1000 of the employees are going to be scheduling their time off at exactly the same time. This would mean that the company probably has at least one million employees, since any individual employee would only be spending a couple of hours a year doing that.

If it's really true that the company only has 1000 employees then the system is only likely to have one simultaneous user most of the time.

[Tim Cooke]

We're actually told both

Mohan Mehra wrote:it will be used by employees of a company with thousand strength. if all these employees use this application at once

I agree with you Paul that the probability of all employees accessing the system at once are ridiculously small. But, when you get asked by the stakeholder if it will work, it's nice to confidently say "Yes, of course!"

Either way, a thousand employees, a million employees, my approach would be the same.

[Anayonkar Shivalkar]

Paul Clapham wrote:This would mean that the company probably has at least one million employees,

I just checked and found that the list of employers having more than million employees is pretty small

Ok, jokes apart, I agree with Tim (regarding premature optimization). However, I'll still go ahead and add a DB connection pool (I'm not very inclined to open 1000 DB connections - even for the small query).

Also, if the operation is processor intensive, then EJB can be to the rescue (it is better to involve multiple objects, rather than share same object across 1000 threads), or maybe internal queues to handle requests...

But again, as Tim has mentioned, for this specific thing, you need to measure the performance via simulator - maybe the operation is not very intensive (e.g. log in, make an entry to DB, log out etc.) and you won't need to do the things mentioned above.

[Paul Clapham]

Well, yes, the approach would be the same. But what I did there is a "back of the envelope" calculation. That's always a useful thing to do when in the initial phases of a design. You want to start out with a realistic estimate of usage rather than an OMG estimate, and I think the thread started out with the OMG estimate.

[Tim Cooke]

Anayonkar Shivalkar wrote:then EJB can be to the rescue

Whoa whoa whoa there. You just made me physically wince with that one.

In this day in age EJB's are almost always not, never, ever the answer. If it's Dependency Injection you're looking for then Spring or Pico will do just fine and are quite manageable. If it's db access management you're after then Spring JDBC, Hibernate, even vanilla JDBC if you're feeling brave, plus a host of other options will help you out.

[Paul Clapham]

Tim Cooke wrote:I agree with you Paul that the probability of all employees accessing the system at once are ridiculously small. But, when you get asked by the stakeholder if it will work, it's nice to confidently say "Yes, of course!"

My answer would be "No, it won't work if everybody decides to use it at the same time." There's no point in building a system which is 1,000 times more powerful than what you need -- it would be like designing the entrance to the company parking lot to allow for the possibility that all 1,000 employees arrive for work at the same instant.

[Anayonkar Shivalkar]

somebody wrote:If hammer is your only tool, you'll see every problem as nail

Looks like my case is like this
To be frank, I know very little JPA and almost nothing about Spring - so can't say about it. But yes, lot of times, EJB is overkill.

I think its time to wait for OP's response about what he intends to do next(maybe initial design, or simulation results etc.)

Paul Clapham wrote:it would be like designing the entrance to the company parking lot to allow for the possibility that all 1,000 employees arrive for work at the same instant

You nailed it Paul!

[Rajat K Gupta]

Make a dummy application and try to test it on different servers and machines. Try to tweak it in different ways.
The question you have asked may not have a definite answer.

So I would say create a dummy application and use profilers/different systems/ servers and check the difference. This will give you a fair idea what is required.
Follow the mantra :- Make It Work, Make It Right, Make It Fast.

All the Best and do share your results!!

[Tim Cooke]

Paul Clapham wrote:it would be like designing the entrance to the company parking lot to allow for the possibility that all 1,000 employees arrive for work at the same instant.

Well when you put it like that it's hard to disagree.

[Paul Clapham]

Tim Cooke wrote:

Paul Clapham wrote:it would be like designing the entrance to the company parking lot to allow for the possibility that all 1,000 employees arrive for work at the same instant.

Well when you put it like that it's hard to disagree.

There are some important differences between the web application and the parking lot, though. It's a lot easier to scale up a web application if you didn't make it large enough, whereas not so for the parking lot.

[Campbell Ritchie]

And you can delay a web application by a few milliseconds; if you delay entry to the car park by a few seconds, you will block the access road for an hour.

[Mohan Mehra]

hey everyone thanks for the enormous replies. helped me a lot especially the communication between Tim And Paul. Great guys. i will start working on it . make it work for one or two users and then tweak it if required. thank you everyone. great job.