that depends very by your application needs. You could server a very simple App to thousands or have an app that reaches it's limits with 10 users. When you have some hardware, try to run real-world-scenarios setting up a test-case (JMeter, HP LoadRunner) to find out, what happens. It's sure not the easiest task and not such one, that would be completed by 30 mins, but it's very important when you're going to have tons of users.
JBoss (Community) is sufficent as long as you have enough CPU, RAM and IO's. The EAP would be right choice, in case you need more support than the community can give you.
If the throughput is not too high you might install many applications in one JBoss istance
often this is not a good idea because:
- separate different customers because of hidding sensitive informations
- no influence of processing time and throughput
For me it is not clear what you mean by customer and user.
What the 2000 customers do? How much requests per second do you have?
thank you very much for your answers.
1- a customer will purchase a contract with us.
2-a customer can register up to 5 users to it application
3-a user is restricted in the application deployed by the customer who created the user.
4-customers can only see data of theirs respective users
5-data of different customers are completely (physically) separated
a user will typically access the application one day per week, for 30 min.
all users may access the application at the end of the month.
10.000 Users max, peak some concurrent 2.000 Users. Can get tight.
For example: I was some time ago on a team, they developed an web app with some 100 - 500 concurrent users. It was JSF-based, ran in a cluster with 2 nodes having each 24GB RAM and 8 CPU Cores. Average load was at 10 - 18GB RAM, 20 - 40 % CPU peak 90 % -100 % CPU (overall) usage and max avg response-time 5 sec.
Thank you Mark,
we will delegate most of the computation work to our RIA client. Server will only provide data storage and reporting.
We also "take the risk" to use one embedded database for each customer, we hope so to save connection overheads.
We will have to experiment and see how the system scale.