How many users on one azure instance before I hit performance issues?

Our app is a simple portal (will be deployed as azure webrole) with following features -

1. Login
2. See details particular to that account (no heavy calculations, only showing details already saved in the DB)
3. See a list of events published to all accounts
4. Basic accoun开发者_JAVA技巧t management like password change

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.

---

Defining your concurrent users is important. A single instance running in a Role isn't going to handle a thousand actual concurrent users, not effectively, but bumping up the instances will give you the ability to scale that out no problem. However, keep in mind that each instance is a compute instance, thus charging $$.

Once you figure out what Role & Instance provisioning you want to make available for the application you can then get a real idea of what you'll need. Also, keep in mind that load balancing and other issues that could come into play if the site is truly huge. You might need to contact Microsoft to appropriately plan at that level, and possibly even more to two Roles with multiple Instances in each of those Roles.

Anyway... just adding some additional things to think about.