none
any thoughts on this server farm structure idea?

    Question

  • 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 "inbox" location.

    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

    Tuesday, July 26, 2011 4:24 PM

Answers

  • I've not dealt specifically with Social Sites but have with large scale / high traffic websites and one of the things that you haven't included in your post is the Design of the Network and backend storage. From experience, this tends to get forgotten about (or left to last) and people focus on CPU, Memory, scaling servers out etc etc but you have to be careful that you don't bottleneck through the IO subsytem.

    Difficult for me to say whether the farm is a good or bad setup without this information and the type of distributed queries you'd be running. Yes in theory separating your servers out can help balance the load but if your network link is 10mb then having distributed queries running (eg. between servers 2 and 3) could have an adverse affect on the response time.

     

    Thursday, July 28, 2011 7:58 AM

All replies

  • I've not dealt specifically with Social Sites but have with large scale / high traffic websites and one of the things that you haven't included in your post is the Design of the Network and backend storage. From experience, this tends to get forgotten about (or left to last) and people focus on CPU, Memory, scaling servers out etc etc but you have to be careful that you don't bottleneck through the IO subsytem.

    Difficult for me to say whether the farm is a good or bad setup without this information and the type of distributed queries you'd be running. Yes in theory separating your servers out can help balance the load but if your network link is 10mb then having distributed queries running (eg. between servers 2 and 3) could have an adverse affect on the response time.

     

    Thursday, July 28, 2011 7:58 AM
  • hmm, good point I'm a little embarrassed to admit that's actually something I didn't put much thought into either.. lol. Like I said, I'm new so thank you for bringing that to my attention. My knowledge of this type of system is pretty limited but I'm assuming by back-end storage you're meaning the actual data warehousing? I guess I was presuming the original and replicated servers that act as the file host for teh actual web application its self would act as bot the front end and middle-tier servers. But from you're response I'm guessing that is a bad idea to attempt as it will bottle-neck the datastores without some "actual" middle tier to regulate to queues. 

    The real reason I'm looking for feedback is because the web app I'm designing is still in the very very early stages of development and I'm trying to get an idea of what I need to take into consideration during development so that if (hopefully) someday the site has an enormous amount of users, I won't need to completely redesign  the structure of both the app AND the data system to be able to scale up the entire project.

    I am  figuring on launching the site entirely on 1 dedicated server JUST in the beginning just while I try to establish a user-base. But I want to be able to smoothly move the site into a server-farm as the demand for it grows. You sound like you may have some valuable tips and ANY advice would be greatly appreciated  :)   Thank you so much in advance.


    oh look! A box! Let's type in it!
    Sunday, July 31, 2011 1:58 AM