Let’s try and finish up the discussion around sizing by talking about the Collaboration and Analytics server products. As a quick reminder, these products are not required in anyway within a WCI implementation, but there are a lot of customers who use them. There are also a number of customers who depend on them as part of their business. As such, I do get asked a lot how customers can size these specific products.
When thinking about the sizing for Collaboration and Analytics, the question has to be asked: How is this customer going to be using Collaboration and/or Analytics within the scope of their WCI implementation? Let’s take a look at each one individually.
Collaboration
Aside from the portal itself, Collaboration is one of the most heavily used components within the WCI architecture, however not all customers use it. Going back to our customer example, we know that the customer is planning on using their Collaboration environment for project management purposes within many of their internal departments. They are expecting as many as 200 different projects to be managed through Collaboration with as many 1000 users working on those projects at any given time.
This does not mean that all of those users will be working within Collaboration at the same time, but there is the potential for that. Collaboration is going to be a very important piece of this customer’s implementation.
Collaboration on average can handle about 400-500 concurrent users at a time depending on the types of activities the customer might be performing. With this as a gauge, we can see that we will need at least two Collaboration servers to support the 1000 potential users that will be working on their respective projects.
RECOMMENDATION: When working with multiple Collaboration servers, you might want to think about how the application is installed and deployed. Due to the fact that Collaboration is a Java based web application, there are a number of ways that it can be deployed. The default installation includes a black-box deployment of Tomcat which Collaboration then gets deployed into. When working with multiple servers though, it is best to deploy Collaboration within a WebLogic application server, so that web application clustering can be used to manage the user session across the two available servers. This is not a requirement, because hardware based load balancing could be used with the Tomcat deployments, just a recommendation.
Analytics
Analytics is a different type of component that can be used within the scope of WCI architecture. It has both a backend component that runs behind to scenes to collect all of the data that is used to determine how a WCI architecture is being used. It also has a web application front-end that can display the aggregation of the collected data into a set of portlets.
In our customer example, the customer is using Analytics to track what communities and portlets are being used the most, as well as what search terms users are supplying. This will help them better determine how the WCI implementation should evolve. However, our customer is using a Business Intelligence tool like Hyperion from Oracle to massage and view the collected data rather than using the OOTB portlets, although some community managers do use the portlets.
Because of the amount of activity the Analytics server is processing, it is best to have Analytics on a server by itself, but it does not appear that there is a need to go beyond the single server.
Conclusion
Using our customer example and all of our previous sizing blog entries, we have the following within our architecture:
• 4 x Windows based Portal Servers
• 2 x Windows based Image Servers
• 2 x Windows based Automation Servers
• 2 x Windows based Search Servers
• 2 x Collaboration Servers
• 1 x Analytics Server
• 1 x Windows based Database Server
IMPORTANT: I am sure that a lot of people are going to read this and think that this seems like a lot of servers, but please remember that all recommendations above were brought together as a set of guidelines and not as a definitive architecture for all customer implementations. The number of servers suggested was based on a Windows installation and the types of hardware that are available for that type of environment. Because of the differences in hardware and operating system, the numbers could be very different if the platform were either a flavor of UNIX or Linux.
Please see the WCI certification matrix for all supported platforms: WCI Certification Worksheet
One question that I am sure a lot of people are going to be thinking after reading through this last of the sizing blogs is: “What about Publisher, Pathways, and Studio?” I am not going to be covering these products, because they are essentially in retirement. They are certified and supported with WCI 10gR3 and they will continue to be certified with WCI 11g, but we are not doing any new development on either of these products. Each of them has a different story for what will be happening to them long-term and I will be happy to talk with any customer about that, but from a general perspective, we will not be doing any further enhancements on the products.
Comments (2)
I'm in the camp of "this seems like a lot of servers".
Posting a "guideline" recommending a 100% concurrency architecture for Collab is overly ambitious, even with the your mileage may vary clause.
I'd love to know what the average concurrency for companies between 1000-5000 users, and how that differs in companies that had a prior history of collaborative technology vs those that don't? What does a 3 and 5 year graph of usage look like for these companies?
Did Plumtree or BEA ask customers for usage data? Does Oracle?
In our case:
When we launched collab 3 years ago we had high hopes for our 2k users: 300 projects, heavy usage of the discussion boards, document section and tasks for project management. Even with those hopes, 50% concurrency would have been unrealistic.
Unfortunately changing our culture from email to discussion boards, and share drives to version controlled collab projects has proven extremely difficult.
A good month for us is 400 messages, 500 document submissions and 13k document views (an inaccurate metric given our storage of some images in Collab which are then used in the "announcement" section - thus counting as a read each time the image displays).
We easily run collab, publisher, studio, and notification on a single 4 year old Windows box.
Posted by Geoff Garcia | July 10, 2009 4:36 PM
Posted on July 10, 2009 16:36
Interesting comments and very useful series of blogs thanks for that.
I've got a project coming up soon that will use the Webcenter suite, hopefully fully, but that may take time. But I need to think about capacity planning for 3000 users in a unix environment. I take it single server instances for pretty much everything as max is a given and in most cases sharing a server for multiple modules.
What about the things you haven't talked to yet and aren't part of WCI, like UCM? That could become an inensively used area what sort of cappacity should we be looking for there if offered as External extranet sites to vendors/customers...
Thanks again I hope to read more capacity planing type of blogs from the experts. Cheers.
Saleem,
You definitely make a very good point here, because as hardware has changed for other operating systems, the number of servers needed has definitely diminished. I actually did put a note at the bottom of each blog entry, that I was referring to Windows installation strictly, because UNIX environments can definitely handle a lot more on single servers. With the number of users you are talking about, you could easily handle all of them on a single UNIX server as long as you have enough processors and memory. The one great thing with UNIX operating systems is that it makes it a lot easier to specify what processors should be used for what processes and this allows you to use one server while making sure that your processors are segregated out properly.
The only key that I recommend is that you try to make sure that you give at least 2 processors to each of the portal server instances that you need as well as the Search Server. Those are the most heavily used services within the architecture.
As for your question with UCM, there isn't really any differences here. I would definitely recommend that it gets its own set of processors, but as long as you have enough processors and memory then you could easily do all of this in one server. I would just seriously recommend that you have a duplicate machine for failover, because otherwise you will have a single point of failure.
Posted by Saleem | August 5, 2009 3:42 AM
Posted on August 5, 2009 03:42