Last post Jul 26, 2011 12:17 PM by magicmike2011
Jul 24, 2011 11:27 PM|magicmike2011|LINK
My knowledge of server/web farms and web gardens is fairly basic. However I have been rolling around an idea for a possible server farm structure for a social site that would have a very high amount of concurrent users, high amount of application server
traffic as well as a very high volume of database traffic. Let's just say for arguments sake, that the "imaginary" site would have to accomodate a few million concurrent users or more on a regular basis. (the web app using a completely custom method of handling
membership, authentication and sessions by utilizing cookies and databases. NO in-memory sessions! (except minimal view state/control state etc. when absolutely necessary). Basically no cookies, no service...
The structure of the farm would be:
SERVER Type 1: These servers hosts the web application its self and 1 single database of a very simple structure that only contains user id's and a value that indicates which section of teh web farm the particular users data is stored in ( which set of
servers... I'll explain why further in). This servers file system, etc, and database would be replicated as needed to accomodate the performance requirements of the web apps traffic. (basically the same way as in a cloud).
SERVER Type 2: These server(s) would be dedicated entirely to hosting the Session Databases. This way the server(s) could be optimized exclusively for a very high volume of short queries and data modifications ( i.e: high-volume connection pools, full recovery
models on all databases, asynchronous auto updates of all statistics etc.). And once acceptable performance limits are close to unacceptable limits another server could be added to the Sessions Server collection and new members sessions would then be assigned
to the new server (and a value indicating that would be stored in the original and all replicated servers of SERVER type 1.
SERVER type 3: The servers of this type would be dedicated to hosting The Membership and Profile databases exclusively, and would be configured accordingly, again, aimed at optimizing for performance of the needs these databases will fullfill. Like the session
servers, when the acceptable performance capacity is near being reached, a new server would be added to the server group and new members would then be assigned to that server.
SERVER type 4: These servers would be entirely dedicated to services such as member to member mail messaging and would be configured optimally for such. Same deal as above, adding new servers as needed and assigning new members to use the new server as their
SERVER type 5: would be dedicated to file hosting of user-submitted images and other high volume media. and associated databases, except images. images would strictly be file-based).
The last server type would be for handling storage of data-based site content, support tickets sytems etc.
Also considered the idea of a database server group type that would be entirely dedicated to use for temporary tables for complex queries as a way of preventing the high overhead associated with them on the servers which would have otherwise managed them
(not sure if this would be counter-productive to the connection pools though...).
All servers would be fail-over clustered and would be properly linked. All servers would be on the same local network to avoid the need for use of full distributed transactions (since their on the same network). Also would be set to use the same machine
keys where needed, although I'm sure it may be more "secure" to allow for independant machine keys on certain server types. That way if one machine key is somehow compromised, the others are still secure .The reason behind the idea of this strcture is that
I figure it would allow for excellent performance even with such a high volume of concurrent users AND would also allow for extremely fast and easy scalability of the website with minimal modifications to code, data structures etc.
I realise a system of such could be MASSIVELY power consuming and cooling could be an issue of it grew too large. BUT since it's just a hypothetical situation... Do you think this could be feasable or atleast be performance friendly?
I'm new... be gentle... lol
Jul 25, 2011 03:19 PM|atconway|LINK
@magicmike2011 - Unfortunately you might not get a lot of feedback from this forum because it is more about 'Software Architecture' as opposed to 'Hardware Architecture'. For these questions it is best to re-post your question on the IIS or TechNet forums
Jul 26, 2011 12:17 PM|magicmike2011|LINK
Thank you much :)