I'm on a multi-domain cloud account and have a question. Regarding the option to set Shared Cloud Servers to 1 or 2, if it's a load-balanced situation, why would I ever want it to be set at 1? Is there some negative to setting it to 2 all the time for each of my sites?
There are application design considerations when it comes to running a site on multiple workers. Each worker runs independent of the other, meaning they are not aware of each other. Let's say you wrote a chat room application that stored the messages in memory. You have 1000 users on worker A and another 1000 on worker B. The users on A could talk to each other as could the users on B, but the A and B users could not talk to each other. Using something like SQL as a backplane to store the data from both workers would be essential here where as in a single worker scenario - you could do so in memory if you were so inclined. Similarly, assume worker A died for whatever reason. Your users would be sent to worker B and a new worker A would get fired up. Great! That's one of the epic reasons the cloud is so powerful. However, session information, anything stored in memory, anything that was generated using worker A's machine key would no longer be valid. If you application takes this for granted as most of us traditionally did in a single worker/site/server scenario, the application wouldn't work properly. In a multi worker scenario, storing everything in a back-plane such as SQL is important. Think of it like running multiple webservers where users are routed to a different webserver at different times. Having said all that - simple sites that aren't very dynamic in nature, don't need authentication, etc should scale out rather easily.
My site is an authenticated, n-tier application with a SQL server back-end, so there are no concerns about them not being able to see common global data. However, what about the session state? I'm currently running in-process, so of a server died, then that user would be forced to log in again when it gets picked up on the other server. But if I moved to a SQL-based session state configuration, that wouldn't be the case, right?
Correction: you do not need to set your own machine key in your web.config because we create a custom defined machine key for you when the site is created.
Still not clear to me what needs to be done for Everleap and session state. In DASP, I was using inProc. In this link, it talks about using SQL Azure for the session state, http://blogs.msdn.com/b/sqlazure/archive/2010/08/04/10046103.aspx . Is this preferred approach? Is Everleap responsible for running the script for the session storage in SQL Azure, or is that something we take care of.
Hi Ron, I'm afraid you won't be able to use "InProc" because there is no way to sync the sessions in memory. You'll need to open a ticket to have SQL Server Session State tables installed in one of your SQL Server databases.
Stay away from InProc if possible. You want to store session information in SQL Server as Ray suggested.
