Our app is a simple portal (will be deployed as azure webrole) with following features -
What I am trying to gather is what do you think is a reasonable number of concurrent logins for an app like this on one small Azure instance? (I know two instances are needed for better uptime, but lets say we have only one)?
The backend is SQLAzure for legacy reasons (and not windows azure storage). To give an idea about datasize, about a 1000 users data will be stored within 50 MB of storage (images are present only for events and will be pulled from windows azure blobs).
Just use the appropriate architecture and you'll be able to host thousands of concurrent users on a single Web role without even noticing the load or stressing the underlying persistence (whether it is RDB or full event storage). If the numbers of concurrent users go higher, problem of scaling will be just merely about adding another web role or command processor (depending on the type of the load).
I recommend to start looking towards CQRS architectures that go really well with the cloud computing and notion of almost-infinitely scalable solutions.
For a thousand users, you should not be worried.
IIS7 handles up to ten-thousands concurrent users or more, but it boils down to the hardware. Since it will differ depending on what you actually do in code I would recommend publish your app to azure and stress test it.
This tells you if you need more than one front-end or if it's the db which is holding you back.
Also implement logging in azure to time different events.
[Edit]
Another thing to consider is what is a "concurrent user"? If you demand response time of 1 second, and the actual call takes .2 seconds, then you can perform 5 calls consecutively, and still regard them as concurrent.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With