6 thoughts

  1. Not a bad article, but places too much emphasis on session-based servers. It barely mentions client-based systems, and even then it delivers a knock with "unable to maintain complex variables."
    In my opinion if you’re at the point were you need to scale to multiple servers you probably shouldn’t be using session-based variables anyway. They won’t fail over correctly when a server drops offline, and if traffic levels are that high you shouldn’t be storing a bunch of "complex" variables per user anyway.
    Also fails to mention additional scalability enhancers like using dedicated "application" servers to manage membership information, logins, registrations, etc.. In which case dumping CF’s session/client system may be in order.
    The only time high-scalability sites should consider sticky sessions, again in my opinion, is when you’re using HTTPS/SSL to the server in question. And even then you may be better off with a load balancer that can handle SSL on the front end with dedicated hardware.

  2. This article is coldfusion clustering 101. There is a whole can of worms underneath this when you actually build a CF based cluster.
    It doesn’t mention verity, and due to the OEM license, you will have major issues if you try to run it on a cluster.
    he says ‘The replication mechanism is the key here’ but doesn’t really say what options you have ? are there alternatives to robocopy ? what other techniques could be used? This is a massive headache if you have an app that does content uploads.
    Also, if you go for a setup like this the costing can go up by a factor of 10 over a single server setup. This is in the extra hardware, configuration and CF licensing costs.
    Im not saying im against CF clustering. Its a great solution for high availability sites, but you really have to have a good business case to support it.

  3. @Michael, I notice you blogged about high availability in Dec 2007 raising several points worthy of investigation. Will you follow this up with a more detailed article about the best ways to cluster in terms of hardware and software options please? It sou

  4. @Pat: So true. CF licensing tends to bias servers towards one or two massive (and expensive) multi-cpu systems rather than many cost-effective 1U servers or blades. You can buy a semi-decent 1U server for the cost of a CF license, and three or four for th

  5. I am sorry to be late in responding to these comments, I was not aware that Ben had been kind enough to blog about my Adobe article. No doubt any shared scope is a challenge with clustering and I always recommend using request scope rather than application scope and client scope rather than session scope. I have found replication of the session scope to be problematic and unpredictable but that is usually because it is an application with very large complex objects in the session scope. So session replication be it simple variables or complex variables is a challenge, using WDDX to mitigate this carries an overhead which may or may not be acceptable.
    You are all right that this article mostly covers concepts which in my opinion are important. Each actual design of clustering will be very application/infrastructure specific and it is difficult to be more detailed in a general way. I have been involved in several and it takes a lot of planning and also testing of each concept to validate before production roll-out. Things such are replication always poses challenges whether for clustering needs or not.
    Thanks for all the comments, you have given me food for thought for future articles.

Leave a Reply to michael Long Cancel reply